[linux-audio-dev] Project: modular synth editor

[Dave Robillard]

> I think the main reason for this (for SSM at least) is firstly that LADSPA
> support came after the app was developed, and secondly LADPSA plugins don't
> have GUIs - these have to be generated, with limited success. SSM is great in
> this regard - the native plugins all have really cool GUIs.

Rather than having GUIs to control plugins, I was thinking ports would
be used for the most part.. real analog modulars don't have nifty GUIs
:).  The GUI problem can be solved pretty well with a slightly more
advanced version of what SSM is doing (in CVS) right now... I havn't
really seen any LADSPA plugins that need more than a bunch of
sliders/knobs.

The ideas ams/ssm have used are pretty good, but I would add the
capability of choosing on an individual control basis whether the
control was in the GUI, or exported as a port.  This is definately
something severely limiting about ams for me right now... (sure, you can
use MIDI out to get around it, but ew).

> Another issue is that LADSPA plugins cannot be used for sample playback, as
> loading samples is impossible unless you stream the data in a la SooperLooper
> (http://essej.net/sooperlooper).

This is where the simplicity comes in.. we're not making a sampler :). 
Use an external sampler, if you want the audio in the synth, bring it in
as audio.  I really think the modularity of the, *ahem* "Linux Audio
Architechture" should be exploited fully.

Something like:

Keyboard --(MIDI)-->  Sampler --(JACK)--> Synth --(Jack)--> Output

And you could also of course run the midi into the synth as well to mix
sampled and synth sounds in any way you choose.  A dedicated sampler
prog is going to be a heck of alot better sampler than some little
plugin in a modular synth, might as well utilize it.  (Plus you could
use drum machines like hydrogen, or whatever you please as an audio
source.. including real-time live audio from a mic or instrument..)
 
> > I don't think an app like this need be that complicated:  all it really
> > needs to do (in the audio engine) is allow connecting LADSPA plugin
> > "ports" to other plugins.  LADSPA being what it is; that's not such a
> > difficult task (and most of the code could be borrowed from existing
> > projects anyway).
> 
> Agreed - at the lowest level it's a directed graph traversed in topological
> order - a solved problem. The complicated bit is the interface and additional
> functionality (subpatches etc), which is what differentiates existing synths.

Subpatches and good polyphony will be the complicated parts, I don't
think the UI will be that tough actually.

> > (If you think this is just a stupid idea you should probably stop
> > reading now...)
> 
> Not at all. It's a great idea.
> 
> > [...]
> > Anybody with more ideas/criteria for the
> > perfect modular synth? 
> 
> OK here I go: From my notes (and fuzzy memory :), what I'd like is a simple cli
> program that communicates via some form of IPC. OpenSoundControl (OSC) would
> seem to be a good mechanism, as it's quite widely supported and should be
> sufficient for all that would be required.
> [chop]

Making an "interface" or communication protocol, IPC, whatever you wanna
say I think is way way way overshooting what needs to be done.  What's
the point really?  The overhead is definately not worth it (realtime
audio..).  The engine should be just code, straight up.  We need to
design the architechture of the _program_ not an interface.

If you really wanted a UI like what you described, it could be
implemented as, well, a UI plugin.  This is my idea anyway, if you have
some good rationale for a system like that please elaborate, but I think
you're overthinking.

I know, I'm really clinging to simplicity here, but it's for good
reasons:  simplicity breeds usefulness (UNIX), but more importantly,
simple means the damn thing will actually get _written_ :).


> I agree with your points, besides the Audio + MIDI I/O - I feel these would be
> better implemented as non-plugins. There's also the sample load / save /
> playback issue to consider. 

I agree about the IO, it would probably be better to have those as
special things (but they'll still just appear as plugins with ports to
the user of course).  See my note above about sampling, out of the
domain of this project.

> > For the record, absolutely no disrespect towards authors of existing
> > efforts (ams, ssm, both great and certainly have their plusses), I
> > probably wouldn't have known what a modular synth was if it wasn't for
> > you guys ;).  Gratitude..
> 
> Indeed. There's a lot of good ideas in all these apps - it's worth considering
> whether efforts could be directed to improving these, rather than starting
> totally from scratch. However, this is likely to be more difficult!

Absoluteley.  Probably AMS because ssm is just not as solid (sorry!) and
the polyphony issue..

> > (Also, yes, I'm actually a coder, and yes, I'm willing to take this on
> > (time being limited as it may be).. I'm not one of those self-appointed
> > open-source-developer-dictators ;) )
> 
> I'm willing to help as well - I've been slacking off on this issue for too
> long...

Well, if it is decided some hardcore hacking on an existing project is
needed, at least we've got two.  Is the interest in modular synths lower
around here than I would have expected?  (Roll call)

> - 
> Myk
> 
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html