17 Nov
2003
17 Nov
'03
9:16 a.m.
Hello LAD,
I'd like to propose an extension of the LADSPA specs, or more correctly, a
particular interpretation of the current specs, in order to support the use of
plugins in a 'polyphonic' context.
The problem to be solved is this:
In a host such as AMS, a plugin can be loaded as part of a polyphonic patch. This
means that there will be as many instances of the plugin as there are voices, but
all of them share the same parameters and user interface. To the user they look as
a single module.
Now a plugin could have resources that can be shared between voices of a polyphonic
instance, but not in general between al instances. For example there could be
precomputed (w.r.t. the sample rate code) tables that depend on a control parameter.
At the moment there is no mechanism to tell instances of a plugin that they are part
of a such a polyphonic group.
I propose the following solution, which does not require the definition of new
data or functions in the interface. It has been tested with AMS, and works well.
It is also backwards compatible. Plugins or hosts that do not care about polyphony
can just ignore these requirements.
1. Plugins that contain code that is specific for polyphonic use must implement
all four 'lifecycle' functions, i.e. instantiate(), activate(), deactivate()
and cleanup().
2. If a host wants to create a polyphonic instance, it first calls instantiate()
for all voices, then activate() for all voices. To remove a polyphonic instance
it first calls deactivate() for all voices, and then cleanup() for all voices.
To create or remove multiple instances that do not form a polyphonic group, a
host always calls both instantiate() and activate() c.q. deactivate() and
cleanup(), for each instance before dealing with the next.
3. If a plugin detects that its instantiate() function has been called N > 1 times
before the first call to activate(), it knows that some of the recources created
by the first activate() can be shared with the other voices. The symmetrical
treatment of deactivate() and cleanup() helps to keep the 'destructor' code
simple.
Comments invited !
--
FA
17 Nov
17 Nov
11:02 a.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 02:14:41 +0100, Alfons Adriaensen wrote:
I'd like to propose an extension of the LADSPA
specs, or more correctly, a
particular interpretation of the current specs, in order to support the use of
plugins in a 'polyphonic' context.
FWIW, I dont think this is the correct way to support polyphony in a
modular system. It works ok for special puprpose soft-synth plugins, but
LADSPA is missing other things to make that viable.
Other modular systems I've seen have a polyphonic block, eg:
-------------------
in -> mono processing -> | poly processing | -> mono processing -> out
-------------------
The poly processing block is repeated once for each voice (with duplicates
of its inputs, and its outouts mixed), and the mono sections only exist
once per patch.
The division between mono and poly sections can either be a magic module,
or a flagged subpatch. In the simple case (everything is duplicated per
voice) the poly processing block is the whole patch, but often LFOs and
things exist globally.
This works well, and doesnt break the "module" metaphor.
- Steve
11:27 a.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 03:01:40PM +0000, Steve Harris wrote:
> I'd like to propose an extension of the
LADSPA specs, or more correctly, a
> particular interpretation of the current specs, in order to support the use of
> plugins in a 'polyphonic' context.
FWIW, I dont think this is the correct way to support
polyphony in a
modular system. It works ok for special puprpose soft-synth plugins, but
LADSPA is missing other things to make that viable.
What exactly do you mean by 'this' in the preceding sentence ?
Anyway the method I outlined works perfectly with the modules I tested.
In an ideal world, I'd prefer another method such as
instantiate (plugin_handle)
where the argument tells the new plugin which group it is in.
But that would not be backwards compatible.
Other modular systems I've seen have a polyphonic
block, eg:
-------------------
in -> mono processing -> | poly processing | -> mono processing -> out
-------------------
The poly processing block is repeated once for each voice (with duplicates
of its inputs, and its outouts mixed), and the mono sections only exist
once per patch.
The division between mono and poly sections can either be a magic module,
or a flagged subpatch. In the simple case (everything is duplicated per
voice) the poly processing block is the whole patch, but often LFOs and
things exist globally.
This works well, and doesnt break the "module" metaphor.
This is exactly what AMS is doing in polyphonic mode. Most internal modules
(PCM out is the obvious exception) are created as many times as there are
voices, but still look like a single module to the user. Plugins can be
created 'monophonic' (e.g. a reverb) or 'polyphonic' (e.g. a VCF). In the
latter case all voices receive the same control parameters from the GUI.
At the border between a mono and a poly module, signals are duplicated or
mixed as you describe. Nothing special has to be done by the user.
Where does this 'break the module metaphor' ?
--
FA
11:37 a.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 04:26:23 +0100, Alfons Adriaensen wrote:
This is exactly what AMS is doing in polyphonic mode.
Most internal modules
(PCM out is the obvious exception) are created as many times as there are
voices, but still look like a single module to the user. Plugins can be
created 'monophonic' (e.g. a reverb) or 'polyphonic' (e.g. a VCF). In
the
latter case all voices receive the same control parameters from the GUI.
At the border between a mono and a poly module, signals are duplicated or
mixed as you describe. Nothing special has to be done by the user.
Where does this 'break the module metaphor' ?
Well if it requires changes to the plugin code then it is breaking the
metaphor somewhere - the AMS engine should be able to habdle the
duplication without requireing support from plugins.
- Steve
11:58 a.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 03:36:06PM +0000, Steve Harris wrote:
On Mon, Nov 17, 2003 at 04:26:23 +0100, Alfons
Adriaensen wrote:
AMS does not require changes to the plugin code, and does not in any way
depend on the things I proposed. It handles polyphony without any problem
with current plugins that were not specially designed for this mode.
The purpose of my proposition is to enable a plugin writer (if he/she wishes
to do so) to detect when the plugin is used in this way, and maybe optimise
his code. For example, control rate computations (which can be elaborate and
even more complicated than the audio rate code) could be shared by all voices.
I have some plugins that are able to create their own GUI (by using a shared
library that makes them look like a single client to the X-server, and that
also provides a standard set of widgets). Clearly, all instances that belong
to the same module should share the same GUI. The proposed way of using
the standard 'lifecycle' functions enables them to do this correctly.
--
FA
This is exactly what AMS is doing in polyphonic
mode. Most internal modules
(PCM out is the obvious exception) are created as many times as there are
voices, but still look like a single module to the user. Plugins can be
created 'monophonic' (e.g. a reverb) or 'polyphonic' (e.g. a VCF). In
the
latter case all voices receive the same control parameters from the GUI.
At the border between a mono and a poly module, signals are duplicated or
mixed as you describe. Nothing special has to be done by the user.
Where does this 'break the module metaphor' ?
Well if it requires changes to the plugin code then it is breaking the
metaphor somewhere - the AMS engine should be able to habdle the
duplication without requireing support from plugins.
12:05 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 04:57:07PM +0100, Alfons Adriaensen wrote:
The purpose of my proposition is to enable a plugin
writer (if he/she wishes
to do so) to detect when the plugin is used in this way, and maybe optimise
his code. For example, control rate computations (which can be elaborate and
even more complicated than the audio rate code) could be shared by all voices.
I see, but I still dislike the idea FWIW :)
I have some plugins that are able to create their own
GUI (by using a shared
library that makes them look like a single client to the X-server, and that
also provides a standard set of widgets). Clearly, all instances that belong
to the same module should share the same GUI. The proposed way of using
the standard 'lifecycle' functions enables them to do this correctly.
This is a valid point, and and interesting technique, does it work with
arbitrary host toolkits? How do you bypass the hosts connection to the X
server?
- Steve
12:47 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 04:04:46PM +0000, Steve Harris wrote:
It doesn't depend on the host's support in any way. The host doesn't even
have
to be an X client - the same library can be called by for example an internal
JACK client.
The shared library creates a thread for the X code, connects to the X-server
as a new client, and provides a set of widgets (C++ classes actually) and some
other code as a dedicated 'mini-toolkit'. It also provides methods for lock-free
communication with the audio code. The X-connection and thread are shared by all
plugins.
Plugin code remains relatively simple since most of the hard work is done by the
library. But it has to be C++.
Maybe I'll present this in Karlsruhe next year. ATM it's 'for personal use
only'
as it touches on too many sensitive areas, and I don't want to start new GUI /
toolkit / language wars. :-)
--
FA
I see, but I still dislike the idea FWIW :)
Well if you want the functionality (and I do) I see no other way,
except by doing something that would break the existing API.
I have some
plugins that are able to create their own GUI (by using a shared
library that makes them look like a single client to the X-server, and that
also provides a standard set of widgets). Clearly, all instances that belong
to the same module should share the same GUI. The proposed way of using
the standard 'lifecycle' functions enables them to do this correctly.
This is a valid point, and and interesting technique, does it work with
arbitrary host toolkits? How do you bypass the hosts connection to the X
server?
1:25 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 05:46:20PM +0100, Alfons Adriaensen wrote:
It doesn't depend on the host's support in any
way. The host doesn't even have
to be an X client - the same library can be called by for example an internal
JACK client.
That sounds like incredibly useful software.
Plugin code remains relatively simple since most of
the hard work is done by the
library. But it has to be C++.
I think I'd be prepared to live with c++ for that :)
Maybe I'll present this in Karlsruhe next year.
ATM it's 'for personal use only'
as it touches on too many sensitive areas, and I don't want to start new GUI /
toolkit / language wars. :-)
Heh, you can never have too many toolkit wars ;)
- Steve
1:45 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
It doesn't depend on the host's support in any
way. The host doesn't even have
to be an X client - the same library can be called by for example an internal
JACK client.
The shared library creates a thread for the X code, connects to the X-server
as a new client, and provides a set of widgets (C++ classes actually) and some
other code as a dedicated 'mini-toolkit'. It also provides methods for lock-fr
ee
communication with the audio code. The X-connection and thread are shared by a
ll
plugins.
have you considered the possibility that Xlib is not statically
thread-safe? if there are any globals in the implementation of Xlib,
this scheme will fail as soon as the host is using Xlib as well.
otoh, AFAIK, XFree86 is pretty much clear of all globals, so it
probably is a non-issue.
ps. fons - even if its not ready for use as a JACK client, i'd really
like to get a look at your SMPTE generating code. ardour really needs
it badly - its become more and more clear that we can't support MTC
master mode without kernel patches.
--p
6:08 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
Hi Paul,
have you considered the possibility that Xlib is not
statically
thread-safe? if there are any globals in the implementation of Xlib,
this scheme will fail as soon as the host is using Xlib as well.
Yes, and if X does its bookkeeping in terms of 'processes' and not
'clients'
the same will happen. But it seems to work.
otoh, AFAIK, XFree86 is pretty much clear of all
globals, so it
probably is a non-issue.
That's reassuring :-)
All this would be a lot simpler if the common GUI toolkits would provide
a call that would allow one to create a raw X window that wil be
connected to their internals and that gets its raw X events delivered
to a user specified callback. From there on, the toolkit or library used
by the plugin takes over. That's really all that's needed.
ps. fons - even if its not ready for use as a JACK
client, i'd really
like to get a look at your SMPTE generating code. ardour really needs
it badly - its become more and more clear that we can't support MTC
master mode without kernel patches.
If you just need the generator, I can probably concoct something readable
somewhere this weekend. I'm currently in the process of moving from SL 8.2
to SL 9.0, not everything works yet, and my system is in a pretty chaotic
state :-)
--
FA
6:40 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
All this would be a lot simpler if the common GUI
toolkits would provide
a call that would allow one to create a raw X window that wil be
connected to their internals and that gets its raw X events delivered
to a user specified callback. From there on, the toolkit or library used
by the plugin takes over. That's really all that's needed.
i've been talking about this a lot on the GMPI lists as
well. yes, thats pretty much exactly what is needed. how can it be so
hard for these people to understand that they cannot always control
or own the event loop?
ps. fons -
even if its not ready for use as a JACK client, i'd really
like to get a look at your SMPTE generating code. ardour really needs
it badly - its become more and more clear that we can't support MTC
master mode without kernel patches.
If you just need the generator, I can probably concoct something readable
somewhere this weekend. I'm currently in the process of moving from SL 8.2
to SL 9.0, not everything works yet, and my system is in a pretty chaotic
state :-) 
7:08 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 05:39:22PM -0500, Paul Davis wrote:
Well, we COULD discuss this with the QT/GTK folk. However, I personally
would not have the first clue where to look or what to ask for. I just have
never done X programming. Never wanted to. :)
All this would
be a lot simpler if the common GUI toolkits would provide
a call that would allow one to create a raw X window that wil be
connected to their internals and that gets its raw X events delivered
to a user specified callback. From there on, the toolkit or library used
by the plugin takes over. That's really all that's needed.
i've been talking about this a lot on the GMPI lists as
well. yes, thats pretty much exactly what is needed. how can it be so
hard for these people to understand that they cannot always control
or own the event loop?
8:49 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
All this would be a lot simpler if the common GUI
toolkits would provide
a call that would allow one to create a raw X window that wil be
connected to their internals and that gets its raw X events delivered
to a user specified callback. From there on, the toolkit or library used
by the plugin takes over. That's really all that's needed.
i've been talking about this a lot on the GMPI lists as
well. yes, thats pretty much exactly what is needed. how can it be so
hard for these people to understand that they cannot always control
or own the event loop?
9:56 p.m.
New subject: [linux-audio-dev] LADSPA: proposition for polyphonic use of plugins
On Mon, Nov 17, 2003 at 07:48:53PM -0500, Paul Davis wrote:
Excellent. Please keep us appraised :) QT and GTK would take care of the
majority of Linux issues.
Well, we COULD
discuss this with the QT/GTK folk. However, I personally
i already am :)
7668
days inactive
7668
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
5 participants
participants (5)
-
Alfons Adriaensen -
Fons Adriaensen -
Paul Davis -
Steve Harris -
Tim Hockin