My guide to compiling Ctrlr (the latest master) for Windows 10 and macOS X (Mojave)

[bijlevel]

I have written a detailed guide to help with compiling Ctrlr v5.6.23 (latest master) for Windows 10 using Visual Studio 2019. As of this moment in time the executable seems to work OK, but further testing is needed, also with the VST3 plugin.

I also succeeded in building Ctrlr v5.6.23 for Mac and found a workaround for the initial problem of 'callback errors'. See the 'issues' section of this repo. This Mac version seems promising, because so far it behaves quite good, but I have to admit I did not yet find the time to test it extensively. I did also write a guide for building on Mac with Xcode.

See for all the binaries and the guides: https://godlike.com.au/index.php?id=361

[Ted-juh]

A massive thanks for the detailed explanation. Or in Dutch: Enorm bedankt voor de uitgebreide uitleg.

This seems to be a good starting point. Thanks again for this explanation I might give it another try to compile CTRLR. See if it's possible to update the Lua bind to some Juce classes. Goodweather might get his chance to update the mouse-over descriptions for the properties and so on.

[bijlevel]

Graag gedaan! You're welcome! My hope is that someone more experienced might pick this up and comes up with a good working executable. Of course I will also keep on working on this compiling business until the result is a stable Ctrlr application.

[bijlevel]

I did upload a new version of the document fixing a typo in the text

[damiensellier]

Thanks @bijlevel this is really helpful. I never did such a thing and it will be very useful.

[dobo365]

Fantastic @bijlevel
Zal het zeker proberen!

[bijlevel]

I indeed hope you or someone else will repeat my steps and discovers why this build crashes with a win32 exception when working with a panel.

[Possemo]

You write that you have no Windows DAW to test the plugins. You can freely use Reaper, there is just a nag screen when you don't want to pay the humble amount for the full version. Reaper handles it all - vst2.3, vst3, x86, x64...

[bijlevel]

Thanks! I know one can find (free) applications that do load vst's, but I'm almost 100% sure the vst won't run if the executable is still crashing. Anyway I take (took?) a pause, because it is enormous time consuming and very frustrating when all that spent time does not pay off. Still hope someone else does also dive into this matter.

[Godlike-Productions]

I use VSTHost for most of my builds on Windows. Much, much quicker than waiting for a DAW to load, and it's free.

https://www.hermannseib.com/english/vsthost.htm

[bijlevel]

I succeeded finally in building CTRLR v5.6.23 'Standalone' running without crashing and with full MIDI in/out. Also the VST3 build succeeded, but I did not yet test it. Part of this success has probably to do with reinstalling VS 2019 and choosing, when asked, as workloads 'Universal Windows Platform development' and 'Desktop development with C++', the latter being the obvious choice. Also I finally found out that VMWare Fusion which I use to run Win 10 virtual on my Mac does not support MIDI, at least not out-of-the-box, so to speak. That was the reason I did see MIDI activity, but no responses from the target midi instrument (in my case the Kurzweil K2500R). When running the executable on my Dell laptop with Win 7 using a simple USB MIDI interface connected to the K2500R it did load and run OK a loaded panel with all the needed MIDI communication.

Next step is to make an installer, because when Visual Studio is not installed on the PC the CTRLR.exe complains about not finding MSVCP140.dll which is, as I learned, a C++ library of the sorts. I did download Null Install System v3.03 (free), because I noticed Roman Kubiak did use that software to generate an installer for Windows. So hopefully I manage to include the needed .dll when making the installer with the Null software. I will keep you posted. I will also update the guide to reflect my latest findings.

BTW I also succeeded in building CTRLR v5.6.23 'Standalone' for Mac, and the AU, VST3 and AUv3 plugins. The VST did not build, maybe because Steinberg deprecated it or maybe it is a license matter. I seem to recall a discussion about this on the old forum. Anyway if someone is interested I can also make a compiler guide for Mac users, because the road to successful compilation on my Mac with Xcode was also paved with many curses ;-), so not an easy task to complete without help.

Lastly, I have adapted the title and the body text of the first message of this thread to reflect to latest progress on this building/compiling business.

[damiensellier]

That sounds really good! For sure a MacOS guide for XCode woud be awesome. Take your time we are not in a hurry :)
What do you mean about "steinberg deprecated it"?

[bijlevel]

OK, I will start writing it. I think Steinberg (the VST "owners" by right...) did want to discourage the use of VST in favour of VST3. But I'm not sure of all this, but (again) there was a discussion about this on the old forum. Anyway, on Mac the build of VST failed, on Windows it succeeded. Personally I don't use VST's on Mac, because most of the time there is also an AU, which I (and my Mac DAW) prefer.

