[Building Ctrlr] Visual Studio build not recognizing changes in CtrlrIDs.xml file

[dobo365]

Hi, as others, I'm also looking and digging into the Ctrlr code.
I'm on Windows with VS2019.

I have the issue that the changes I'm making in the CtrlrIDs.xml file are not taken into account in my builds.
This file is in Source/Resources.

You can make a simple test to correct a typo which is there since long ;-)
The text of uiPanelBackgroundColour2 is indicating Background colour [1]
It should thus be [2]
<id name="uiPanelBackgroundColour2" text="Background colour [2]" type="Colour" />

I have done previous builds successfully.
I change the file.
To be sure, I'm doing a Clean build which is suppressing the temporary VS build files.
Then, as indicated by Sjoerd, I'm building the SharedCode then the Standalone
Starting a new panel and looking at the properties is still showing Background colour [1].

I discussed this with Damien and he told me to restart from Juce and even to restart my PC between builds.
I cannot believe this is needed (I don't want to). Would be a crazy way to do develop.

Maybe that one of you has a suggestion/idea?
You can easily reproduce this issue by just changing the text of any property and check if you see the change.
Thx in advance!

[dobo365]

Extra info:

There is only one reference to this file in the .jucer file

        <GROUP id="{3E28051A-C67A-EB61-FFEC-E15E9C2440B2}" name="XML">
          <FILE id="sfPVqB" name="CtrlrIDs.xml" compile="0" resource="1" file="Source/Resources/XML/CtrlrIDs.xml"/>
          <FILE id="c2a7q2" name="CtrlrLuaClassTemplates.xml" compile="0" resource="1"
                file="Source/Resources/XML/CtrlrLuaClassTemplates.xml"/>
          <FILE id="l7AUOW" name="CtrlrLuaMethodTemplates.xml" compile="0" resource="1"
                file="Source/Resources/XML/CtrlrLuaMethodTemplates.xml"/>
          <FILE id="lTRutZ" name="CtrlrMidiMultiTemplate.xml" compile="0" resource="1"
                file="Source/Resources/XML/CtrlrMidiMultiTemplate.xml"/>
          <FILE id="o4T0m9" name="CtrlrMIDITransactions.xml" compile="0" resource="1"
                file="Source/Resources/XML/CtrlrMIDITransactions.xml"/>
          <FILE id="dO5K8X" name="CtrlrMIDIVendors.xml" compile="0" resource="1"
                file="Source/Resources/XML/CtrlrMIDIVendors.xml"/>
        </GROUP>

In VS2019, I checked the Properties.
For a .h file it is indicated Item type=C/C++ header
For this xml file is is indicated Item type= "Does not participate in build"

Maybe that the question is thus: how is this file taken into account? how come the changes are not taken?

I thought it was due to the Ctrlr app temp folder.
I have both 5.3.201 and my new Ctrlr on the same PC.
They are using the same temp folder.
So, I renamed my old temp folder and launched the new Ctrlr.
A new temp folder has been created BUT I have still the bad property name.
So, the Ctrlr app temp folder is not influencing this issue.

[damiensellier]

I checked all about that and it has to do with the fact those xml files have to be "Embedded binaries".

Embedded binarie are binary files that are copied to your application bundle when you build the project. Use embedded binaries when your application relies on third-party frameworks so people can use your application without needing those frameworks installed on their machine. Embedded binaries keep users from having to manually install third-party frameworks. Your application uses the framework you embedded.

I saw on Xcode there's a way to include those files everytime you build the project but I'm not sure about the right way to do with Visual Studio.

On my side with xcode everytime I modify those xml files I just need to remove the xcode project files .plist, .xcodeproj and libCtrlr.a, restart the projucer, save and launch xclode and it's all good to go, the next build has proper updated values.

Maybe that's a hint:
https://stackoverflow.com/questions/5978414/vs2010-autogenerated-xml-documentation-file-does-not-update
https://stackoverflow.com/questions/12182203/executable-not-rebuilt-but-object-files-recompiled
https://stackoverflow.com/questions/68768693/visual-studio-keeps-embedding-the-wrong-resource-file

I think that somewhere you still have some kind of a temp file used by VS that is not updated and it's not about the Ctrlr app cache or preference but about what VS uses to build the app.

Maybe it's also related to the resource folders of this particular project :
https://stackoverflow.com/questions/28066817/understanding-resources-in-visual-studio

[bijlevel]

@dobo365 I want try to help you out, but I need to make myself again familiar with compiling on Windows/Visual Studio and have to use my former iMac with Windows 10, because I have now a Mac Studio. This takes time, but I will do my best!

[dobo365]

Thx a lot @bijlevel ! Your Word document describing how to build Ctrlr and the good advices from Damien helped me to understand how to build. I have been looking a lot at the code and start to know what is where (I said "start").
Unfortunately, for the initial changes I wanted to do I faced this CtrlrIDs.xml issue...

FYI, I just bought a Mac M1 second hand so will need your M1 build and would also like how to build Ctrlr on Mac (will also take that with Damien)

[bijlevel]

@dobo365 I'm happy to send (or upload) the latest ARM build of CTRLR (including the mouseUp event), but FYI the Intel version of CTRLR does also run on a Silicon Mac, and I didn't notice any speed differences... (So you can already start making panels on your M1! )Tell me what you prefer.

[Ted-juh]

It won't help you a lot Goodweather but I can't reproduce the problem in my repository of version 5.6.23. The typo was there and I changed it to what it should be. Just to be sure, I saved it all, closed Visual Studio, saved the project in the Projucer, and reopened the project. Did a rebuild. The typo didn't come back.

That's on Windows, Visual Studio 2019, Ctrlr version 5.6.23 from April, 8th, 2021.

[bijlevel]

Same here. I did the same as Ted-juh (saving closing etc.) and the change was made.

[dobo365]

This is great guys. At least we know it is working!
What I have done is:

• change the code in VS2019
• save the individual file in VS2019
• Clean the build of Shared and Standalone
• Build Shared and Standalone
• Use the exe

So, I guess I'm missing:

• save ALL files (strange but OK, doesn't hurt) - don't think this is needed
• close VS (seems also overkill but why not) - not sure this is needed; maybe just close the project
• saved the project in Projucer: THAT ONE is maybe the missing thing. Since I have everything in VS, I was not using Projucer anymore.
  Do you mean that I should re-open the corresponding .jucer project and re-save it?
  Before saving I will check it contains the typo change that I made in VS.
• shall I re-export to VS or can I just close the Projucer?
• re-open the project in VS and do a Rebuild (Rebuild is first doing a Clean)

[Ted-juh]

I always start the project from projucer, open ide inside projucer and do my job, save all in the ide and close it. Then save all and save project in Juce. Just to be sure, not saying it is necessary.

I found out the hard way that it's mandatory to add a class in the projucer before doing anything in Visual Studio. But that's a different topic. Maybe it does something to the jucer file because else made changes seem to get deleted (?).

I know there's a way to leave the Projucer out of the equation but that involves CMake which is still acracadabra to me.

[dobo365]

I'll try that during the w-e.
Thx to all for your advice

[dobo365]

Amazing... Saving in Projucer then opening VS from Projucer made the trick.
Projucer must do something...
Thx A LOT to all of you!

[damiensellier]

@dobo365 @bijlevel @Ted-juh I'm really curious about how long does it take to buid Ctrlr with your computer?
It's so boring on my side everytime I hit the run button with my mac mini it takes 4min30'' to get the build done. I would go much faster to improve the program but right now It's preventing me from really digging into it seriously.
If I changed the code and it would take 30 sec i would be far more into it.
I'm thinking about getting a macmini M1 or M2 I'm sure it would be so much faster.

[Ted-juh]

Edit: I forgot to add the specs of my PC:
AMD Ryzen 7 7800X3D/ X670E Platform/ 192 GB Ram/ Windows 11/ Visual Studio 2019

Building the Ctrlr_SharedCode after cleaning takes about 42 seconds.
Compiling the Ctrlr_StandalonePluging takes about 3min35" after cleaning.

Depending on the changes I made in several files, without cleaning, building the SharedCode takes about 10 to 20 seconds.
It's the same decrement when compiling the StandalonePlugin without cleaning, it takes roughly 2min30",

From Stackoverflow:
[Build solution] Will perform an incremental build: if it doesn't think it needs to rebuild a project, it won't. It may also use partially-built bits of the project if they haven't changed (I don't know how far it takes this)

[Rebuild solution] Will clean and then build the solution from scratch, ignoring anything it's done before. The difference between this and "Clean, followed by Build" is that Rebuild will clean-then-build each project, one at a time, rather than cleaning all and then building all.

[Clean solution] Will remove the build artifacts from the previous build. If there are any other files in the build target directories (bin and obj) they may not be removed, but actual build artifacts are. I've seen behavior for this vary - sometimes deleting fairly thoroughly and sometimes not - but I'll give VS the benefit of the doubt for the moment :)

