ya I heard about those snap packages. not sure I love the idea of having every plugin or app bringing a new copy of a library I already have, but thats another thing.
falktx said he just needs a regular deb if you want to put it in kxstudio. Though he did mention that he’d like it to use his distrho fork of juce for consistency.
If falktx only needs a .deb file we can use checkinstall. We would need to decouple buildCabbage into two different scripts (buildCabbage/installCabbage) and sort out where do we want each file to be placed in the system hierarchy. We would then need to replace the JuceLibraryCode folder with his fork. After that it’s just a single command to build the .deb.
I can set that up, but could you ask falktx if it’s ok to use checkinstall? Should we upload v1.0.0 or the most recent beta?
EDIT: falktx uses launchpad so I bet we’ll need to use the appropriate Debian/Ubuntu tools. I’ll read about what are the proper ways of doing it.
falktx later made the point that we could maybe just get this into Debian which would really be a better solution, more widely applicable when its official rather than a PPA. I really know little of packaging, but its a good point.
Bravo, gsenna for looking into it!
If we want to distribute Cabbage via Launchpad we’ll have to change all hard-coded paths inside the code. I’m talking about IntroScreen, opcodes.txt and Examples.
As a workaround I’ve managed to create a .deb using checkinstall. It doesn’t follow the traditional rules for placing files in Linux. Basically it places a Cabbage folder (equals to the CabbageBuild folder) inside /usr/local. Then it copies the .desktop files into /usr/share/applications/. I’ve checked and lilypond does something similar.
This .deb doesn’t have the Docs included because I can’t figure out what Docs/_book is.
It appears to work fine. We could refine the process and distribute these .deb packages through the Downloads page or the Forum. Of course it will be better if we could create proper .deb files in the future.
I had to put my name in the Maintainer’s field. I don’t think it’s fair because the Ubuntu Software Center displays the text as I was the creator of Cabbage. Would you like to create these .deb Rory?
The good thing is that newbies can install Cabbage using the Ubuntu software center or dpkg -i. Then you can remove with apt-get purge.
Let me know what do you think about this approach and test the .deb if you can. It’s a 64-bit installer and I used the development branch to build it. As you can’t use characters for the version’s text field I filled it with v1.0.4.
First off, thanks for running with this guys. I’ve just now updated the makefiles so they should work Ok, between the ones @gsenna contributed, and fixing the mistakes I had in my own, I think there are now good to go.
Please use the latest dev branch. I’m about to push it to the master branch anyway.
You will need gitbook to bild the docs. It’s pretty simple to install. Once installed cd to the Docs dir, run “gitbook init” and then gitbook build. It will create html docs in a folder called “_book”
Just one thing, does your .deb also include Csound? Or does it have a way to check for the existence of Csound? I look forward to adding it to the downloads page. I don’t see any problem with having the Cabbage directory placed into usr/local, it might not be very PC correct but it’s clean and easy to maintain right?
Thanks again for this!
I installed the deb without issue. Great work!
However due to the unconventional install location I’d try to make it clear in the docs or when you download or something how to use it from that location. Just the .desktop file doesn’t work in my case because I use a minimal WM with no launcher (i3wm).
OK. So I’ll use the development branch. But I’ll need a way to specify the development version with dot-decimal notation. What convention should we adopt for that?
I went mad trying to figure out what was _book yesterday! I should have asked…
It seems that I can pass something like –requires=“csound (>= 6.03)” that will cause dpkg to make the installation fail if the dependency is not met. The other thing we could do is place a copy of Csound’s shared libraries and the plugins64-6.0 folder in /usr/local/Cabbage, like the Windows installer does. What would be best?
Rory, can I put your name and e-mail in the maintainer’s info? Both things are required by Debian. Oh, and another thing, I don’t use fedora but checkinstall can create RPM packages too. If there’s someone willing to test, I can try to create them.
Maybe a symbolic link in /usr/local/bin would be a good idea then.
I’ll just go ahead and merge the dev branch with the master and we can release v1.01, that will satisfy the dot.decimal naming scheme right?
I think it might be best to have a dep on Csound rather than include it. I don’t really like the idea of multiple copies of the same libraries being placed about the file system.
I’m happy for your name to go there considering you are the one who is doing all the work on this! Actually, can one put down a web address too? Maybe http://cabbageaudio.com?
I think it will, yes.
OK. What should be the minimum version of Csound demanded as a dependency?
I can put it in the description and there’s a Source field also which should point to your github repo maybe.
I’ll try to document the process whenever I’ve some free time.
I think it’s Csound6.04, but I can’t recall for sure. I think they bumped the API again after 6.03.
Cool. Take your time, I want to sort out a few last little bugs before merging the dev branch into master. I’ll let you know when that’s done.
just tried to export an lv2 but CabbagePluginSynthLV2.so was not found. I imagine a lot of linux users will be interested in LV2 export, so if its stable, please include that in the .deb.
Thanks guys! I’m super stoked about having these plugins!
I’ve never really used the LV2 stuff much. Is there any advantage over native Linux VSTs?
Hello, me and my buddy Matt installed cabbage on his Ubuntu “trusty” system yesterday, I thought I’d post what happened in case it is useful.
We used the new makefiles and SDK3 VST, rather then vstsdk2.4 (which I used for my Debian install). This worked OK except for MakefileHost, which still needed the old vstsdk2.4 folder in the ~/SDKs/ folder in order to compile.
There was also another compile error which we needed to install libxrandr-dev to solve
Also the desktop link to CabbageStudio was broken though it still worked from the command line
Other than that it was ok. Also we had to install csound from source code too because the package version for Ubuntu “trusty” wasn’t recent enough. Thanks everyone cheers
Hi @KezL,
I think the Makefiles haven’t been updated in github yet. I still see the old hard-coded paths.
I forgot to mention that the buildCabbage script has a lowercase/uppercase typo when copying the Cabbage Studio .desktop file.
Ubuntu 14.04, correct. Ubuntu 16.04 (released today) should work.
ok thanks
@rorywalsh the biggest difference is that LV2 is an open format, so for us flag-waving open-source purists, it’s much nicer. Actually from a plugin developers perspective there are a few things LV2 can do over VST mostly due to the meta-data capabilities in the spec, but a lot of it is just politics.
@KezL I’ll take a look at the build process for the host. I probably have it set to use 2.4 somewhere. Cheers for the heads up.
@gsenna, did you check the dev branch? The only hard coded paths now are the default locations. Custom paths should now work fine, although I still need to update the default VST paths to VST3.
@ssj71 That’s about the best argument that can be made for using LV2!
Yes, I checked in the dev branch. Specifically, the MakefileHost file. The CPPFLAGS are still hard-coded.
I agree we should be pointing to VST3 because that’s what you get when you go to the Steinberg’s website.
EDIT: Don’t forget to fix the CabbageStudio.desktop typo (Last line of buildCabbage)!
I think I have them right now. Sorry, I didn’t realise that they were hard coded into the CPPFLAGS!
