JUCE Library update

[Carlos Nunes]

Hi @Steffen Fuerst ,

Today I spent some time with the latest version of Juce Library (master branch after tag 6.0.8) and for my surprise there were an VisualStudio 2019 solution there with compiles flawless, not even warnings!

So I decided to try to upgrade your project to this version, because I strongly believe that it will solve issue #8 once for all. (Or at least have a better ground to search for bugs.

I’m not a C++ programmer, but I’m an experienced C# programmer and I’d really like to improve my C++ side.

I’d like to ask you for help to figure out some issues, because I’m planning to restart the migration, but doing commits from time to time, so you could check the improvements, what do you think?

I know from your previous reply from Reaper forum that you don’t have too much time to deal with this program alone, that’s why I’d like to help.

I thought that I was going well until sudenly I start to get a lot of error messages with @@@ and no source code line referenced (only .OBJ).

As soon I have that figured out, I can take care of bug fixing and improvement that this program deserves!

What do you think?

[Carlos Nunes]

Just to let you know, after several hours of fighting with linking libraries and project parameters, I finally get it!

I had to “touch” Juce project setting to change Runtime Library setting to Multi-threaded (/MT) and change the output filename, because I simply could not find how to change the references at your project.

Due the changes on Juce library, I created two environment variable to point to Juce modules and libraries as needed.

As I suspected the issue #8 is gone and I just need to figure it out how to change the font color of labels and textboxes.

If you want to give it a look, here’s my branch (I will create a PR only when it’s working): https://bitbucket.org/Caverna/csurf_klinke_mcu/branch/JuceUpgrade

[Steffen Fuerst]

Wow, thank you for this work, the changes in the branch are looking good.

Unfortunately I am busy with the preparation of a recording session until the beginning of August, but if you have concrete questions just ask.

[Carlos Nunes]

No problem, I can wait!

Here’s the current statuts. If you agree, I will create a new method at CCSModeEditor.cpp to fix the colours, due the new library version (unless you have a better idea):

The issue #8 wasn’t completely gone.

Reaper doesn’t crash anymore when I leave reaper environment, but the old window stays there and it will crash only when I try to close it…
I will be working on this issue as soon I have the text showing correctly.

There’s another task to be done: the project cannot be compiled in DEBUG mode, but it should be taking care only after the library is working…

[Carlos Nunes]

Hallo!

To keep this subject updated, here’s I got so far:

It was easier for me to make background darker, instead to make the texts black (branch updated).

[Steffen Fuerst]

This dark background fits very well to my Reaper theme The only problem I see are the missing or not visible borders of the textboxes.

[Carlos Nunes]

that’s great! I liked that too…

I did notice the missing border for textboxes, but before working on that, I prefered to wait for your oppinion.

Now I can work to fix that.

[Carlos Nunes]

‌

HMFS!!!

Labels used as TextBoxes!!! I would never expected that!

Should I look for all instances where that happens, setting a border or should I replace by TextBox?

[Steffen Fuerst]

Yep, that is strange. I can not remember why I have done this in that way. So if you do not run into problems by replacing them with a TextBox I think this is a better way then adding additional borders.

[Carlos Nunes]

ok, I will put my efforts to replace the labels then…

[Carlos Nunes]

Beautiful!

‌

‌

‌

‌

[Steffen Fuerst]

Looks great. Thank you a lot.

I wonder, however, why only six pages appear in the action mode editor, there should actually be eight.

Can you document the necessary environment settings for Juce, incl. other steps necessary to use your branch (I think the best way would be to update the readme.txt)? I would try to compile it, to see if I can reproduce your problem in issue #8 with the new Juce version.

‌

[Carlos Nunes]

No man, I thank you for the opportunity!

The six pages at action mode was C++ fault, not mine

I replaced the code repetition for a for-loop and I used: String("Page " + ('1' + i)) to format the text.

Replacing it by: String::formatted("Page %d", i) brought back the last two pages!

I updated the readme.txt describing the two new environment variables and what I needed to do to compile, but I think you can do better, using fresh new settings.

