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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Thu Jan 15 2004 - 00:16:39 EET


On Wed, Jan 14, 2004 at 09:35:27 +0100, Fons Adriaensen wrote:
> > Wouldn't number of voices and finding out if a port is connected be
> > internal to the app? These things can (actually have to) be stored. As
> > far as storing, this kind of information would go in the patch file
> > (.ams), not the plugin. Am I missing something here? Besides, since
> > you've got LADSPA plugins working... well, it must be possible ;).
>
> You can of coourse use plugings in a polyphonic mode, and AMS even implements
> a special protocol that enables LADSPA plugins to discover that they are used in
> this way (I have some unpublished plugins that actually use this). But this is
> not part of the current LADSPA standard. I proposed it some time ago, but when
> I mentioned that one use of this would be to let a poly plugin create only one
> GUI for all voices, the thread quickly changed into a discussion on plugins GUIs
> and how to make them, and the original proposal was lost in the hassle.
>
> There are other reasons why you may want to know that a number of plugin
> instances belong in fact to one polyphonic module. There may be for example
> lookup tables or control voltage calculations that can be shared between all
> voices.

We did discuss this briefly, personally I'm against plugins implementing
polyphony in this way (though I'l admit its more a matter of taste than
anything else), but a good UI standard should probably address controlling
mutiple plugins (its quite common eg. for doubling up mono plugins to
effect stereo streams) and its possible to share data between plugins, and
even across hosts (eg. my bandlimited osc plugins share the table matrix
where possible).
 
> Knowing that ports are unconnected can be important if this changes the way
> the plugin operates, or just to avoid useless calculations on endless arrays
> of zeros,

Agreed, but to be acceptable it probably needs to be transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.

Someting like passing the plugin a valid buffer of zeros, with a known
address (that can be queried and compared by the plugin) would be OK,
but would require API extensions.
 
> Some of the functionality I want for the new AMS also requires 'metadata' along
> with the audio signals, e.g. to indicate which voices in a poly patch are active
> or have terminated. In the current AMS for example, there is a 'hidden' data path
> from the envelope generators back to the voice controller, to signal that a
> voice has terminated and can be reallocated. This is why you can't have an
> envelope generator in a plugin, as this data path is hard-wired into the engine.

This comes back to wether you believe that the plugins should be handling
polyphony or the engine. Again, probably a matter of taste.

FWIW I'l note that hardware modular systems dont have metadata streams :)

- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 00:18:50 EET