[damiensellier]

Okay I understand. VST2 was not exporting but could you get the VST3?

[bijlevel]

@damiensellier I tried to load the Mac VST3 in my DAW (Digital Performer) but it failed. I will try some other audio apps that can load VST3's. If you want the VST3 anyway, I can send it to you.

[damiensellier]

@bijlevel Sure if you can pack everything up and send it to @Godlike-Productions so that he can host it that would be awesome! I'll come back to you once I'll tested it and let yuo know if there's something wrong. Thanks for all your efforts.

[Godlike-Productions]

I'm happy to try, especially on windows, and can try VST3.

[14bitMIDI]

Same here! Any chance to get hold of the working build? @bijlevel ???
I can test on both platforms and see if there are any differences in funcionality.
Cheers!

[bijlevel]

I have just uploaded version 2 of the guide (see the first post of this thread) with significant changes because of new insights ('voortschrijdend inzicht' ;-)). So please throw the initial version into the bin and download this version!

[damiensellier]

@bijlevel I never used AU ever on a mac. I use Cubase and used Nuendo as well in pro studios for a long long time and being steinberg product they use VST. My friends use studio One reaper and ableton live and they also use VST3. Protools is a bit different since they have their own AAX and logic uses AU. Your are right Steinberg is pushing VST3 there's less and less VST2 releases and 32bit is out for several years. But to sum up, that's a lot of people using the VST format on mac.

[Godlike-Productions]

VST's are required by people using Pro Tools, as there is a VST to AAX wrapper, but nothing for AU

[dobo365]

Thx a lot again for this work!
I will plan to look at this in detail.
As you know, I'm quite "locked" with 5.3.201 and like it despite willing to do some small changes.
I will first try understanding and rebuilding the same version you did.
I will also try 5.6.23 exe with my panels.
Can we then summarize the situation in terms of rebuilding versions?

5.3.201 rebuild:

• Commit number on main Ctrlr github site is
• Original build date is
• Needs VS2010
• Needs Juce v...
• Needs Projucer app?
• Windows 32bits standalone: OK/NOK
• Windows 64bits standalone: OK/NOK
• Windows VST: OK/NOK
• Windows VST3: OK/NOK
• MacOS standalone: OK/NOK
• MacOS VST: OK/NOK
• MacOS VST3: OK/NOK
• MacOS AU: OK/NOK
• Issues/Comments:

5.6.23 rebuild:

• Commit number on main Ctrlr github site is
• Original build date is
• Needs VS2019
• Needs Juce v...
• Needs Projucer app?
• Windows 32bits standalone: NOK
• Windows 64bits standalone: OK
• Windows VST: NOK
• Windows VST3: OK
• MacOS standalone: OK/NOK
• MacOS VST: OK/NOK
• MacOS VST3: OK/NOK
• MacOS AU: OK/NOK
• Issues/Comments:

[bijlevel]

That's a good idea. I think that information you propose should go on the website for CTRLR, hosted by Godlike Productions.

I did find the commit for v5.3.198 dated back to 2016 (from which I think the latest version for Mac was build). I did succeed in building the Standalone version, but building the AU was a PITA, so I gave up. Maybe we should indeed focus on v5.3.201. But is that wise? Maybe focusing on v5.6.x is more productive, because all the needed builds so far did succeed. Doing so we could fix errors or suggest improvements or extra features. I'm sure someone on this forum is an experienced C++ developer ;-) and can help with the required programming.

But anyway I'm happy to try building v5.3.201 for Mac (or even Windows), but again my hopes for building the AU (and the VST's?) are rather low.

[Godlike-Productions]

I'll add the list @dobo365 has provided and fill it in as info is posted.

@bijlevel, if you get a chance, can you please send through the OSX binaries, and I'll add them up as requested by @damiensellier .

The page is still very much under development. Send me anything that you'd like linked or hosted and I'll try to get them up over the next week. I'm thinking of using the page for a bit of a FAQ/Starting page to link to popular and useful resources.

[shooking]

Good stuff. I got this working a while back but what stopped me from publishing was the fact that the Jucer seemed to require and absolute path rather than a ..
So say one makes a pull request, hacks the Jucer, generates new one then tries to check the code back in one is overwriting the Jucer.

I wonder if we could agree that Windows builds go in say c:\Ctrlr
Or any other place (the subst command can make R: map to a path).
I figure C:\Ctrlr is as good a root as anywhere? Or better still
c:\Ctrlr\master
c:\Ctrlr<>
Then the Producer can be consistent.
On Linux/Mac a ln -s solves this. Windows is always so special.