Back to me.
So all in all, just a "build" would be faster. Correct me if I'm wrong but I noticed just debugging to see if it runs can be faster if changes aren't made in too many files or after adding classes or linking. Then again, I only rebuild or clean (or clean then build) when I make big changes.

Question to you guys...
I noticed that GitHub Desktop wants to push all the changes made in the build folders after building the project. This doesn't seem necessary to me because one would have to build the project themselves anyway. Can I add the build folders to the gitignore file?

[damiensellier]

45 se. is impressive I'll try right now, I'm working on implementing the lookandfeel properly and it's on a very good way. V4 sliders look so much better, alsi it has the color picker popup which is really handy .

[damiensellier]

@bijlevel I always change the scheme depending on the targeted build type, did you change any particular settings in there?

[bijlevel]

I did not really change a scheme, but the scheme in Xcode 14.3.1 did not show a scheme for building the standalone plugin, only a 'CTRLR- all' scheme, which included the standalone, but also all the other build variations. So I added a new scheme, with only the standalone as a target and used that one for my timing. So now I'm happy, because the Mac Studio is indeed much faster.

BTW what are V4 sliders?

[Ted-juh]

@bijlevel ( or Mr. Sjoerd :) )

Damien is talking about the Look and Feel class from Juce. V4 refers to Look And Feel version 4. The one used in Ctrlr is Version 2, if I'm correct. If you compile the demorunner (Juce/ examples/Demorunner), a Demo panel will show you what the Look and Feel classes look like.

