Cabbage Logo
Back to Cabbage Site

Cabbage is awesome :) aka how to make it work with LMMS

First huge congratulation to the devs , amazing job and very nice idea.

A small introduction about me , hello everyone, I come from Greece and I am 3d coder and artist messing with Blender source code (https://www.blender.org/) on a commercial project I have been working.

I recently decided to go full open source and give another try to Linux. I own a late 2013 iMac but I have been working mainly on win10 for my commercial project. Someone convinced me to give Manjaro a try (https://manjaro.org/).

Of course this being Linux I had my far share of crashes, freezes, lack of driver support but we came to arrangement in the end :smiley: So I was looking through the package manager for installing stuff and came across LMMS (https://lmms.io/) I am not new to LMMS , I have given it several tries in the past and saw it as a very weak alternative to Fruity Loops. I have been coding and making music for more than 30 years now and decided to give LMMS source code a look and was blown away how well the UI hides many of its powerful features. Before I knew it after 10 years of hiatus I was making music again. I make mostly ambient and synthwave.

Then an idea hit me to make my own VST synth. So I went to learn DSP coding to find to my horror how painfully complex it was so I gave up because I did not have that much time and I wanted to make music too. My dream is a synth that I call LazerHawk which will take the beautiful simple architecture of Yamaha CS-80 (I am huge Vangelis fan) and add a lot more stuff to it.

In the mean time I was browsing music software on Linux and came to Cabbage. I found the user comments hilarious in the website , nice touch with TNMT by the way. So I said what the hell let give this a try seems very interesting.

Of course it was not long before I discovered that it was using something weird , called CSOUND. CSOUND??? Hmmm where do I know that name ? DOH!!! And then I remembered that I had a spell with both CSOUND and Supercollider until I gave up on them because the idea of programming music was not that appealing to me. But then I had the revelation, “Wait a second , it should not be so hard to make something like LazerHawk via CSOUND and via the elegant Cabbage”.

So I did try to build it on Manajaro, it failed in building the JUCE library then I found a windows binary and managed to run it via WINE with many issues. I did use an example to make a synth , LMMS can load VST plugin (also uses WINE to do so) but it crashed and burned.

Even though this failure could made me lose motivation my head start spinning with infinite possibilities. What started as a simple synth idea now it had the potential to embed not just CSOUND but even Cabbage inside LMMS and give its users unlimited potential. Of course a easy to use GUI would be in hand and I like the node architecture that are present in cabagge and jackctrl. I also like the rack architecture of Reason which would like to bring to LMMS as well.

I am already familiar with how LMMS makes its own plugins, I studied the source of one of its simplest synths TrippleOscilator so I know I can embed things in it without have to use any stupid VST plugin and thus avoid crashes and having a gazillion levels of abstraction between LMMS and Cabbage/CSOUND. I also love to design GUIs , my commercial project actually implements its own GUI api (using Blender low level opengl gui elements) I call “Hecate”. So its even possible to port Hecate to LMMS and use it as a main GUI on top of QT which is what LMMS is using, of course only for LazerHawk.

That give me the potential of also bridging Blender and LMMS.

I know all that sounds crazy complex but of course my goal for now is to just start simple with doing simple embeding of CSOUND in LMMS using Cabbage as external editor which should pretty doable and then go on from there. Should take a month or two (obviously working part time) .Second step is to make LazerHawk (probably till the end of 2020). Third step to embed Cabbage (if it is possible). Final step to make a bridge (via shared memory or sockets , I am familiar with both made project that united programming languages this way with python) between Blender and LMMS. So all that is long term and I am quite experienced to know that code is a slow exercise of patience where everything that can go wrong, will go wrong. But then this is for fun , so there is no rush to get it done.

Also do not let “commercial” scare you, this will be completely free and of course everything is under GPL license. My commercial project will focus only on 3d graphics.

So this long post was a big hello, a big thank you and an open introduction for discussion, I would like to talk to developers and users and read what they think, what they want and how it could be done.

I feel 2020 will be a very exciting year :wink:

Happy new year everyone :slight_smile:

Sounds very interesting,
A simple (inelegant) solution to your problem would be to build your synth with Cabbage Windows (works well in linux/wine) and use VeSTige with LMMS
More complex (and Linux only) would be to create a LADSPA exporter in Cabbage (I guess it would be possible), LMMS can load LADSPA plugins.
For sure, I guess you could also create a specific LMMS exporter :slight_smile:

this is exactly what I did that made LMMS crash and burn.

LMMS can indeed use LADSPA and VST plugin (it work well with 32 bit VSTs instruments, does not support effects). Problem is LADSPA comes without GUI support and the GUI offered by LMMS is by all agreeing to it even the devs, well, ugly (it just displays knobs in random order) and VSTs are prone to crashes.

LMMS also defines its own plugin format, those plugins like VSTs are shared libraries (DLLs on Windows) but they have much deeper integration giving them access to more abilities and also far more stable being native to LMMS. They also have access to native GUI of LMMS which is the very powerful QT5.

There is also the solution of doing my own embedding of CSOUND directly inide LMMS code/executable but I think that is a bit of an overkill for now. But still doable if needed.

LMMS devs also work in bringing support for LVL2 which is basically LADSPA 2 with GUI support but I am not that interested for the above reasons. Plus LVL2 is Linux only and I like to keep things as cross platform as possible.

There is no need for an export because AFAIK cabbage basically creates CSOUND files (taking into account of the possibility I embed CSOUND in LMMS) but then you have a point that streamlining the process would make sense to make it as easy as possible for the user.

I am not interested in supporting other DAWs because that would make things far more complex and my goals are already too complex :smiley: Plus I like to do something that is exclusive to LMMS to give one more reason to explore this amazing DAW that is so underhyped.

Hi @kilon, I just replied to your other thread :wink: TL;DR - try again to get Cabbage building on Monjaro. I’m sure it is possible… somehow! But a quick look through the JUCE forums seems to show people have been able to build JUCE applications with it.

Ok I would have started a new thread but apparently the forum thing I am a spammer

First of all I cannot build Cabbage on Manjaro because I miss header files

I followed the instructions and downloaded the VST SDK from Steiberg website however there is an issue

I get several errors here an example

In file included from ../../JuceLibraryCode/modules/juce_audio_processors/juce_audio_processors.cpp:149,
                 from ../../JuceLibraryCode/include_juce_audio_processors.cpp:9:
../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:61:10: fatal error: pluginterfaces/vst2.x/aeffect.h: No such file or directory
   61 | #include <pluginterfaces/vst2.x/aeffect.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [MakeCabbageIDE:517: build/intermediate/Release/include_juce_audio_processors_10c03666.o] Error 1

the problem here is that it tries to locate aeffect.h problem is that header is neither located in VST2 or VST3 folder and corresponding subfolders, I assume this is a VST 2 header the closest I have to this may be
audioeffect.h which is part of the vst2.x folder indeed
so how come it builds for you and not for me, you happen to have an older version of vst2.x which comes with his headers ?

Second of all, I @rorywalsh I reply here, so we may not have to jump from thread to thread. Let me explain how LMMS work, in order to use a plugin in LMMS the user has to drop vestige and the go and open a plugin. However in code level its a bit more complex.

In order for LMMS to open the VST, LMMS first builds its own plugin called of course “Vestige” , even internal instruments are plugins, similarly like VSTs are regular shared libraries. So far so good. However in order to open the VST plugin it uses WINE, but of course WINE in order to open the VST plugin needs a host to do so. So LMMS builds another library its calles RemotePlugin which then it loads via WINE and then RemotePlugin loads the VST plugin. RemotePlugin from what I have seen in the source is basically using OSC protocol to transmit messages and this is why LMMS cannot load VST plugins that are audio effects.

I mention this because you seemed to implied in the other thread that LMMS is loading VSTs directly, it does not. So debugging the crash can be tricky because it may be the fault of either a) LMMS b) Vestige c) RemotePlugin d) VST plugin e) WINE. In short debugging nightmare :smiley:

Thus is why I want to avoid a VST solution like the plague. Embeding CSOUND in LMMs will make sure not only that I will have a single plugin , my plugin, that plugin will be an LMMS plugin so far more stable and most importantly WINE won’t be involved and no weird hackery will be needed. In short I am going for the shortest, easiest and most stable approach.

Of course that does not exclude the fact I have no clue what I am doing :smiley:

Thanks for the welcome , nice to be part of this community. I do agree I prefer forums too but alas other people prefer live chat , cant blame them, hence why I asked for Discord server. I am perfectly fine with using the forum.

I’m familiar with Vestige, and LMMS. I understand you trying to avoid the VST route. Have you seen ToneZ. It was built speciificall with LMMS in mind and avoid the use of VSTs by using the Vestige headers. Let’s ping @T0NIT0RMX and see if he can help. There are a few options theses days when it comes to avoiding the VST, check out for example Free Studio Technology, and VeSTige, which seems to be an update of the original Vestige headers. There are also some forks of JUCE that embed reverse engineered VST headers.

wow impressive synth.

But of course it crashes after 5 second in LMMs similar problem. It is kinda weird because I have many old VSTs that work fine. I guess LMMS may not like more recent versions of VST 2 SDK. Of course Cabbage synths is not the only problem, in some case LMMS just refused to loads the synth altogether and they are regular VST synths. It has a deep hatred for 64 bit VST 2 synths in particular. Others work but have GUI issues.