Anyhow neat write up.

[bijlevel]

@shooking I'm not sure if I understand what you mean. When building CTRLR with Visual Studio 2019 (started from Projucer) the resulting application build can always be found in the folder .../ctrlr-master/builds/VisualStudio2019/x64/
After the build you can move the application Ctrlr-64.exe to any place on your computer.

As I wrote in my v2 guide you have to set two Projucer paths to where some specific folders are located in the ctrlr-master folder. So nothing special about that, I think.

[shooking]

Been away from Ctrlr for a long time. I got too frustrated by lack of basic version control by Roman. Sorry - but read thru all majority of comments ... Folks are desperate for proper releases, consistent build instructions and then proper peer reviewed commits can happen!! In short the community need permission and capability to take Control of Ctrlr else it's dead.

I am(was) a professional C++ development for US and EU software companies. My interest was in porting to the Pi (which I did) then getting that checked in as an official build (which I couldn't manage). Ctrlr itself is well matched to Pi Zero etc as midi/UI controllers for gear. But no official coordination inspite of some decent folks. Not meaning to piss on anyones parade here. Just not getting any younger and need to spend my time where I can get progress on my interests.

Anyhow back to Projucer. I ported Dexed to Pi4. Similar concept to Ctrlr BUT their admins at least welcomed Pi branch :-). In both cases one has to download Projucer - and that insisted on later versions. When you build for Pi you need to add the atomic lib. When you use build producer to generate makefiles the tool now insists on an absolute path. The older versions used by Ctrlr are more lax. But newer ones need to be nailed down.
Hence instead of c:\users\shooking I figured c:\ctrlr\version might make sense. I figured similar symlinks could work on Linux / Mac. Consistency in design can really simplify software (automation, build, test, understanding).

But I sort of gave up on Ctrlr for more advanced stuff and just wrote my own GUIs (basic but work) in TkInter using mido and python-rtmidi. Can debug with Microsoft code on Pi4 (or remotely). Can control midi interactions directly from code. No need to worry what version of what unstable build I am using. Can add in physical controls again via Python libs.

I truly hope Roman can find the time to update to latest Projucer (although didn't Jule's team quit?), Version the bloody releases, make these based on branches and allow keinstein, dobo365, dnaldoog etc check stuff in. My limited panels (k1r, k4) only work on certain versions of Ctrlr and it's just too complex to work out compatibility - it shouldn't be that hard!! Rant over. Wishing you all best of luck in new year to get the control of Ctrlr that any viable community would need. Try Python if you don't get this.

[Godlike-Productions]

Windows Binaries available here

https://godlike.com.au/index.php?id=361

I'll keep this page updated and continue to develop.

[bijlevel]

