Road Map

Here are the broad areas I think Tonic development needs to address, probably in order of importance. Hunter and Nick -- feel free to add to this or comment on it.

#Performance Benchmarks

In order to justify Tonic's existence, we should demonstrate that it is at least as, and possibly much more efficient than the other available options, such as MomuSTK and Maximilian, and libpd. Before I go much further, I want to convince MYSELF of this. In order to create the pretty end-user syntax, I've had to do some deep nesting of objects in some funky ways. On every buffer calculation, this tree has to be traversed, and I want to make sure that all these function calls aren't negating the benefits of vectorizing (is that the right word?) -- calculating samples in batches, rather than one-per-function-call.

I'd like to set up benchmarks which are easy to run (Tonic::runPerformanceTests()), measuring how much time it takes to calculate a certain number of samples of a certain synthesis algorithm. Once these are set up, we can demonstrate Tonic's superior efficiency against other tools, and measure it against itself as we improve its own efficiency. A few ideas of tests to start out with:

• Mix down 10 sine waves.
• FM synthesis (maybe chain more than two oscillators)

#MultiChannel

• How much more effort will it take to build Tonic to handle an arbitrarily large number of channels?
• How much automatic expansion from mono to stereo (or more) do we want to do? For example, if a user does outputGen = SineWave().freq( 500 ), should we raise an error, warning them that SineWave has a mono output, and they're trying to plug it in to a stereo input, or do we just work out a way to gracefully handle as many channels as needed?

#Generators

Here's some stuff that needs to be done:

• ADSR. Might have an input which it multiplies, might just output 0-1 values. Supercollider uses pre-calculated envelopes, presumably for efficiency. I like the concept of a "Triggerable" superclass for envelopes. "Triggerable" has a "trigger()" method. Also maybe a "trigger(string name)" method which is how we could handle keyup. Along with simple linear envelopes, I'd love to have a way to generate curves.
• Sine Oscillator. Right now what I have is a copy of the STK sine wave oscillator. Maybe Nick can implement a wave table oscillator and a sine wave subclass.
• Reverb, filters, FX, whatever. We can never have too many!

Wherever possible, I'd like to make EVERY parameter to each generator be another generator. There may be specific cases where this isn't efficient, but generally I think it should work fine. So you NEVER set a value on a Generator as a float. You always have a parameter be a Generator object, enabling the user to plug in an arbitrarily complex graph in order to generate and modulate that parameter.

#Insta-Synth

Nick had some really good ideas about prepackaging a collection of Tonic synths ( or file players, or whatever) so they could be usable with just a few lines of code in iOS or OpenFrameworks projects. I think this is a great idea, a great way to welcome people in, to give them something for free. If we could provide something that's a little more than just a filtered saw-tooth oscillator or whatever, that would be pretty awesome. If people can be like "hey -- I want to slap a synthesizer in to my little open frameworks experiement" and go to Tonic, and BAM, they have a nice sounding synth with NO effort and super easy setup, that would be pretty damn cool.