So this is not a CSOUND or Cabbage problem obviously. Which is why I do not report this a Cabbage bug. Also I do not care about the VST format currently. Mainly because I am pretty certain Cabbage will work fine on Windows and MacOS. My synth will be mainly csound files so I dont think there will be an issue making a VST version at least for Windows with Cabbage’s kind help.

I know how to avoid VST solution, or at least I like to believe that I know, CSOUND C API comes with a static library and header file that allows to execute CSOUND files , most likely you already familiar because this is how you integrate Cabbage with CSOUND. Or the tiny fact I found a pdf you posted online on how to use the CSOUND API :smiley:

@rorywalsh Is this not a good idea ?

PS: FST does seem like a very interesting idea, will keep it in mind, thanks

Btw, although I never used wine, are you sure that the cabbage vst dll is located in the same folder as csound64.dll? It could be that it can’t find Csound, which would be a likely cause of a crash…?

yeah I did not have those in the same folder but putting in the same folder it made things worse , it now crashes as soon as I try to open the plugin.

I dont think that was the reason because if WINE looked for CSOUND it would have found it inside its C “drive” anyway because Cabbage installed it automatically. But you gave me an idea of what may cause this, I think its the fact Cabbage generates 64 bit vsts and depends on the 64 bit version of CSOUND

ok I manage to find a dude in audio programmers discord server that provided with the vst2 files i needed but now I get a new error, this is time is the turn of Cabbage not to be happy with my coding skills

../../Source/Audio/Plugins/CabbagePluginProcessor.cpp: In function ‘juce::AudioProcessor* createPluginFilter()’:
../../Source/Audio/Plugins/CabbagePluginProcessor.cpp:45:29: error: ‘JucePlugin_Manufacturer’ was not declared in this scope
   45 |     CabbageUtilities::debug(JucePlugin_Manufacturer);
      |                             ^~~~~~~~~~~~~~~~~~~~~~~
make: *** [MakeCabbageIDE:212: build/intermediate/Release/CabbagePluginProcessor_8a6343af.o] Error 1
make: *** Waiting for unfinished jobs....

Are you you running the buildCabbage script? The Makefile in the Build/LinuxMakefile folder is not used. In fact, I just remove it to avoid any further confusion.