On another note. In Ctrlr, panel mode, panel properties, you can choose a different LookAndFeel version for the panel (Almost at the bottom.). But it doesn't seem to work for me because Components still show L&F V2 regardless of which version I choose.

[bijlevel]

@Ted-juh (or is it Mr. van Es ;-)?) thanks! Runnng this demo is a real eye opener! Now I whish for V3 or (maybe better) V4. Could have saved me a lot of image sliders and buttons (and for that, time!) (But if @damiensellier hurries up 😋, we can soon enjoy V4!) And yes, choosing a different L&F version doesn't change anything at the moment.

[damiensellier]

On another note. In Ctrlr, panel mode, panel properties, you can choose a different LookAndFeel version for the panel (Almost at the bottom.). But it doesn't seem to work for me because Components still show L&F V2 regardless of which version I choose.

Yes, exactly! https://docs.juce.com/master/classLookAndFeel__V4.html
I'm working into updating the GUI from the 2 drop downs in the property pane. I'm fed up because I wrote clean code but some repaint or lookandfeelchanged() crash my mac. I don't know why. And every little correction requires an extra 5 minute to verify. It's not WYSIWYG at all. It's working well for the canvas, menubar, propertypane but sending the lookandfeelchanged to the parents component of the property pane crashes the app. I know why romanKubiak gave up on it, because I'll need to update every single component class, so that the look change accordingly. In the code Roman commented (which is not often) "Crashes on MAC...
I'll prepare that lookandfeel_v4 update so that the version v6 of ctrlr gets every little improvements we talked about and already done.
That will be nice to have an updated and unified version with macOS silicon etc

EDIT: currently, ctrlr has a mix of LookAndFeel_V3 with a rest of LookAndFeel_V2. All modulator components' styling is hardcoded as overrides. the best would be to unify the styling for every component and allow other default color scheme.