(by the way, take a look at new Projucer, you will be amazed!)

I did create a PR with this branch, since it’s in a good shape to be used.

Important to notice, I didn’t update your project file, since you’re using an older version than me.

So you need to include these two addicional variables at “additional paths” project settings

[Steffen Fuerst]

I create a build with Juce6, but this build crashes already at startup, while reading the GlobalAction.xml file. Can you please upload your jucelib* builds to my cloud storage? And also the project files for the Juce6 libraries and the CSurf (I have now also installed Visual Studio 2019)? Thank you.

‌

[Steffen Fuerst]

Did you changed the JUCE_STRING_UTF_TYPE?

[Carlos Nunes]

I didn’t change JUCE_STRING_UTF_TYPE…

As requested, I uploaded the compiled Juce I used and my .prj files.

Important to say that I was able to compile for 32 bits/Release only!

But since you have VS2019, maybe it’s better to restart with a fresh install of JUCE, running Projucer and letting it to create a new VS2019 project!

Doing that way, you can even create Linux and MacOS versions too!
I was afraid to update the project to VS2019, but since you’re there too, I can try to do here, saving you from this trouble, leaving to you just the “small details” that may be necessary, what do you think?

[Steffen Fuerst]

Thank you for the files. I'm afraid I won't be able to continue working for the next two weeks, but after that I'll focus on this.

Regarding a new VS2019 project via Projucer: Don’t underestimate the work. My starting point was the reaper-sdk and not Juce, and i doubt that you will find a Projucer-Template that you can use without a lot of adjustments. But of course it would be nice to have it, so if you really want to give it a try, do it.

[Carlos Nunes]

yep, I noticed that…

so, lets do the following, you take care of having a “compilable” version for release.

in parallel, I’ll be working on make the original reaper-sdk to work via Projucer.

As soon I got that, I will start to migrate all your code to this new environment, keeping your original structure as best as I can.

I’m sure that this will take more than two weeks, so as soon I have that working, I can have any modification that you had included on this new environment for validation.

Having the possibility of releasing versions for Linux, if doesn’t increase the number of user, surely it will at least make it more “famous”…

[Carlos Nunes]

Hi @Steffen Fuerst…

I really don’t know what kind of black magic you did here…

You said that I may run into problem with Projucer-Template, but I’m struggling with something even more basic and I cannot find a single information about that.

How did manage to compile Reaper sdk?

I mean, you didn’t create any .lib and even that the application can be compiled!

When I try to compile Resharper I always run into problem with “unresolved external symbol” (LNK2001), but if I compare the project settings side by side I have basically the same settings as you!

I really tried to find by myself but for everything I found, it’s supposed that I should be importing .lib files!

Just recently I found about open source libraries but even that expects me to compile them to a local .lib or to manually add the files to my project…

What’s the catch here?

[Carlos Nunes]

Ok, I’m felling like an idiot now…

I can compile in release win32/x64 versions but no debug win32/x64. I see not too much worries here, since I could not compile the original debug version either…

But now I simply don’t have the surfaces listed in a clean reaper install, nor at my “main” reaper install…

yep, long road ahead…

[Steffen Fuerst]

Oh, we worked in parallel on this, I also just successfully created a JUCER-project that compiles, but is not listed as a control surface (I first build a version with your Juce libs, but also with those Reaper crashes at startup while calling Juce functions). I plan to take a deeper look into this next week, but if you are impatient or curious, you can find the entrypoint that Reaper tries to call for each dll at linenumber 198 in the csurf_main.cpp. I assume that this is not called at all, for whatever reason. Maybe the developer section of the Reaper forum could be helpful.

[Carlos Nunes]

funny…
I was about to make a PR of a Projucer project…
I’m glad to know you’re back on this…

Since you’re on that, I’d like to say that update Boost is not a good idea…

Looking at csurf_main I can find the entrypoint. Comparing to original from sdk, it doesn’t seems to affect (I tried to comment the error checking for errcnt, it makes no difference)