Also, it might be best to use the develop branch. I pushed some changes for the Linux build in recent weeks that might make things a little easier to build. I assume you’ve already built and installed Csound too?

JucePlugin_Manufacturer is defined in the AppConfig.h file. If the compiler is not finding AppConfig.h then something is very wrong…

1 Like

Yeah I am using a git clone of your repo’s master branch

In any case it does not matter anymore, I switched back to windows 10 and all my problems disappeared. Working with Manjaro had the usual Linux problems anyway, like freezes, inability to use my pro audio card, slow downs etc. etc. I am keeping Manjaro around but I am back to the comforts of my main DAW which Reason and Cabbage VST synths work fine with it.

I already started making my synth going back to the CSOUND tutorials, read through your docs too which I find them very well written.

One think I wonder is about customising the look of the GUI. First of all what kind of GUI API is this ? JUCE ? Something else ?

Second you mention in your docs that you can customise the widget using SVG files instead of PNG files but you never go into as much detail as you do with the SVG widgets. How I can do this (use PNG files as skins for the widgets) and keep the functionality of the widgets ? Like knobs , sliders etc.

Is it possible to combine both techniques, PNG and SVG skins ?

Yes, check out the SVGSliders example. That should get you started :wink: The better GUIs I’ve seen created with Cabbage use a mix of native sliders and PNGs. Check out this one for example:
https://gbsoundlab.com/equphonic/
Note you can also make completely transparent widgets, and put them on top of images. This provide quite a lot of customization options too.

1 Like

oh I really like this idea with the transparent widgets, I assume the GUI API can handle animating images performance wise, like custom knobs etc. Nothing crazy,

You still did not tell me what kind of API GUI is this, what is based on ?

All the widgets are drawn natively using the JUCE framework. It features its own look and feel classes for drawing. I’ve tried to expose as much as I can.

Cabbage can animate widgets by sending data from Csound. There is a controlling widgets example that shows how this can be done. I’m in my phone right now, but you should be about to find it easy enough…

[edit] Check out the fun and games examples, they show good examples of how to animate widgets. Also, they the Miscellaneous/ModifyingWidgetAppearance.csd example.

Btw, I didn’t have time to respond properly to your suggestion of running Csound/Cabbage directly within LMMS. I think the best thing in this case would be to use the LMMS GUI toolkit, QT, or whatever it is, and simply embed Csound. This would reduce the umber of dependencies and make things easier to build in the long term.

It should be pretty simply to link to Csound from a native LMMS plugin instance, and pipe audio data and fro instances LMMS and Csound. Victor Lazzarini and I wrote a LADSPA interface for Csound some years ago, it might be worth looking at. It’s pretty low level, which is probably the best way to start.

Of course, you might find it unnecessary, depending on how far you get with Cabbage as it currently stands. You may well hit limits in terms of GUI development. I did recently investigate the option using OpenGL to create GUIs, but it ended up being a little too complicated, and probably a little over the top for such a framework.

Thanks will surely do because I love to design custom guis

I tried to link CSOUND to a LMMS plugin, I did not know this but apparently one cannot link a 32 bit library (what CSOUND is) to 64 bit (LMMS). Probably there is some workaround I am not aware of but I decided to give it a rest for now and focus on creating the synth. Even LMMS on windows works fine with Cabbage VSTs and to be sincere I will be using mainly windows because
a) Visual Studio is by far the best IDE for C++ which is what I use for my commercial project
b) Good GPU support again for my comercial project
c) Can use my MOTU ultralike mk3 hybrid pro audio card for some proper audio syntheis and my good monitors

I would love to embrace Linux but sadly it has a long way to go to convince me to switch to it as main platform. Doing it also as VST does not tie me to LMMS which I don’t want to do right now , like to keep my options open. The Linux was a nice experiment but for now I will focus on my synth, CSOUND and Cabbage and let LMMS devs fix their problems and I will focus what I love doing.