Looks good, but at least I expected some credit :-(

[Godlike-Productions]

I have more work to do on the page, including credit. Sorry. I've just been travelling for 7 hours. Will do more work tomorrow.

[14bitMIDI]

Tried the x64 standalone here on Win10 machine and simple demo panels from Roman opens fine but more sophisticated panel with lots of Lua stuff in it and Look and Feel crashes on opening. No crash log whatsoever so it is hard to say what the cause was. I will need to test some more with more panels this coming week! Build for OSX would be also good to check the same panels on both platform so if anyone have a working one feel free to share so we can use it for some testing work.

[bijlevel]

On Mac this version of CTRLR did also crash immediately, but after emptying the ctrlr folder in 'users/yourhomefolder/library/preferences/ctrlr/' all went well, also with panels having much Lua stuff. So this may also help if you are on windows. But beware: before you do this, save your panel(s) as bpanelz with resources because, on Mac for sure, in that folder are also the resources and they also get deleted. How to find this folder on Windows, see discussion #188. Of course I'm not sure if this is the cure, so it can go wrong!

[damiensellier]

@bijlevel good to know this trick. I'll try as soon as @Godlike-Productions will make the MacOS version available on his page.

[Godlike-Productions]

OSX Binaries are now uploaded, as well as @bijlevel's compilation guide.

https://godlike.com.au/index.php?id=361

[damiensellier]

Yes I did but it doesn't change anything. I think it's more related to the script itself. Nevermind I'll remove some lines and add-up them back until I find the culprit :)

[damiensellier]

Edit: Well I think you touched something with your suggestion.
If I comment the following line, the method is going through.
panel:sendMidiMessageNow(CtrlrMidiMessage({0xC0, 0x01}))
Did something change about the way to send messages? This used to work for years.

Also I have a : tonumber() higher in the method to convert a string to an Integer, it is prompting an error as well. Once commented It goes through too.

[Godlike-Productions]

Yeah that line is the table. Either make them a string CtrlrMidiMessage("c0 01") or a memoryBlock. That table format is exactly what breaks it.

Dunno about the tonumber thing. Maybe try toNumber(), or you may need something in the brackets. I haven't used this function, I don't think. It's only really important for converting to and from strings. All number formats automatically convert (ie hex to dec, to octal to binary, float, int etc). LUA does it on the fly.

[damiensellier]

Thanks I'll update my code to comply with that for the new versions.

[bijlevel]

Emptying the content of the ../ctrlr folder in the user library ONLY helps if Ctrlr crashes immediately after loading a panel, without error messages. At least that is my experience.

The error messages @damiensellier is getting, are discussed extensively in the issues section of this github.

[Godlike-Productions]

A new version (Release rather than debug) version of the OSX binaries are up, as well as another guide by @bijlevel on how to compile under OSX Mojave.

https://godlike.com.au/index.php?id=361

[Godlike-Productions]

The changes I made to get my Jupiter Panel to run in 3.4.201 seems to make them also work with the VST and VST3 in 3.6.26 on Windows (albeit the replaceWithText needs the "\n" added in the latter version)

[bijlevel]

Are you sure about the version numbers?

[Godlike-Productions]

Sorry 5.3.201 and 6.0.26 should have been the version numbers

[damiensellier]

Hi guys, so here is my insight about compiling for macOs.
I tried every version using the projucer. Some 5.5 builds are working but 5.6 don't (errors while opening with : CtrlrMidiDevice::open device failed to open midi device). But all the versions I had have the exact same issue with the vst3.
The ctrlr.vst3 is working great itself, you can run panels within cubase etc but if you export instances or restricted instances, those vst3 are not renamed properly with global "name" and "author name" for vst vendor, so the exported vst is still seen "ctrlr" and "instigator" by the host. There's conflicts between the exported instance and the original ctrlr.vst3. #394

Ideally I need the exact same mac vst as in the official 5.3.198 which is bulletproof. My only problem with this version is that the header space of the .vst is not compatible with the Pace iLok wrapping tools.
Is it possible to expand the size of the header space outside xcode to fit my needs?

I have no idea how to build an older version from the repository, I downloaded the ctrlr 5.3.198 [8b32662] binaries, with the old Juce, I could compile the standalone and the AU because the .xcodeproj are in the folders but not the .xcodeproj for the vst.
If someone could help with that that would be awesome! Just let me know we could arrange something.

Damien

[damiensellier]

Hi @bijlevel I tried to compile the audiounit following your guide. xcode succeed but when I run it in studio one it doesn't load. The version you uploaded to godlikeproduction website is working though. Did you make something special to make it work? Is it with juce 6 or 6.1 and Ctrlr 5.5.9, 5.6.0 or the latest master branch ? (I'm lost about this versioning). Could you please share your .jucer file if you changed something from the one in the repo.? thanks in advance

[shooking]

Ok so you own the fork. This also allows you to grant differing access to people. If you check out my ZoomPedalFun on git I ask users to comment on Issues. I created wikis etc to summarize the various SysEx that I reverse engineered.

Now in terms of documentation Doxygen can help a lot here. Also vim tags are pretty neat for navigation (I created my own with the Ctrlr). I would love to contribute port to Raspberry Pi 4 - but I need to make time next year to build from this fork.
Would-be great if you add whomever has been working out builds to check-in new read me. I still think it is worth considering default locations for Windows and Linux builds.

Some set of panels that major check-ins should verify works (@dnaldoog has made plenty of demonstration panels). I know the memory blocks is something that fundamentally changed between 5.3 and 6.x

I might suggest branches for these pivotal releases. Since we have panels that work well on 5.3 and other that work on later - but the branches don't seem compatible.

I am in a UK timezone. Can build on Windows, Pi4 and Linux - don't have a Mac.

[dobo365]

Thx Damien and the others!
I can work on the wiki and put it there many things I saved in my Step by Step guide v2.0. From there I can complete it further.
I you guys decide on how it should be done (I mean, with which tool), I can learn it and start documenting (first proposing you a structure then starting to write text). I would also like to have at least one reviewer defined and I think that John (dnaldoog) would be perfect in that role.

I can also look at the Ctrlr code as such but I'm not familiar enough with C++ or C# if this is used. However I'm quite good at programming. There are a few things I'd like to get improved from 5.3.201 and if they are not yet in the last version then I can look at it and propose a solution to one of you expert in the languages.

