Hi! today I installed latest cabbage from website. System is debian buster, csound is 6.17 compiled from source. Exported pdclip and LoFi to vst2 and they result with 64 ins/outs regardless of
nchnls = 2
nchnls_i = 2
Is there other way to set it?
Hi @alikthename, what host are you using? It seems that some hosts just pick up the default, which is maxed out at 64 IO, while others try to find the plugin’s preferred channel config. I can test here if I have the same host.
There was one thing though. I installed Cabbage, then found out that csound from repositories is not new enough and got some errors. So I compiled csound from source, which required lots of dependencies I did not have. May be Cabbage also needs them at installation?
I don’t think this is an issue. If Cabbage built, and you can see the plugins in a host everything went well in building. I’ll check tomorrow and see what’s going on.
I’ve pushed a ‘fix’ for this. ‘fix’ because Cabbage will now try to force the hand of all DAWs on Linux to use the channel config set out by the .csd file. I’ve tested with Reaper and Bitwig and it seems to be Ok. Can you try a few other hosts and let me know? You’ll need to grab the latest source from GIT. Let me know. On Windows and Mac I check for certain hosts and then deal with them accordingly. It seems that I can’t easily get the name of the host in Linux. Hence the all or nothing approach.
Outputs look good now. Though some plugins crash ardour with “Csound tidy up: Segmentation fault” (like waveset or Compressor). Good to see new gui for Compressor, but at the same time pity that it gives no sound 
. But these probably have something to do with what’s in .csd files
One thing though. It seems like plugins take a bit more cpu than they should. Might it be that they compile in debug mode or something? I remember JUCE by default sets release type as debug
Do you mean more cpu in comparison to a non Csound, or native plugin? Csound runs about a third slower than native code, so you should expect some overhead. I’ll check the build accept tomorrow. It may mistakingly be set to config debug.
I just checked now and it is set to release build by default.
I fixed the compressor .csd file. But I couldn’t spot any problems in the waveset .csd? The compressor update is in GIT now.
Rory, how are the -b and -B calculated? Are they connected somehow to running jackd settings?
These two settings have no relevance in Cabbage as it implements its own audio IO.
So it very different from csoundqt? I wanted to compare how the same instruments with just csound, and -b -B seem crucial here. Is there a way to somehow match what cabbage is doing?
I think CsoundQT just uses Csound to handle audio IO? Cabbage doesn’t use any of Csound’s MIDI?Audio IO interfaces. I think CsoundQT and Cabbage are quite different in this regard. But I could be wrong. It is a long time since I looked at CsoundQT.
Ok will take a look at latencies then
ksmps sets up the latency in Csound. But this is offset whenever you run Csound as a plugin within a host. You can also use the latency() identifier to give you more control over this. What is the issue exactly?
I’m just trying to get an idea why cabbage plugins seem to add much more DSP load. For example ball in a box as cabbage vst2 adds about 20% to jack’s DSP load indicator where babo that comes with csoundqt and runs in it is about 1-2% on jack’s DSP load
Are you getting a DSP load of 20% when you run the Cabbage plugin in Ardour ? I just testing that plugin now and after exporting I get a 0.4% CPU performance on it in Reaper. I tested with a pretty old laptop.
I would expect CsoundQT to run Csound instruments faster than the Cabbage IDE. CsoundQT is much closer to the metal in terms of Csound, while Cabbage is basically a plugin host.
I get the same behavior if I run an instrument in cabbage itself
I will try it on another machine
In the IDE you mean, or in a plugin in a host? Sorry, that wasn’t clear…
