Compiling Klinke source code with newer Visual Studio

[inertia]

I don't have VS 2010 and am trying to get the Klinke controller to compile with VS 2019 Community Edition.

Has anyone managed this?

I have included Reaper SDK, Boost and Juce libraries and followed the instructions but cannot get anything to resolve properly.

Any help would be appreciated. Preferably for 64 bit environment.

[guyperrin]

To get a copy of VS2010 go to this web page:

https://visualstudio.microsoft.com/vs/older-downloads/

and scroll down, you will see the following instruction:

"Visual Studio 2010 and Other Products:
To download any product from the following list, click the download button and log in with your Visual Studio Subscription account when prompted. If you don’t have a Visual Studio Subscription, you can create one for free by clicking on “Create a new Microsoft account” on the login page."

I believe this should get you up and running in VS2010 if you choose to do so.

I am using VS2019 myself, and tryng to compile the klinke driver.

I followed the instructions in the readme.txt file:

1) installed the EXACT versions of the Juce (1.52)and Boost (1.39.0) libraries mentioned in the klinke source instructions ("readme.txt")
2) modifying the include files paths property for the project - didn't bother setting up an environment variable.
3) as I am building a 64 bit version for 64 bit Reaper, I copied across the files located in the "JUCE-changes" directory - as instructed in the "readme.txt" file.

I have yet to successfully compile the Juce v1.52 library using VS2019 - thought I'd just jump in and see what blew up in an initial compile attempt.

The Boost library is headers only and doesn't require compilation, however, the compile is complaining alot when processing some of the Boost declarations - mainly paramter conversion issues.

I have managed to get the compile phase working in VS2019 ... with 869 lines of warnings, errors and notes. I am working through them one by one.

the most prolific error I am getting is:

"Unknown compiler version - please run the configure tests and report the results"

which is apparently being raised by a header file entry in the boost library - this line is from boost/config/compiler/visualc.hpp.

my next step is to compile the Juce 1.52 library in VS2019 ...

perhaps I will download VS2010 and try that ;-) - but only after the obligatory period of coding frustration and pain. I would prefer to have a current klinke derived project working in VS2019.

I am trying to solve a timecode display problem on my newly purchase Icon Platform Nano. Just ordered an Icon Platform D2 - hoping that it works with the current MCU OR Klinke drivers, and it may assist with my work.

regards
guy

[DrFrankencopter]

I compiled it on VS2015...and 2017 IIRC. It was an older version and quite some time ago, but I wrote a bunch of details in this thread here https://forum.cockos.com/showthread.php?t=132992
Klinke used old versions of boost and juce and I recall having to make some changes inside those frameworks. Maybe someday I’ll revisit it, but what I have now works for my purposes.

Good luck!

[inertia]

Sorry for wasting your time but I should have updated the thread that I already solved it.

As you said, you need specific versions of JUCE to get it up and running.

The project compiles for me in VS 2019 with no issues but I don't remember now if there were any warnings.

If you still have problems send me a PM and I will help you solve them.

[guyperrin]

@inertia: thank you for the offer of assistance.
@DrFrankencopter: the juce and boost issues are toe-stubbers, and a deal breaker for me.

thank you both for replying and the assistance offered.
I have decided not to pursue the klinke route at the moment - I hit the my six hour limit and packed it in. I am not interested in JUCE provided functionality.
I am going to develop a csurf_IconNanoD2.dll, using the MIDI codes and sequences exposed in the source for csurf_mcu and csurf_mcu_klinke.
Neither of these two control dlls work with the Icon Nano to give me the full promised functionality (nor does CSI) so I though it best to just develop a dll specifically tailored to my device.

[Geoff Waddington]

Originally Posted by guyperrin

@inertia: thank you for the offer of assistance.
@DrFrankencopter: the juce and boost issues are toe-stubbers, and a deal breaker for me.

thank you both for replying and the assistance offered.
I have decided not to pursue the klinke route at the moment - I hit the my six hour limit and packed it in. I am not interested in JUCE provided functionality.
I am going to develop a csurf_IconNanoD2.dll, using the MIDI codes and sequences exposed in the source for csurf_mcu and csurf_mcu_klinke.
Neither of these two control dlls work with the Icon Nano to give me the full promised functionality (nor does CSI) so I though it best to just develop a dll specifically tailored to my device.

Yeah, I hear you re: JUCE.

I've tried it on and off over the last 15 years or so, and seems you have to buy in fully, and ride the wave by updating constantly as it evolves -- for sure pretty damn good code though -- Jules rocks !!

Agree as well that the absolute best way to exploit a given surface's capabilities is a custom dll.

[inertia]

Originally Posted by guyperrin

@inertia: thank you for the offer of assistance.
@DrFrankencopter: the juce and boost issues are toe-stubbers, and a deal breaker for me.

thank you both for replying and the assistance offered.
I have decided not to pursue the klinke route at the moment - I hit the my six hour limit and packed it in. I am not interested in JUCE provided functionality.
I am going to develop a csurf_IconNanoD2.dll, using the MIDI codes and sequences exposed in the source for csurf_mcu and csurf_mcu_klinke.
Neither of these two control dlls work with the Icon Nano to give me the full promised functionality (nor does CSI) so I though it best to just develop a dll specifically tailored to my device.

The Csurf_mcu code in the mini SDK is an absolute mess but it's usable and does work.

There is a stripped down version of it on Github desgined to get you going with a skeleton project that i initially based my Faderport code on but in the end I went my own way with it.

The Klinke project is very large and difficult to follow if you haven't programmed an MCU before and has a ton of stuff in there you probably won't want to use.

[DrFrankencopter]

Originally Posted by inertia

The Klinke project is very large and difficult to follow if you haven't programmed an MCU before and has a ton of stuff in there you probably won't want to use.

I'll echo that sentiment! It takes hours to figure out what's going on under the hood in Steffen's (Klinke's) plugin.