- This topic has 27 replies, 4 voices, and was last updated 3 years, 6 months ago by
.
-
Posts
-
Hi,
as opuswerk in another old post but for macOS, I would like to learn how to build Ctrlr on Windows (32 and 64 bits), standalone and dll (32/64 bits).
I’m new in all those new tools like Code Blocks, github… but learn fast and have engineering/IT background.
@atom (or other) hope you can help and guide me.What I did so far:
– I have a Win10 64 bits PC
– downloaded and installed github desktop
– cloned the ctrlr project
– downloaded and installed Code::Blocks
– opened the Ctrlr.cbp file and I can see all files in Code::Blocks
…don’t know what to do next… will complete successful steps here 😉About the build, my questions so far:
– is Code::Blocks coming with compilers (seems not)?
– which compilers and libraries do I need to install to build Ctrlr? C? C++? Juce? others?
– is Code::Blocks better for Ctrlr development or is Visual Studio 2017 better or it doesn’t matter?My plans:
– restart from 5.3.201 and first try an easy change that I can see the effect
– learn how Ctrlr is built, coded and assembledThx atom for all your great work!
Wouldn’t it be easier to install something like VMware and an image of Mac os instead of going for the cross-compile route? To my knowledge code::blocks works better on osx than it does on windows. Because on windows, visual studio seems to be the way to do it. And that way, you can even test it.
On the ctrlr GitHub, there are some hints how to compile it for different operating systems.
I’m trying to get my head around Juce to see if it’s doable to add classes to ctrlr. Better start at the source, right? I do the recompiling with visual studio community (free) with a free Juce and with some effort was able to build a small GUI.
Wanted to recompile the ctrlr repository this week (3 week’s vacation) to do the same like you want to do.
Sorry, double post. Forgot to add that you can compile it by going to the “build” folder and choose the right OS and program which you want to compile with.
Thx for you answer! I’m not looking about compiling on/for MacOS at this stage.
So, just a beginner on this build and compile stuff and I’m on PC.OK. So, I will follow your advice and install Visual Studio instead. I used it 20 years ago 😉
I took Code::Blocks because the files in the Builds folder are more recent for Code::Blocks than VS2017.
As you took the VS way, I wil do the same and from there we can help each other.When going to the Build folder, there is a .sln file for VS and a .cbp for Code::Blocks.
I opened the .cbp and as said above I see all the files in the project. FineThen how do I compile all that stuff? Don’t I need first to install some librairies (Juce…) or…
This was my question with my post 😉I want also to learn to identify the changes made in each version since 5.3.201 and want to have a starting project as 5.3.201 because this is the only version I trust at the moment (even if I’m sure that more recent ones brought nice stuff but from what has been written, also destroyed some working stuff).
I installed VS2019 and cloned the ctrlr git from within VS2019. Went fine.
Got errors when loading the .sln file from the VS2017 folder.
Are you using VS2019 or shall I install VS2017 to be sure to be compatible with this .sln file?
Thx for your helpSorry, thought you were trying to compile CTRLR for Mac os, but I see you were talking about an old post. I thought I might give it a go as well to try to compile CTRLR. For your information.. I’m using visual studio 2019. At installation, I only selected the “c++ for desktop” and made sure the windows SDK 10 was selected. (I needed it for JUCE to compile, that’s working. Doesn’t necessarily mean it works out of the box for CTRLR.)
The JUCE Library is downloaded when you download the CTRLR repository. You can see an older (this is 5.1.1 whereas JUCE is now at version 6.01) version of JUCE in the conveniently named JUCE folder.
Ok, after some messing around. When I download the CTRLR repository, there’s only a visual studio 2017 sln file. But when I download the stable CTRLR branch, there is a visual studio 2019 sln file. Both throw errors about a stdafx.cpp which I didnt’get around yet. There’s a mention about it at the CTRLR github under compiling for windows, but I do not understand what it is saying:
“You need to set the creation of the precompiled header for the stdafx.cpp.”
To compile it, at the top there is a x64 debug, with next to it “select startup item”. I’m wondering why I can’t choose x64 release instead of debug. I select ctrlr.exe for startup item. No dice either. So.. that’s as much as I can help you for now.
There is an old thread about the stdafx.cpp file..
Good that we are doing the same 🙂
But I didn’t reach very far…I had also installed VS2019 with the C++ desktop and SDK Win 10 (just checked). So there we are aligned.
I cloned ctrlr in 2 ways to my local PC and both are giving errors that I don’t understand what to do…1. From within Github, I cloned Ctrlr with Github Desktop and I have thus the folder structure on my PC.
When opening the VS2017 .sln file in Builds, I get 3 errors in the output window claiming for missing files (Documents\GitHub\ctrlr\Builds\VisualStudio2017\Ctrlr_StandalonePlugin.vcxproj, Documents\GitHub\ctrlr\Builds\VisualStudio2017\Ctrlr_VST.vcxproj, Documents\GitHub\ctrlr\Builds\VisualStudio2017\Ctrlr_SharedCode.vcxproj)
This is from the master branch.I can see the different branches and see the stable; Exploring a bit VS2019 I saw I could get the history of the stable branch. There in november 2019 you can see there is a folder VS2019 with a .sln file in it. It also contains the msising files I’m mentioning above.
What shall I do to use that stable branch? Fetch? Create local branch from?
How to get this stable as starting point in another project?2. From VS2019, I cloned ctrlr and it has been added to my local Git repositories in Sources\repos
When I want to switch to the stabe branch I get a message “Cannot switch to the stable branch because there are uncommited changes”
All the changes are in JUCE/Extras and JUCE/Doxygen directories.
What is happening if I’m doing that commit? Is this happening only on my local version?
Don’t want to mess up with the official Ctrlr.
I want to only work locally on my PC.Thx for your help.
Will try to find some YT video on VS2019 explaining the branches, ways of working, commit, history navigation, retrieval of previous versions, etc…I think it would be a good idea to start with 5.3.201 but that will probably be difficult. If I remember well it was built with vs2013. So you would have to use this version of visual studio. And you need some other things like the boost library https://www.boost.org/. Is at least v5.3.201 still available on github?
I think it does not make a lot of sense to just always upgrade to the newest version of Juce. You would have to implement the new features of Juce in Ctrlr in order to get some advantage out of the new version. An example of what I mean is the new design of the uiButton. It may be nice but it does not fit always. You would have to be able to go back to the old design. I think there is no doubt that this would be possible if implemented correctly. If this is not possible I would prefer an old version of Juce.
Because 5.3.201 is the stable version, I thought it was indeed better to start with that version and go from there. But there’s some confusion about how to get that version from GitHub.
There are different branches. Master, stable, lua bind cleanup and testing. I can see they differ from each other because of missing commits but I can’t download a different branch. It’s only the master branch that has a download. And there are tagged versions of which 5.3 (not 5.3.201) is one of them. But that one is from 2014 (?). (Would explain the use of VS 2013) Those tagged versions have downloads as a zip file. But somewhere around 2018, when Steinberg dropped support for vst2, an updated version for Ctrlr was released. I can see some files were deleted and changes were made.. but no branch or tagged version to download.
AFAIK the Juce version is an old version that is being downloaded. Already downloaded boost and tried to follow the instructions for compiling the GitHub repository. But I get errors that go way above my pay grade.. so far no luck.
Hope Goodweather has more luck..
I have exactly the same reasoning as you Tedjuh. 5.3.201 is the starting point to reach and from there we can start implementing small changes / bug corrections. I have myself no intention to implement a new version of Juce. Just to correct some boring bugs and to implement the explanations of all properties (we have links but no explanation).
@Tedjuh, did you look at what I wrote as problems/questions? Any clue or hints.
Will follow some VS2019 YT training videos to understand branches and history.I didn’t mean that you shouldn’t implement new Juce versions. If I get it right the most important changes from different Ctrlr builds were the use of new Juce releases. THIS I think does not make a lot of sense, well it may if they fixed bugs in some Juce code but it can be counterproductive when the new Juce is not fully compatible with the Ctrlr code.
I think I remember now, that v5.3.201 was done with VS2010. Some time ago Roman made the jump from 2010 to 2015. Maybe that was the mistake I made when I tried to compile Ctrlr some years ago using VS2015. I think I should have tried VS2010. After a long time not exactly knowing what I was doing I eventually gave up.
@ Goodweather:
Well, the branches and history thing is actually a Github thing. But basically it comes down to this: The Master Branch is usually the one that should be compiled to get a working version. Other branches are to try out code or to make changes outside of the Master Branch, test them.. and when it’s working they could be merged in the master Branch. So, when working with different people or different ideas for changes, that’s as many branches you can have. Every time a change is made, there is also a history being created to make it easier to revert back to some older version.
What’s happening here is that the “Master Branch” is version 6.0 but the “Stable Branch” is also version 6.0. So this led to some confusion on my side on how to get version 5.3 and preferably the updated (or rather said, downgraded) version without VST2. I think I got it and here are the steps to get it:
Go to the CTRLR repository on Github. You’ll see it’s the Master Branch and underneath it says that the last commit Roman made was CMake: initial Cmake import. Further to the right, there’s 726405f (I guess this is a history number from Github) dated January 28, and there are a total of 526 commits.
— Click on Master and change it to Stable (The number of commits in the blue bar changes to 577).
— Click on the “577 commits”. It will open a page with all commits that were made during the development of Ctrlr.
— Scroll down and click on older to go further back in history.
— Then scroll down to June 14, 2018. Which says: Removing VST SDK due to Steiberg takedown (click the dots at the end, couldn’t agree more).
— To see the code from that date, click at <> next to the version number dee3e52.There you have it. June 14, 2018. And when you click the green Code button, you can download the commit from that date as a zip file to do things locally. This has Ctrlr file version 5.3\0 (Ctrlr/Builds/VisualStudio2017/resource.sc). But this is without the VST SDK. Now when you go back to Commits (or history), on August 31 2018 it says “VST3 support Added”. But this is Ctrlr file version 6.0. Maybe Roman’s reasoning behind it was that it was some sort of new version to build from. But I think I need to go for one commit later, the “6.0 version bump”. I don’t know.. argh..
I guess I’m going to try to compile the latter one.
@Possemo:
Newer versions of JUCE bring new classes or other functionality, besides the bug fixes. Backward compatibility isn’t always guaranteed. So, yes, better be careful with that. But where Goodweather wants some minor bugfixes and add some definitions, I want to see whether it’s doable to bind an already existing class to LUA. If that’s working.. maybe add some more classes. And so on.The VisualStudio version shouldn’t make that much of a difference as far as I know. They should be backward compatible to compile Ctrlr. And in Ctrlr version 6.0 there is a VisualStudio2019 which should give a headstart. I hope.
I bet Roman is laughing his ass off reading this 😉
Thx Tedjuh. I will follow your explanations and report back.
Today I watched some good explanations on Github and VS2019. Will play a bit with that as well.I’m a patient guy and I’m digging into things layer by layer, exactly in the same way I learned Ctrlr and where I’m trying different things one at a time.
When you don’t have someone putting you directly on the rails, it is the only way (including the very nice exchanges on this forum; sometimes it feels as we were all close friends in the same hobby club; this is great 🙂 ).I believe Roman had some problems when switching from VS2010 to VS2015. It did ont build at first try. He had to make some changes in the Ctrlr code. Maybe now VS is more backward compatible than at that time but if I would try it again I would want v5.3.201 and I would try to build it with VS2010. I’s a pity that the exact state of v5.3.201 seems to be lost. If I am right the whole “look and feel” stuff got lost after v5.3.201. Though I did never use it, some important panels such as the ones from Dasfaker rely on it.
Goodweather.. any luck?
When Visual Studio nags about missing files, like you had, it’s just simply because they’re not in that commit but are referenced in the sln file. You could try add them from another commit.
I got around a few errors by installing VCPKG, and bind some Lua directories in the properties of Cmake inside Visual Studio. Mostly concerning the stdafx problem I described earlier.
I dropped Github Desktop because it’s buggy as hell. Cannot switch branches. Or it should switch after 6 hours because that’s the longest time I tried to switch from Master to Stable. So went back to downloading Zips.
I noticed that when you download the repositories as a zip file, you have to download Juce separately. (Just click on the Juce folder in the Ctrlr commit and download the zip from the Juce repository.) Sometimes it’s necessary for panel folders as well. Depends whether there is a number in light grey after the folder name.
I’m still figuring out how to exclude some files from using precompiled headers. I can see an exclude option from the properties when right click on the sln file. But after doing that, it still produces the same error.
After some clicking and compiling some x32 release, I got an error saying it couldn’t find Ctrlr.win32.exe inside the vs\build folder. When I put the 5.3.201 version inside that folder, it opened. But it was just the stand-alone version.
And trying to find version 5.3.201. I think I need to go further back to 2016. I’m explicitly looking for when Stable Branches got merged inside the Master Branch. Something tells me that those were (partially) working for Roman.
If there is anyone else who wants to join the club or has more experience with compiling on Windows, please join the club. You are being welcomed with open arms.
Didn’t look further yet. Will first experience with making a branch, doing a change, committing, look at the history…
At this stage I have absolutely no clue on how to compile this solution, what files are needed, where do you describe the files you need, where do you store them…
Feel like a total beginner (and so I am) even if I have a quite good programming experience.
So, will first play with some “Hello world” project then tackle Ctrlr.
I’m pretty sure we can find all we need. It is just a question of time…
Thx for your support!OK. Some (training) progress. Created hello world project, different branches with changes, sync with Github…
So, indeed also found how to compile that simple project, with or without debugger.I cloned Ctrlr to my local PC but I wanted to have it also in Github under my ID as I didn’t want to do changes on Roman’s work (of course!). So I did a fork.
I have now added a 5.3.201 branch to make changes and will also try building my own master branch.
Need to learn about CMAKE and understand how all libraries are connected.
Can you point me to where I find all the involved libraries, how to add them…?
Which file is mastering the build? CMakeLists.txt? . sln files? others?What is Ctrlr.jucer?
In the ctrlr repository there are many .sln files. I took HelloWorld from the VS2017 JUCE examples
Will have a look at thatAre there difference between VS2017 and VS2019? Shall I create a VS2019 for each VS2017 or earlier I find?
Maybe a good exercise to understand how everything is articulated…Jesus, so many question marks… Keep cool, man,you will find your way…
Hi goodwheater,
About ctrlr.jucer:
A .jucer file contains all the settings of a project started in Juce, so in this case all the settings of the ctrlr project in Juce. For more info see the following link with as prefix https:
//juce.com/discover/stories/projucer-manual.I follow your project with great interest.
Cheers,
I’m doing what Possemo suggested, trying my luck with an ancient visual Studio 2010 Ultimate inside a VM. I’ll report back how things are going.
About the libraries, well, there is Cmake but that is pre-installed with visual studio (or add it as a individual component). There is the Juce Library. For Juce, the windows 10 SDK is needed l. I’m not sure if you need the Vst3 SDK (or vst2 SDK for that matter).
Juce has its own Sln files which I think are Juce specific. They are there to build demo files amongst others. I’m more interested in the Sln files in the Build folder of Ctrlr or any Sln file outside the Juce folder.
Afaik there is no real different between VS 2017 or VS 2019 besides that newer SDK’s might not work for VS 2017. But when you open a VS 2017 SLN file in VS 2019, you might need to “retarget”. If I remember correctly it’s under “project” or it is asked when you open a VS 2017 file in VS 2019.
That is all I can tell you for now. And what I said could or could not contribute to a successful build. So, good luck.
- You must be logged in to reply to this topic.