Some questions

[Iain Duncan]

Hey Rory, I have a few questions, and please feel free to just tell me where to best figure them out myself if the answers are things I ought to find out elsewhere.

- when one uses cabbage generated plugins, how does a patch get saved? In a VST environment, is that entirely up to the host? and can hosts save cabbage gui settings?

- how does the gui get generated? does it use a specific toolkit? Can one do this kind of thing with any toolkit? Your gui parser is very impressive! ( I know, look in the code! hoping for an easier answer. ;-) 

- is it feasible to have cabbage instruments receive more than midi data? (ie would it be possible given more hacking, not do you personally plan on making it possible.) 

 Does that question even make sense in the VST paradigm? IE is there any kind of way of having something that is running as a vst plugin receive OSC controls, or receive input from apps *other* than the VST host? (I'm new to the whole VST idea as you are probably noticing!) I guess it seems to me like the limitation of a vst instrument is that it's only getting control data from one track in a host, but maybe there are options in that area?

I'm trying to figure out what direction I should take with some of my work to make it fit in nicely with Cabbage. Cabbage is that cool! I honestly think this has the potential to do more for Csound than anything in uh, forever really. Most of the csound dev community is focussed on rather esoteric ways of working, to put it mildly. ;-)

My own project is a live step sequencer and looper using jack and QT. It was, years ago, a whole live rig done entirely in Csound, which was ridiculous, but that's how I started. Now I'm redoing it in C++, with the intention that it will be usable as an expert oriented way to do group improvisation of electronic music, and be able to emulate control volt sequencing of modulars. I'm planning on a flexible output layer allowing sequence data to be arbitrary bit depth and resolution, so that it can go out to midi based instruments, csound score instruments, PD patches, supercollider, etc. Given your work, I'm thinking perhaps it needs to either be a vst host, or needs to be able to communicate to a vst host well. 

Any suggestions for how/where to get up to speed on VST coding welcome!

thanks

Iain 

[Rory Walsh]

> - when one uses cabbage generated plugins, how does a patch get saved? In a
> VST environment, is that entirely up to the host? and can hosts save cabbage
> gui settings?

On Linux and Windows the patch is simply saved as a .csd file with the
same name as the plugin library. When the plugin loads it loads the
Csound file too. On OSX I can bundle the csd into the app so that it's
completely self-contained. I can do this also on windows and linux but
for now it's just as easy to keep it the way it is. I might look to
change it in the future so all platforms are the same.

> - how does the gui get generated? does it use a specific toolkit? Can one do
> this kind of thing with any toolkit? Your gui parser is very impressive! ( I
> know, look in the code! hoping for an easier answer. ;-)

I use Juce as my main GUI toolkit, but before that I did a similar
thing with wxWidgets, and before that using Borland VCL classes.
Because the Csound API has so many interfaces it's possible to do
these things with lots of different languages. My GUI parser is no
great shakes, but it's easy to expand and maintain. Because the syntax
is so simple I can stay away from having to use dedicated parsing
libraries.

> - is it feasible to have cabbage instruments receive more than midi data?
> (ie would it be possible given more hacking, not do you personally plan on
> making it possible.)

Considering that Csound can do this already then the answer is yes,
and without too much hassle perhaps. One could create several Cabbage
plugins that could speak to each other using OSC messages. On top of
this we could check is plugins inside one host can speak to other
plugins open in other hosts. Hmmm. Interesting idea. It should already
be possible thanks to Csound.

>  Does that question even make sense in the VST paradigm? IE is there any
> kind of way of having something that is running as a vst plugin receive OSC
> controls, or receive input from apps *other* than the VST host? (I'm new to
> the whole VST idea as you are probably noticing!) I guess it seems to me
> like the limitation of a vst instrument is that it's only getting control
> data from one track in a host, but maybe there are options in that area?

I don't see why not. OSC sends message over a network so any program
that can receive/send those messages can communicate with the program
sending them.

> My own project is a live step sequencer and looper using jack and QT. It
> was, years ago, a whole live rig done entirely in Csound, which was
> ridiculous, but that's how I started. Now I'm redoing it in C++, with the
> intention that it will be usable as an expert oriented way to do group
> improvisation of electronic music, and be able to emulate control volt
> sequencing of modulars. I'm planning on a flexible output layer allowing
> sequence data to be arbitrary bit depth and resolution, so that it can go
> out to midi based instruments, csound score instruments, PD patches,
> supercollider, etc. Given your work, I'm thinking perhaps it needs to either
> be a vst host, or needs to be able to communicate to a vst host well.

With OSC it should be able to speak with a host through a plugin. And
it needn't be one you build yourself, I'm sure there are OSC plugins
that let you send data to them?

> Any suggestions for how/where to get up to speed on VST coding welcome!

There is a section about VST programming in the Audio Programming
Book. You can also check out the Juce library. It's quite a beast. I
think it's by far the easiest way to get into programming plugins. It
builds right out of the box, so long as you point towards your vst sdk
folder. If you don't wish to go down that route there is also the
actual vst sdk itself, but Juce is totally cross platform and you can
use the same code to generate VSTs, AU, Linux VST, RTAS etc. Check it
out. In the meantime I hope to have an OSX beta release for you
shortly. Maybe you can realise your project using Cabbage? We're
currently working on a new table widget that should make it child's
play to create a fully functional step sequencers.

Rory.

[Iain Duncan]

On Sun, Feb 19, 2012 at 4:11 PM, Rory Walsh <rory...@ear.ie> wrote:

> - when one uses cabbage generated plugins, how does a patch get saved? In a
> VST environment, is that entirely up to the host? and can hosts save cabbage
> gui settings?

On Linux and Windows the patch is simply saved as a .csd file with the
same name as the plugin library. When the plugin loads it loads the
Csound file too. On OSX I can bundle the csd into the app so that it's
completely self-contained. I can do this also on windows and linux but
for now it's just as easy to keep it the way it is. I might look to
change it in the future so all platforms are the same.

Hey Rory, I actually meant the state of the widgets. To me, I think of the csound file as the synth, and the state of the controllable inputs as a patch, as in what would be a patch on an analog or modular. Do those get saved? Is that something that is normally the responsibility of the VST plugin or the host? 

 

> - how does the gui get generated? does it use a specific toolkit? Can one do
> this kind of thing with any toolkit? Your gui parser is very impressive! ( I
> know, look in the code! hoping for an easier answer. ;-)

I use Juce as my main GUI toolkit, but before that I did a similar
thing with wxWidgets, and before that using Borland VCL classes.
Because the Csound API has so many interfaces it's possible to do
these things with lots of different languages. My GUI parser is no
great shakes, but it's easy to expand and maintain. Because the syntax
is so simple I can stay away from having to use dedicated parsing

libraries.

Cool, will take a look at it.

 

> - is it feasible to have cabbage instruments receive more than midi data?
> (ie would it be possible given more hacking, not do you personally plan on
> making it possible.)

Considering that Csound can do this already then the answer is yes,
and without too much hassle perhaps. One could create several Cabbage
plugins that could speak to each other using OSC messages. On top of
this we could check is plugins inside one host can speak to other
plugins open in other hosts. Hmmm. Interesting idea. It should already
be possible thanks to Csound.

Yeah, I think that will bear some experimenting. My only hesitation with VST instruments is the way we are restrained by what we can get the host to send to each one, but if we can augment that with OSC input, that would probably take care of it.

 

> My own project is a live step sequencer and looper using jack and QT. It
> was, years ago, a whole live rig done entirely in Csound, which was
> ridiculous, but that's how I started. Now I'm redoing it in C++, with the
> intention that it will be usable as an expert oriented way to do group
> improvisation of electronic music, and be able to emulate control volt
> sequencing of modulars. I'm planning on a flexible output layer allowing
> sequence data to be arbitrary bit depth and resolution, so that it can go
> out to midi based instruments, csound score instruments, PD patches,
> supercollider, etc. Given your work, I'm thinking perhaps it needs to either
> be a vst host, or needs to be able to communicate to a vst host well.

With OSC it should be able to speak with a host through a plugin. And
it needn't be one you build yourself, I'm sure there are OSC plugins
that let you send data to them?

Not sure, have to dig into the world of OSC, I'm new to it.

 

> Any suggestions for how/where to get up to speed on VST coding welcome!

There is a section about VST programming in the Audio Programming
Book. You can also check out the Juce library. It's quite a beast. I
think it's by far the easiest way to get into programming plugins. It
builds right out of the box, so long as you point towards your vst sdk
folder. If you don't wish to go down that route there is also the
actual vst sdk itself, but Juce is totally cross platform and you can
use the same code to generate VSTs, AU, Linux VST, RTAS etc. Check it
out.

Hmm, may take a second look at it. I eliminated it when I was choosing toolkits because Juce is a one man show, and when I asked about the truck number and what the contingency plan was if Juce closed ( ie was there a license reversion poison pill or anything ) I was, to be honest, rudely dismissed by the author as being concerned over something that didn't matter. As someone who owns a two person software business, I'm well aware that it can matter a lot. Consequently I chose QT plus Jack as my framework and have been really really happy with it, but it does sound like Juce has some great stuff on a technical level. I think for large projects QT is brilliantly designed though, now that I've drunk the QT koolaid I wouldn't do a big project without their signal-slot mechanism/registry, it's beautiful.

 

In the meantime I hope to have an OSX beta release for you
shortly.

Will be happy to test!

 

Maybe you can realise your project using Cabbage? We're
currently working on a new table widget that should make it child's
play to create a fully functional step sequencers.

heheh, that was how this started, about 7-8 years ago. ( Then I took about five years off from computer music when I started a Python business, and spent all my music time playing jazz sax.) It was, at one point, I think the biggest csound project by lines of code and table count, and it got way way too hairy and was a maintenance and design nightmare. We started it on Csound 4.13 before the CsoundAPI was an option. So the current project is redoing the whole thing with all the i/o, file management, gui, and sequencing done in QT, limiting Csound to audio generation only. That's part of why I think Cabbage is so great, Csound is awesome for writing small self-contained synths, but just too linguistically primitive for large projects of interconnected components. I will however work on incorporating and playing well with Cabbage, absolutely!

thanks and looking forward to working with your work!

Iain

[Rory Walsh]

> Hey Rory, I actually meant the state of the widgets. To me, I think of the
> csound file as the synth, and the state of the controllable inputs as a
> patch, as in what would be a patch on an analog or modular. Do those get
> saved? Is that something that is normally the responsibility of the VST
> plugin or the host?

That's all saved in the host through automation pre-sets. All GUI
controls in Cabbage can be controlled directly with the host.

QT is a great toolkit, as is wxWidgets. I can see peoples issues with
Juce but for me the pros out-way the cons. I'll keep you posted on OSX
beta.

Rory.

[Iain Duncan]

On Sun, Feb 19, 2012 at 4:49 PM, Rory Walsh <rory...@ear.ie> wrote:

> Hey Rory, I actually meant the state of the widgets. To me, I think of the
> csound file as the synth, and the state of the controllable inputs as a
> patch, as in what would be a patch on an analog or modular. Do those get
> saved? Is that something that is normally the responsibility of the VST
> plugin or the host?

That's all saved in the host through automation pre-sets. All GUI

controls in Cabbage can be controlled directly with the host.

Thanks, I thought that was the case but wasn't sure. That's a great way to build/use csound synths then!

 

QT is a great toolkit, as is wxWidgets. I can see peoples issues with
Juce but for me the pros out-way the cons. I'll keep you posted on OSX
beta.

Yeah, for what you're doing that makes sense. It sounds like Juce is very slick for building plugins. The plugin side was secondary to long range project and complexity management for me.

iain