OpenGL has been dead for almost 3 years now, dont waste your time. Vulkan has completely replaced it but unfortunately its insanely hard to work with because both OpenGL and Vulkan were intended to be low level APIs. I know because Blender has based its GUI on OpenGL and they pay it now dearly that Apple dropped support to it. Personally I think QT is the way to go , so I think LMMS made there the smart choice there. Of course from what I read large part of Linux GUIs have switched to QT as their backend so right now its very big both for closed and open source projects. Frankly QT has completely dominated all platforms , almost everyone is using it.

Csound has been 64bit for a long time. All plugins created with Cabbage are 64bit. I’m not sure why it wouldn’t link. It should link just fine.

I with all of this, although I don’t have a MOTU card :frowning:

You’re not the first person to say this to me :+1:.

Yes, but I think JUCE is the foremost platform for audio development. I used wxWidgets for earlier versions of Cabbage. I even flirted with QT, but all roads seem to lead me to JUCE in the end. Being able to target multiple plugins SDKs with a single code-base is something that I like very much.

JUCE also provides wrapper code for OpenGL and will do the same with Vulkan and Metal. This means that a ‘native’ JUCE draw method can render a GUI using the GPU, or the CPU, depending on the renderer chosen. The good thing is I can avoid having to write any ridiculously complex code. I was already pulling my hair out with OpenGL, I can’t imagine what Vulkan is like :roll_eyes:

The application may be, it says afterall on the download but dont think that applies to its library but then I may be mistaken and this could be completely unrelated. With C++ you can never truly know.

I did not mean it in the hipster way , that people use the term to mean none is using it, I mean its spec has not be update by the people that made it (KRONOS group) for over 2 years now and they have shifted their focus 100% to Vulcan. So at some point even JUCE will have to port to Vulcan because when GPUs companies stop making the opengl dll, its literally game over. Android has almost completely ported to Vulkan too, they have to if they want to compete with Apple’s Metal. So yeah no new versions for OpenGL.

Frankly I do not trust JUCE, there was alwasy something that bothered me with this framework. But then I trust Steinberg even less and yet I use the VST format. I don’t know maybe its the best choice, I am not familiar with non 3d graphics stuff. On the other hand you dont have much of a choice JUCE seems to be pretty much the defacto frameworks for VST synths/effects. It is kinda sad to see how much music technology has stagnated. But then project like yours give me hope, CSOUND is an amazingly undervalued piece of software. Wish we had something similar in 3d graphics.

Stay far away from Metal, to give you a taste, the Metal triangle example, which is the equivelant of OpenGL triangle hello world example, is 1000 lines of code. It requires an insane amount of setup because this thing is crazy low level but then it does give you vastly superior performance to OpenGL up to 10 times faster which is why everyone is moving to it. Indirectly though 99.5% is via game engines. So literally almost none bothers learning Metal , yet almost everyone using it indirectly. But then such is the fate of low level frameworks.

Yeah I had witness the insanity trying to debug OpenGL from a python script. It made C++ coding look like a piece of cake. Also OpenGL debugging and error reporting tools are a bad joke. Which is why I try to avoid OpenGL like the plague.

Csound is written in C, apart from a very small portion of code, and on Windows its most certainly 64bit. So I’m not sure what the problem is. Note that all of the Windows CI builds here contain a 64bit VS lib file. It’s also pretty simple to build yourself with VS.

This is an interesting opinion. I’ve been using JUCE for a long time. Long before the ROLI acquisition. The JUCE code-base is GPL, so I don’t really need to trust them. Sure, they provide wrappers for all the major proprietary formats, but even this wrapper code is GPL. In saying that, you’re not alone in your suspicion of JUCE. I’ve talked to a lot of developers who prefer to stick with lesser, but more open formats, such as iPlug2 and the likes. Each to their own I guess. I can safely say that without JUCE Cabbage wouldn’t be where it is today.

1 Like