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

[Joost Diepenmaat]

On Fri, Jan 16, 2004 at 02:39:36PM -0500, Dave Robillard wrote:
> Not once in my fiddlings with LADSPA plugins in a modular synth have I
> said to myself "Damn.. these things need a big spiffy GUI".  Honestly, a
> bunch of sliders works just fine for me - I don't really see the need
> for more.  Sure, VSTs that look like shiny audio hardware are nifty...
> but who cares?  

I agree in general; the only time this becomes helpful is when plugins
have *lots* of control ports, I think. (disclamer: I've been mostly
using Buzz on win32 for audio use, but the situation is much the same
there - most plugins just let the GUI be generated by the host, and
of those that don't, only a couple actually improve the situation -
actually, the only one I can think of is the default mixer plugin,
which has 16 channels with about 7 controls per channel - that just
too much to represent as a bunch of vertically aligned sliders)

OTOH, my guess is that this *could* be solved by making polophony
explicit, so only some ports get duplicated when the a voice is
added - if a host is aware of this, it could employ some grouping
of controls for the extra voices that takes less space.

> > FWIW, I dont think its neccesarily important that LADSPA is used in
> > modular synths, its far more important that modular synths all use the
> > same module format, whatever it is, to save the duplication of effort
> > thats going on currently.
> 
> Absolutely, but if LADSPA could be that plugin format.. that would be
> obviously the best case.  Then every audio plugin would be the same
> format, which is cool.

I would not like a (to my mind) artificial split between modular synth
plugins and general LADSPA plugins either.

The only thing I'm really missing from the LADSPA specs at the moment is
the availability of 'recorded' streams (so you could implement a sample
player as a LADSPA plugin, or play recorded tracks backward, etc.)

My ideas on this are rather shady, but to me the most "simple" solution
would be, to let the host handle all memory management, loading, etc for
the streams, and to present them to the plugin as an "object" so the
plugin can request a buffer representing part of the stream (so you don't
need all recorded streams in memory, and the reading of files, etc is
out of the plugin's responsibility).

BTW: My apologies for posting these ramblings, if they are inappropriate,
as I'm new to this list.

Joost Diepenmaat.