In relation with coding, is there an instruction for dummies on how to make a running Ctrlr version on PC with Visual Studio 2019? If I need to use XCode, fine as well, just tell. What I want to highlight is that the instruction should really explain what to do step by step (including a description of the why), starting from the different downloads (CtrlrX code, Juce, other libs...) up to the final build.
The most important for me is to understand where the files are, what I can modify and show you without destroying the original code.
I know this is done with the commits and co but tbh, I don't understand yet this collaborative way of working, so I'm afraid to do wrong things. Maybe that we should have some simple Ctrlr "Hello world" project where newcomers can learn the basics with a fake project but including all the key components of Ctrlr (CtrlrX code, Juce, other libs...).

You are speaking about a version 5.6.23 but where is it? The latest is 5.5.9 and 5.6.0 is pre-release.
Shall we work from CtrlrX proposed by Damien?
@damiensellier, maybe you can open a new topic and define guidelines on how to work on CtrlrX.
For example, what shall I do if I want to work on the wiki, what shall I do if I want to look at some stuff in the code

I keep watching this thread with great interest.
Happy New year to all...Dominique

[bijlevel]

If I'm not mistaken I have made a guide for how to compile Ctrlr with visual Studio 2019 😉. It was the start of this thread...

[shooking]

@bijlevel - genau. But until it's linked via README.MD to some wiki page likely folks will miss it.

Similarly with FAQ.

Finally regarding the versions my take is unless something is released it isn't really a version. It is just the current state of a build. If people want releases (and it is a great idea) they need to be annotated in the code. Either an official release, new branch or even totally new fork. Otherwise we get to the situation we find ourselves in. Impossible to know if we are building the same thing.

So my suggestion is folks raise issue like "I want to contribute build instructions", owner grants them wiki permissions, they update it, some folks test instructions for a given version - this becomes the way ahead for building until mistakes are found (and corrected) or new release comes out. Keep the old instructions for building v X.

Finally I don't know what the legal position is regarding JUCE. Dexed has a link to get Projucer. If you want to use it you need to register own account, explain it is non commercial open source, then you can download it. But don't know if you can check it in. Hence the version of JUCE foe generating the projucer needs to be agreed upfront IMHO. My experience is Dexed got it right. With Ctrlr is was never clear.

[damiensellier]

Hi, I started sending invites for collaboration on the CtrlrX fork.
I'll prepare a welcome page and some guidelines on what to expect from this fork asap. but to sum it all up, we will do ONLY there what we can't here without the required credentials, nightly updates, official releases, wiki, tutorials, sample panels etc

