So I develop primarily on mac, but for surge I have a linux and windows vm I can spin up on my box which i do occasionally. 95% of the time I rely on the pipelines to check and I generally “know” when I’m doing something OS specific. If you stick to the APIs in rack you are fine, generally. The first time you build another platform you will realize you missed something (like you refer to a uint64_t and don’t include stdint.h or some such) but rack is also pretty consistent in tooling on all the platforms. Just stick to the rack API and you are OK basically.
If your code is in a public github repo and has an open source license I’d be happy to pull it down and try it on a mac also.
Andrew has his own docker based (I think) cross compiling build system I know for the whole shebang. As to why more folks don’t use the azure pipelines I’m not sure but I occasionally hop into a thread with a dev and point them to the experience i had. Incredibly useful.
Understood. Well if it is and you want a volunteer to try a build on a mac, and it’s not the week or so between christmas and New Years, tag me here and I’m happy to give it a whirl for you.
It is time that I create a GitHub repository. If I create the repository as private, can I change it to public once I get it working right? I’m setting it up under GPL 3. I’m assuming that is the best license for open source and non-commercial?
Yeah GPL3 is a good choice if you want to ensure that it is open source and the source is only in other open source projects. (If your code is GPL3 and included in another bit of software, there’s no particular requirement those projects can’t be commercial but they must be open source and GPL3, which de facto means that a free version will always be available).
And yeah you can swap from private to public. But the experience we had over in surge land was that claes (the original author of surge) dropped a not really working very well and definitely not finished version of surge 1.6 into a public github repo and let the community find many of the bugs.
The first version in the public repo didn’t compile on mac, didn’t compile on linux, and had lots of things that needed fixing. This is not a criticism - he was super open about the fact that it was a half finished version 1.6, and the core of the synth was fantastic on day 1. My point is more that having the unfinished code available to the community may be something you want to consider.
Although of course you should choose the development lifecycle and code disclosure that works for you. I’m not trying to bias you one way or another, just sharing my experience!
Well, that was easy. I set up my GitHub private repository, cloned/downloaded, built it and it works! I need to get a little more familiar with GitHub before I make this public.
Wow, you are fast! Whew, this is a relief that it works on MacOS. I get those same warnings on my build. I need to fix them anyway. The DEBUG redefinition is what I use to cause all DEBUG() calls to be “commented out” and not compile.
paul:~/dev/VCVRack/plugin-source/Meander$ grep -r Deja src
src/Meander.cpp: textfont = APP->window->loadFont(asset::plugin(pluginInstance, "res/fonts/DejaVuSansMono.ttf"));
paul:~/dev/VCVRack/plugin-source/Meander$ ls -al res/
total 3416
drwxr-xr-x+ 11 paul staff 352 Dec 8 12:03 .
drwxr-xr-x+ 13 paul staff 416 Dec 8 12:03 ..
-rw-r--r--+ 1 paul staff 37832 Dec 8 12:03 EurostileBold.ttf
-rw-r--r--+ 1 paul staff 830004 Dec 8 12:03 LEDCalculator.ttf
-rw-r--r--+ 1 paul staff 595082 Dec 8 12:03 Meander.svg
-rw-r--r--+ 1 paul staff 71288 Dec 8 12:03 MusiSync2.ttf
-rw-r--r--+ 1 paul staff 44988 Dec 8 12:03 MusiSync3.ttf
-rw-r--r--+ 1 paul staff 53380 Dec 8 12:03 Musisync-KVLZ.ttf
-rw-r--r--+ 1 paul staff 77604 Dec 8 12:03 Musisync-qYy6.ttf
-rw-r--r--+ 1 paul staff 16624 Dec 8 12:03 Segment7Standard.ttf
-rw-r--r--+ 1 paul staff 2489 Dec 8 12:03 musisync-guide-06dd.htm
I never noticed that I had the struct name and the object name the same. I guess your linux compile does a more stringent check than my Windows compile.
