Hi all,

I'm very new to plugin design and quite new to C++, but have a solid grasp on SuperCollider, so hopefully I've got what it takes!

I'm thinking of designing a plugin instrument and I've been looking at C++ audio synthesis libraries. I've spent a few days wrestling with the Synthesis Toolkit, which is the library I see most recommended around the web, and to be honest was the only relatively comprehensive one I could find for some time. I'm not getting on too well with it.

But I've just come across the Create Signal Library and I was wondering if anyone had any experience with it? From what I've seen it seems far easier to use, and even resembles SuperCollider quite a lot, which is a massive plus to me. Has anyone here had any experience with it? Does it have any clear pros or cons against the STK?

Many thanks,

T

On a side note that app looks like it was created with JUCE...I approve!

Yes, it seems there is quite tight integration of CSL with Juce, which is another big bonus since that what I intend to use for the GUI and compiling to AU and VST.

CSL is a FANTASTIC library. The most recent version of it is dependent on Juce io classes, which is great if you like Juce. My only problem with it is that Juce isn't truly open-source, as you will need to purchase a commercial license in order to sell anything you develop with it. You can rewrite the io classes, or get an older version of the library and it will work fine. CLAM is also a fantastic DSP/Synthesis library.


Dan

I think their license fees are quite reasonable. The show stopper for me was that JUCE doesn't yet support 64 bit sample data, and these days customers want and expect it.

Haven't looked at CSL yet, what's it do?

Cool, glad to hear it. I like the look of it. Yes, it's a shame it's dependent on Juce 1.50, but only because I'd like to use Juce 2! It looks like the integration of CSL into Juce 2 will not be trivial, but hopefully it won't be too hard either.

CLAM is another library I was looking at, but it is under the GPL and I'm hoping to (eventually) create commercial plugins. CSL only requires author credit in your app I believe.



Just out of interest, did you go for a custom solution for GUI/IO instead? Or did you use a different library?

I agree that, considering Juce allows you to compile to both AU and VST from the same codebase, it seems worth the fee to me - I could easily see myself wasting a lot of time on the intricacies of each platform which I think I'd gladly pay £400 to skip, if I ever make it to releasing a commercial plugin. [/quote]

My plug-ins are pure VSTs (2.4, which aren't really any more complicated in code than JUCE. process(), setParameter(), etc all look very much the same.) and for GUI I use VSTGUI 3.6. (Heavily modified to fix bugs and make higher-functioning controls.)

I wrap them with Symbiosis to make AUs. (Works great! You can even wrap other people's VST products!)

http://code.google.com/p/symbiosis-au-vst/

Interesting, I hadn't seen that before. That seems like quite a viable option too. And a cheaper one!

Try it. You can use it in two ways, either compiled-in, or the way I use it where I just take the completed .vst package and drop it into their .component container and tweak a couple of config files.

This way I only have one binary to manage. Anything that reduces complexity and compile targets is a huge time saver.

You don't need to purchase a commercial licence for selling you software that uses Juce, but of course you'd need to release your source code as well.
Also, I wouldn't say the GPL isn't "truly open-source".


It shouldn't be hard (few days) to add this to Juce.
May I ask why you considered switching to Juce? It seems you already have a working setup.

For the cross-platform aspect, specifically for x64 builds on OSX. Also for the hopes of RTAS builds (if Avid ever respond to us to allow us to use their SDK -- but they don't). And also for a (slightly) more rapid prototyping of new plug-ins.

But you're right, I would have to re-produce a lot of my custom control work. So I was mostly just considering it for new, smaller products where I could possibly forego our advanced knobs.

And JUCE hard-codes the sample data as float, rather than using a template or typedef. So it's a lot of work to add it in. And if I modify it, it's all broken again at the next JUCE update. So it should come from them, not me. (Also, I'm not going to PAY to fix someone else's product!)

But yes, you're right, it shouldn't be hard and should just be a few days for JUCE to add it. But I asked for this months ago, back in April (and many others had been asking already) and no sign of it. That doesn't really give me the warm fuzzies.

http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=4113

Derail split to another thread. Please don't wreck this thread with a tangential argument. It's a disservice to the OP.

Thanks Meffy.

As an update to this, I noticed the other day that the author of CSL has updated it so that it now works with Juce 2.0.23 - which is brilliant news for me since that's what I'm building my interface with. This is extremely serendipitous timing for me!

At the moment the new version doesn't work with Juce's audio file reader classes, but instead uses libsndfile. Not a huge problem, but it would be nice to have full Juce integration.

Anyway, between Juce and CSL, I now feel I have a fighting chance at actually getting this synth idea working, which is exciting. Time to get down to work!