@dobo365 Dominique, I was also confused about the versions here, just for the info, the current master version is 5.6.23 and uses the official latest Ctrlr 5.5.9 version (I know it's confusing) Juce 6.0.8. Build with Projucer 6.0.8 it's working great. Some code is deprecated so it requires some cleanup.

@bijlevel I sent you an invite so you'll be soon able to add your "How to build Ctrlr" on a wiki Page.

[Godlike-Productions]

Thanks for the invite. I've accepted. I'm happy to do some work on the wiki. I have quite a bit of experience with them. I'm 99% sure I have a Juce account, but it's been a while since I've played with it.

[bijlevel]

I had to adjust the compiling guide for MacOS a bit, because of some minor changes (for the good) in the latest source. (If I'm not mistaken, for example the issue of the missing menubar in an exported restricted VST3 instance has been addressed...). You can find the guide (v2) at https://godlike.com.au/index.php?id=361

[bijlevel]

If I'm not mistaken, this vst2sdk does come with the ctrlr-master zip. It's in: ../ctrlr-master/Source/Misc/vst2sdk. You're right though about pointing Projucer to the right folder, because default the field in Projucer is empty.

[shooking]

Which is I why I was asking should a standardised directory be made? Then the projucer points to fixed point.
I download the fork today - I only had the 2022 Windows community edition. The projucer one can build from the branch supports up to 2019. Not sure if Steinberg would be happy with a sdk3 being cloned into the git? My problem with windows build is compiler was on C.but ctrlr was on F - relative paths get messed up. I think inwill stick to Linux and Pi builds. My C drive is getting full.

[damiensellier]

@shooking I like the idea of a standardized directory path too. Either with SDK at the user root or all the directories in user documents/GitHub/ like it's recommanded with the github desktop app

[bijlevel]

I'm not sure what is the problem with the directories. I don't have problems with it, not on Mac and not on Windows. Whenever I download the source as zip I leave it on my desktop and only make sure (copy from my guide): Start Projucer and then check the first two global paths settings. They should point (by default) to the downloaded JUCE folder. But maybe I'm not understanding the issue.

[shooking]

The sln and projucer files often get checked in. So unless they are in a gitignore (haven't checked) they get updated by each upload.

If these generators were standardised then no need to modify them. On Linux it's easy to use a sym link. Sure you jave junctions and subst on DOS. Doesn't work as well as symlink.

The later projucer insists on a fixed rather than relative path. Hence the idea of a suitable fixed point.

[damiensellier]

Hi guys, I am currently building plugins for Win10 and I had to compile Ctrlr with visual studio 2019.
I followed the guide which was a saviour.
I experienced some errors though, sometimes it works sometimes it doesn't and I don't know why because it's exactly the same setup (welcome to the pc world)

I have this error which stops the process for a long time:
1>Generating code
1>C:\Users\Damien\Documents\Ctrlr\CTRLR Build\ctrlr 5.5.9 f452347\Source\MIDI\CtrlrMidiInputComparatorSingle.cpp(239): warning C4702: unreachable code

and after 10 minutes it goes ahead but only once out of 5 it works.

Any idea what's wrong with CtrlrMidiInputComparatorSingle.cpp?

ctrlr/Source/MIDI/CtrlrMidiInputComparatorSingle.cpp

Line 239 in f452347

for (int j=0; j<cache[i].mapData.targets.size(); j++)

Also I experienced :

c:\users\Damien\documents\ctrlr\ctrlr build\ctrlr 5.5.9 f452347\source\uicomponents\ctrlrlua\methodeditor\ctrlrluacodetokeniser.cpp Line 1 Compiler is out of heap space in pass 2 Fatal error C1002

I don't know what's going on and how it's possible for a computer to succeed in its duty randomly like this.

Thanks for your help

[shooking]

So you are running out of heap when you compile - the compiler itself crashes and you get no binary. Heap is dynamically allocated memory - so maybe your PC has a lot going on and runs out of memory?

The code not reached - say you have

return 10;
More statements.
The more statements are never reached because of the return.

In your case there is a for loop and if looks to me it is reachable. I guess if the size is unsigned and gets cast to int then there could be a negative number that is less than 0, so that rhe for loop will never run. I will try to make.some time to follow what you are doing.

[shooking]

Actually I see from subsequent post that MS starts with 32 bit linker. Runs out of space (boy that's say 2GB of heap - something very silly happening there. Recursion? Precompiled headers? Then it decides to switch to the 64 bit linker. That has a lot more potential ram. If you run out it might page and swap. A fast SSD or NVMe would help. Used to hit stuff like this on the Pi3. With the Pi4 and 8GB one gets less compiler errors. Would probably be good to ask Windows to build 64 bit because the OS is 64 bit nowadays.

[shooking]

ok I have an old pull from July. Builds

  F:\CtrlrX\Source\Misc\libusb\src\windows_usb.c(837,7): warning C4996: 'GetVersionExA': was declared deprecated [F:\Ct
rlrX\Builds\VisualStudio2019\Ctrlr_SharedCode.vcxproj]
  F:\CtrlrX\Source\Misc\libusb\src\windows_usb.c(840,8): warning C4996: 'GetVersionExA': was declared deprecated [F:\Ct
rlrX\Builds\VisualStudio2019\Ctrlr_SharedCode.vcxproj]
  F:\CtrlrX\Source\Misc\lua\src\lua.c(15773,16): warning C4127: conditional expression is constant [F:\CtrlrX\Builds\Vi
sualStudio2019\Ctrlr_SharedCode.vcxproj]

    58 Warning(s)
    0 Error(s)

Time Elapsed 00:01:42.25

Used 12 threads nicely and 12GB RAM. I also have installed the 64 bit version of the Visual Studio 2022 but added the VS tool chain for 2019 64bit. My guess is you run out of RAM, hence fails except when fewer tasks are running.

Taking a look at the code - it seems the MS static checker doesnt like the size operator?

  CtrlrMidiInputComparatorMulti.cpp
F:\CtrlrX\Source\Lua\CtrlrLuaDebugger.cpp(62): warning C4702: unreachable code [F:\CtrlrX\Builds\VisualStudio2019\Ctrlr
_SharedCode.vcxproj]
  CtrlrMidiInputComparatorSingle.cpp
  CtrlrMidiMessage.cpp
  CtrlrMidiMessageEx.cpp
  CtrlrOwnedMidiMessage.cpp
  CtrlrLinux.cpp
  CtrlrMac.cpp
  CtrlrNative.cpp
  CtrlrWindows.cpp
F:\CtrlrX\Source\MIDI\CtrlrMidiInputComparatorSingle.cpp(239): warning C4702: unreachable code [F:\CtrlrX\Builds\Visual
Studio2019\Ctrlr_SharedCode.vcxproj]
  CtrlrProcessor.cpp

the both have similar coding style

std::string CtrlrLuaDebugger::dbgRead(std::string prompt)
{
    if (pendingBreakpoints.size() > 0)
    {
        for (int i=0; i<pendingBreakpoints.size(); i++)  <-- size is actually returning and int        {

with declaration in ArrayBase.h

//==============================================================================
    /** Returns the current number of elements in the array. */
    inline int size() const noexcept
    {
        const ScopedLockType lock (getLock());
        return values.size();
    }

The const just means that this doesnt modify values.size().
values is a JUCE array. Which itself is also an int (normally size operators can be size_t so 0 to largest value a pointer can hold)

    inline int size() const noexcept
    {
        return numUsed;
    }

and
int numAllocated = 0, numUsed = 0;

So it's int's all the way down. So unless the compiler believes numUsed is always 0 then I say the code seems to be reachable.
Stick a break point inside the loop - if you hit it then it definitely is used!

Get more RAM or use a 64 bit compiler to avoid the heap exhaustion.

[shooking]

Ok I think I get it.

Let's examine the original code (239)

	Array<CtrlrCacheDataSingle>	&cache	= getCache(type);

	for (int i=0; i<cache.size(); i++)
	{
		if (cache[i].key == number)
		{
			for (int j=0; j<cache[i].mapData.targets.size(); j++)
			{
				if (cache[i].mapData.targets[j]->getMidiMessage().getChannel() == channel)
				{
					cache[i].mapData.targets[j]->getProcessor().setValueFromMIDI (messageContainer);
					return (true);
				}
				else
				{
					return (false);
				}
			}
		}
		else
		{
			return (false);
		}
	}

Looks good. But wait.

So you have a cache that say has 10 messages 235.
for i in 0 to 10
line 237 we ask "is this key the number we are looking for?"
Let's say it isnt ... so we know the first cache's key isnt the number we are looking for.
so we drop to line 252 (the else)
and we return false ... so we NEVER check the i < cache.size() because we bail on first time thru the loop.
Bit off tha the SAST tool doesnt complain there

So now apply logic to the inner loop.

At line 237 let's assume the 1st message's key IS equal to the number.
We reach line 239 and we loop a new variable for that size of that cache;s mapData.targets.

What could go wrong?
We check at line 241 is we have the right channel. If we do, we set a processor, and return TRUE
So we NEVER get back to the for loop at line 239.
Ah but wha if the channel isnt right?
we return false, and we NEVER get back to line 239.

Nice spot - this indeed does appear to either be a bug or pointless code!!!

My guess is the else from line 246 0> 249 shouldnt be there.

We should loop thru the caches.
if the key is the number we are looking for then ok ... not go thru the targets' size.
if we find the right channel, set it and we are out of here.
so both of the return (false)'s inside the loops appear to be coding error.

My 2 cents.

Probably similar on the debug. Yup

    if (pendingBreakpoints.size() > 0)   <-- [pointless check?? if the size was -ve we would not run the loop below [[check my C is a bit rusty!]]
    {
        for (int i=0; i<pendingBreakpoints.size(); i++)  <-- so here we walk the breakpoints.
        {
            PendingBreakpoint pb = pendingBreakpoints.removeAndReturn (i);  <-- what does this do?

            if (pendingBreakpoints.size() == 0)  <-- nasty. are we playing with the loop variable??
            {
                commandQueue.add ("run");
            }

            if (pb.shouldBeSet)
            {
                return (_STR("setb " + _STR(pb.line) + " " + pb.fileName).toStdString());
            }
            else
            {
                return (_STR("delb " + _STR(pb.line) + " " + pb.fileName).toStdString());
            }

<-- we dont get here so the above loop doesnt make any sense??
        }
    }

[damiensellier]

@bijlevel I have exactly the same log as yours. So it's definitely not just on my side.

@shooking I think you are spot on.
You explained the logic behind it very well. I'm a C++ noob and can understand but I have some issue with the syntax.

I use visual studio 2019 on my mac mini 16Gb of RAM with Win10 x64 on a bootcamp partition. So the loop probably overloads the cache.
I could go through several times but it succeeded randomly only after switching to 64bits which can allocate more memory.
In the end, I have my compiled VST3 and .exe but I had to try several times before it worked for the different reasons posted above. On mac Xcode doesn't get those warnings anyway.

If you could post the fixed portion of the buggy code, I would try it right away and if it's working OK I'll pull it to my Fork for future updates.
Let me know ;)
Thanks a lot!

[shooking]

Something like this - I added some comments - some folks object but well it makes it reasonably clear what the algorithm is.

I havent touched the debugger file yet - I am certain something peculiar is happening there but in this case it seems control logic error.

bool CtrlrMidiInputComparatorSingle::cacheMatch(CtrlrMidiMessageType type, const int number, const int channel)
{
	if (type == SysEx)
	{
		return (cacheMatchSysEx());
	}

	Array<CtrlrCacheDataSingle>	&cache	= getCache(type);

	// walk the caches
	for (int i=0; i<cache.size(); i++)
	{
		// did we find key we are looking for?
		if (cache[i].key == number)
		{
			// walk the targets mapped data
			for (int j=0; j<cache[i].mapData.targets.size(); j++)
			{
				// did we find the channel?
				if (cache[i].mapData.targets[j]->getMidiMessage().getChannel() == channel)
				{
					cache[i].mapData.targets[j]->getProcessor().setValueFromMIDI (messageContainer);
					return (true);
				}
			}
		}
	}
	return (false);
}

Computers are funny. If you run out of memory then they can still page and swap and often (slowly) get a result. But running out of heap is rarely recoverable - certainly not if the heap and stack smash thru eachother!

I would consider using the 64 bit all the time. On Windows you can open a Visual C 64bit dev window.
Then from the prompt:

REM open Developer Command Prompt for VS 2019 
REM I am using VS 2022 with VS 2019 build env
REM this is a 64bit env

set MYCTRLR=F:\CtrlrX\Builds\VisualStudio2019
cd %MYCTRLR%
msbuild Ctrlr.sln /t:clean

msbuild Ctrlr.sln /t:build

go sip your brew :-)

There are some "hides" warnings that I will try to look at. The debug warning.
Some deprecated warnings - they will break in a future compiler or on a different OS.
Quite a few conversion warnings that will eventually break.
These are mostly in LUA bindings.

I am not aware of unit tests for Ctrlr. I booted a panel up with the above hack and it ran.
I used the GUI to add a breakpoint - didnt trigger it. I also found the IDE has some cross reference (we used to generate our own back in the day). Eventually the code gets called whilst trying to match cache data - makes sense. But I couldnt find an obvious route (and hence test) of the proposed code change.

I did try to copy the file (drag and drop). Edge says no.

[damiensellier]

This is for older Windows but shows the idea. https://youtu.be/0wgJmmbjI-g

Basically click the Windows button, search alphabetically and it should be under Visual Studio... not the IDE but a series of CMD prompts. NOTE generally you don't open normal cmd prompt - there is a way to make it into the compiler but better just to open correct prompt.

Look for 64bit native or x64. Once open type cl And this should return then version of the c compiler.

@shooking Hi Steve, I would like to hire you to debug a feature I added in my custom Ctrlr build. I don't have enough c++ skills to fix it.
It's like a 4 line code not more. You know Juce, you know Ctrlr and C++ so you are probably the right person ;) Is there a way to contact you? you can send me a message whenever you want. Thanks a lot. Damien

[shooking]

You don't need to hire me (I am no Spenser :-)).

I am shooking_miniak on Skype. I don't use Skype much but also I am in UK timezone. If we can find a sync point we can start from there. Generally I do stuff for free - my mother never learned me to be commercial.

[damiensellier]

lol thanks a lot @shooking, I'll get in touch with you via skype I just need to reinstall it :)
thanks and have a nice day mate

[dnaldoog]

This is for older Windows but shows the idea. https://youtu.be/0wgJmmbjI-g
Basically click the Windows button, search alphabetically and it should be under Visual Studio... not the IDE but a series of CMD prompts. NOTE generally you don't open normal cmd prompt - there is a way to make it into the compiler but better just to open correct prompt.
Look for 64bit native or x64. Once open type cl And this should return then version of the c compiler.

@shooking Hi Steve, I would like to hire you to debug a feature I added in my custom Ctrlr build. I don't have enough c++ skills to fix it. It's like a 4 line code not more. You know Juce, you know Ctrlr and C++ so you are probably the right person ;) Is there a way to contact you? you can send me a message whenever you want. Thanks a lot. Damien

Hi Damien - I might be able to help you with that C++ code

[damiensellier]

@dobo365 Thanks John, that's super kind! I will get my things together to make super easy to work on, and will let you both know about it. Thank you very much ;)