If it helps, I noticed that I can overwrite .DLL while Reaper still running, meaning that the file is not loaded!

Please let me know if I can help!

[Steffen Fuerst]

Okay, my new extension was not loaded, because the name didn’t started with reaper_ anymore. After changing the name of the dll, Reaper tries to construct the extension, but crashes when it tries to parse the config-xml-files. When I remove the xml files, I can open the Control Surface dialog, but the dialog is empty, it seems that the resources are not included sucessfully into the project. I will continue to look into this tomorrow.

[Carlos Nunes]

fuuuuuuuuuuuck….

I don’t remember seeing anywhere that the name needs to start as “reaper_”!

thanks for the feedback!

If I can help in anything, please let me know!

[Steffen Fuerst]

Yes, I found the reaper_ information also only in the maybe 10th “how to create an extension” post in the Reaper forum.

Maybe I have understood the resources problem. It seems that the Projucer exports an own resource file, which e.g. contains the Version Number you enter at the top of the project settings. My current solution is:

After exporting the project from Projucer, close Visual Studio, open the vcxproj and vcxproj.filters files in a text editor and replace the existing <ResourceCompile> sections with

<ResourceCompile Include="..\..\Source\res.rc">
  <Filter>CSurf_MCU_Klinke\Source</Filter>
</ResourceCompile>

It’s likely that you must adjust the Filter with your path.

After this change, I can open the resource dialog, but afterwards Reaper is crashing, likely at the moment when the new created csurf instance (changing the settings always destroy and recreate everything) tries to read the default xml files that where created when the first instance is destroyed (but I have not checked this in the debugger).

It would be nice if you could find a solution/setting inside Projucer, that allows to export already with the correct settings.

For the linux port this resource dialog will also create some additional work, as the current solution is windows only.

I will be away till the end of the next week.

[Carlos Nunes]

Before everything, it worths all the efforts to pursuit this goal, since this last Juce version doesn’t have the “lost focus bug” (I could even remove my fix and I can leave and come back to Reaper without any issue)…

It seems that there’s no way to set this value at Projucer at all…

This was the most solid information so far: https://forum.juce.com/t/using-our-own-resource-file/8768/15

‌

Using that as startpoint, I was able to compile for Win32/x64 for Release and Release_B, but no Debug so far…

At my branch JuceUpgrade you can find my Projucer working version, but it still some bugs there.

But there are some bugs, for example: I have my “clean” portable version for both Win32 and x64 Reaper (to not mess up my “official” one), which the library works “fine” (I mean, no crash to startup), but when I try to use at my main Reaper instance, it fails…

Also, I can create a .xml config for a plugin, but it doesn’t load this custom version.

Another thing you may notice at my version, I’m not using system variables at all.

I decided to go to relative folders instead, so this is my folder structure:

‌

That made the things easier for me to handle the projects.

Attention: those three folders in red are always recreate, that’s why it doesn’t exists at my branch…

Also you can see my additional Reaper instances. It’s not required, but highly suggested to have…
I’m not worried about the Linux version, because as soon you figure it out what’s wrong, it should be straight forward to apply to Linux (that’s why it avaiblable at Projucer project)

One thing that would help a lot is to be able to complile the Debug version, so I could really dig into the code, but it cannot compile, pointing errors to vector standard library!

[Steffen Fuerst]

I haven’t found time to look deeper into your new changes, but I have some comments:

• The pre-build command setting are fine, thank you for this.
• I also switched to relative folders, but moved the reaper-sdk and WDL folders inside the KlinkeMCU folder (and plan to add them to the repository).
• I don’t have the same problem with the Debug version, the version created by my new Projucer project compiles without errors. Sorry that I don’t have currently the time to continue the work and to commit it (I hope the situation next week will be better).
• The problem with the Linux version is, that the code related to the Settings dialog is not Juce-Code (see the dlgProc function in csurf_mcu.cpp, or the #ifndef WIN32 part of csurf_main.cpp). The WDL library from Cockos should help somehow, but I have no experience with this.

‌