16 Jul
2004
16 Jul
'04
9:35 a.m.
I'd like to announce a new version (numbered 0.4) of the DSSI synth
plugin API proposal.
http://dssi.sourceforge.net/
Disposable Soft Synth Interface (DSSI, pronounced "dizzy") is a
proposal for a plugin API for software instruments (soft synths) with
user interfaces, permitting them to be hosted in-process by audio
applications. DSSI 0.4 was constructed by Steve Harris, Chris Cannam,
and Sean Bolton.
DSSI is intended to be simple, especially for plugins;
GUI-toolkit-agnostic; and slightly biased towards familiarity with
MIDI. It's proposed as an interim measure until bigger and better
things come along: hence "disposable".
The 0.4 release addresses the problem of efficiently managing shared
resources among instances of a plugin by providing explicit support
for plugins that may be run in a group. It also clarifies issues
such as thread-safety and fixes a few other problems with the 0.1 API
identified on LAD and elsewhere. We think the 1.0 release could look
pretty much the same as this 0.4 version, barring any more stupid
mistakes.
The release contains the RFC, the dssi.h header file, example host and
plugin code, and now the all-important FluidSynth wrapper plugin.
Comments to LAD please.
Chris
16 Jul
16 Jul
10:22 a.m.
On Fri, Jul 16, 2004 at 12:52:28PM +0100, Chris Cannam wrote:
I'd like to announce a new version (numbered 0.4)
of the DSSI synth
plugin API proposal.
From the RFC:
The host does not send updates to the UI for port
changes that the
UI itself initiated; likewise the UI must not send port changes back
to the host that the host itself initiated.
While the second part of this surely makes sense, I'm not so sure
about the first. In MCV terms, the UI is both a C and a V. With the
definition above, the host assumes that both parts 'know each other'.
This may be the case for a UI, but in general this will not always
be true. Even in the case where it is, the following should be
considered:
- The design of the UI is probably simplified by separating the C and V
functions.
- In some cases, the host may refuse to do what the UI asks for, so the
UI should not simply assume that it knows the new state after a command.
- If the UI has its own internal path to update V from the actions taken
by C, events may arrive at V out of order, for example:
1. the host sets parameter P to value X, and sends a message that
it has done so.
2. the UI sets P to Y, and displays Y.
3. the message from 1. arrives, the UI now displays X while the
actual value is Y.
More generally, not reporting the results of external commands makes
any extension to multiple C or V impossible.
--
Fons
11:28 a.m.
On Fri, Jul 16, 2004 at 02:11:45 +0200, Alfons Adriaensen wrote:
On Fri, Jul 16, 2004 at 12:52:28PM +0100, Chris Cannam
wrote:
If you take the opposit approach and echo all the UI initiated changes back
to all parties then it becomes very hard to write a UI that doesnt glitch
unpleasently during gradual changes. You /could/ tag re-echoed changes
when thier sent back to the UI, but its a bit messy and unnecessary. the
only advantage it could give is if you timestamp the host messages against
when it applied the change, and that requires ntp support, and some
complex OSC stuff to do.
I'd like to announce a new version (numbered
0.4) of the DSSI synth
plugin API proposal.
From the RFC:
The host does not send updates to the UI for port
changes that the
UI itself initiated; likewise the UI must not send port changes back
to the host that the host itself initiated.
While the second part of this surely makes sense, I'm not so sure
about the first. In MCV terms, the UI is both a C and a V. With the
definition above, the host assumes that both parts 'know each other'.
This may be the case for a UI, but in general this will not always
be true. Even in the case where it is, the following should be
considered: - The design of the UI is probably simplified by
separating the C and V
functions.
I disagree (in this case). The UI /is/ both C and V, the case where you have
a single control that has both independent C and V is extremly rare -
infact I cant think of a case where it happens in audio software and I'm
not sure how it would make sense in LADSPA.
- In some cases, the host may refuse to do what the UI
asks for, so the
UI should not simply assume that it knows the new state after a command.
If that is the case then the host just sends the correction as a normal
change. The UI control will flick to the real position, but thats
acceptable I think. Its not a common occurance.
- If the UI has its own internal path to update V from
the actions taken
by C, events may arrive at V out of order, for example:
1. the host sets parameter P to value X, and sends a message that
it has done so.
2. the UI sets P to Y, and displays Y.
3. the message from 1. arrives, the UI now displays X while the
actual value is Y.
Yes, this is a genuine problem. It is very hard to solve though, and
simply echoing all changes to all parties doesn't help.
More generally, not reporting the results of external
commands makes
any extension to multiple C or V impossible.
*External* commands are send to the UI (for this reason), its just local
commands are not echoed back. Maybe thats not clearly expressed. I belive
that this is standard practice in MVC systems, but I could be wrong.
The situation should be that changes are sent to all parties, except the
originator, and there may be multiple UIs, at the hosts discression.
- Steve
1:31 p.m.
On Fri, Jul 16, 2004 at 02:18:16PM +0100, Steve Harris wrote:
A simple button, such as the stop buttons in Aeolus.
In the first design, the buttons would light up whenever the GUI was thinking
a stop was 'ON'. As more functions (presets, grouped changes, MIDI) were added,
the logic to control this became quite complicated, and in fact the GUI thread
had to maintain a complete copy of the logic that was already present and
necessary in the audio thread.
Now the button lights are controlled by messages from the audio engine, and
by nothing else - it's much much simpler.
It *does*, if messages are kept in order. This may suggest that UDP is not
the best choice.
How does the host distinguish between an 'external' command and one that
came from the UI, if both arrive by UDP message ?
If you take the opposit approach and echo all the UI
initiated changes back
to all parties then it becomes very hard to write a UI that doesnt glitch
unpleasently during gradual changes.
This is certainly true for things like a slider. But there are a simple
solutions:
- changes are sent to all V, with an identifier of the C that requested
them. So a UI can ignore the echos to its own commands if it wants, OR
- For e.g. a slider that is being dragged, the UI can ignore all echoed
values while the drag lasts (but keep the most recent to use when the
drag ends).
- The design
of the UI is probably simplified by separating the C and V
functions.
I disagree (in this case). The UI /is/ both C and V, the case where you have
a single control that has both independent C and V is extremly rare -
infact I cant think of a case where it happens in audio software > - In some cases, the host may refuse to do what
the UI asks for, so the
> UI should not simply assume that it knows the new state after a command.
If that is the case then the host just sends the
correction as a normal
change. The UI control will flick to the real position, but thats
acceptable I think. Its not a common occurance.
This requires extra logic: if a command is accepted, the state change
is sent to all except the originator. If it is not executed, the current
state must be sent to the requester. It's much simpler to broadcast all
changes to everybody. One mechanism to rule them all...
and I'm not sure how it would make sense in
LADSPA.
Not all commands are ultimately executed by the plugins. Think of connections
in a softh synth: they are executed by the host, and it could make sense to
refuse them.
- If the UI
has its own internal path to update V from the actions taken
by C, events may arrive at V out of order, for example:
1. the host sets parameter P to value X, and sends a message that
it has done so.
2. the UI sets P to Y, and displays Y.
3. the message from 1. arrives, the UI now displays X while the
actual value is Y.
Yes, this is a genuine problem. It is very hard to solve though, and
simply echoing all changes to all parties doesn't help. More
generally, not reporting the results of external commands makes
any extension to multiple C or V impossible.
*External* commands are send to the UI (for this reason), its just local
commands are not echoed back. Maybe thats not clearly expressed. I belive that this is standard practice in MVC
systems, but I could be
wrong. The situation should be that changes are sent to all parties,
except the originator, and there may be multiple UIs, at the hosts
discression.
Imagine this list, but you don't receive your own posts... Would it be
easier to follow ? Or to implement ?
--
FA
3:36 p.m.
On Fri, Jul 16, 2004 at 05:21:15 +0200, Alfons Adriaensen wrote:
A simple button, such as the stop buttons in Aeolus.
In the first design, the buttons would light up whenever the GUI was thinking
a stop was 'ON'. As more functions (presets, grouped changes, MIDI) were added,
the logic to control this became quite complicated, and in fact the GUI thread
had to maintain a complete copy of the logic that was already present and
necessary in the audio thread.
Now the button lights are controlled by messages from the audio engine, and
by nothing else - it's much much simpler.
I see, but the DSSI case is a bit different because any such logic for
single controls must be purely in the UI, as the plugin part has no way of
updating its own input controls (its LADSPA essentially).
The equivalent would be if the plugin has a set of output controls that it
sets (to reflect engine driven complex changes), and those reflected the
true state of the controls. In this situation the current DSSI scheme will
work just fine, as the ins and outs will have seperate messages and ty
will be sent to the UI and the UI wouldn't change its widgets in response
to user action, but in response to the plugin->host->UI message.
I disagree. It makes the host logic slightly more complex and the UI logic
slightly simpler. I think thats a win. The UI can treat all updates events
exactly the same way, and it requires no explicit support.
Its also very simple in the host:
receive UI update
if its ok
apply it
else
change to it OK value
tell UI
You need that if in any case to trap and handle the "bad" value. Its also
an extreme corner case. Also note that I've not yet seen a LADSPA or DSSI
host that does this.
DSSI doesnt support that. You can only control the plugin. If you step
outside it then your going beyound what reasonable in a plugin API IMHO.
It *does*, if messages are kept in order. This may suggest that UDP is not
the best choice.
You still have this race as most protocols are full duplex, if it were a
half duplex comms then it might be OK, but still only if you only have one
UI.
I agree that TCP would be better (for other reasons), but not many OSC
implementations support it, its tricky, and I dont want to limit people to
a small set of implementations. Maybe a later version could require it.
The DSSI API does distinguish between the different OSC transports, so
adding TCP support would be easy.
How does the host distinguish between an 'external' command and one that
came from the UI, if both arrive by UDP message ?
It can tell from the message. The address path is different.
That analogy is not relevent. I have implemented a DSSI UI and I can
assure you that, in the general case, its easier not to have your own
updates echoed back. Three others have implmentation experience too, they
can speak for themselves. If you really want the update to handle some
corner case in a UI then you can just send the message to yourself :)
- Steve
- The design of the UI is probably simplified by
separating the C and V
functions.
I disagree (in this case). The UI /is/ both C and V, the case where you have
a single control that has both independent C and V is extremly rare -
infact I cant think of a case where it happens in audio software > - In some
cases, the host may refuse to do what the UI asks for, so the
> UI should not simply assume that it knows the new state after a command.
If that is the case then the host just sends the
correction as a normal
change. The UI control will flick to the real position, but thats
acceptable I think. Its not a common occurance.
This requires extra logic: if a command is accepted, the state change
is sent to all except the originator. If it is not executed, the current
state must be sent to the requester. It's much simpler to broadcast all
changes to everybody. One mechanism to rule them all... and I'm
not sure how it would make sense in LADSPA.
Not all commands are ultimately executed by the plugins. Think of connections
in a softh synth: they are executed by the host, and it could make sense to
refuse them. - If the UI has its own internal path to update V from
the actions taken
by C, events may arrive at V out of order, for example:
1. the host sets parameter P to value X, and sends a message that
it has done so.
2. the UI sets P to Y, and displays Y.
3. the message from 1. arrives, the UI now displays X while the
actual value is Y.
Yes, this is a genuine problem. It is very hard to solve though, and
simply echoing all changes to all parties doesn't help. More generally, not reporting the results of external
commands makes
any extension to multiple C or V impossible.
*External* commands are send to the UI (for this reason), its just local
commands are not echoed back. Maybe thats not clearly expressed. I belive that
this is standard practice in MVC systems, but I could be
wrong. The situation should be that changes are sent to all parties,
except the originator, and there may be multiple UIs, at the hosts
discression.
Imagine this list, but you don't receive your own posts... Would it be
easier to follow ? Or to implement ?
7235
days inactive
7235
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Alfons Adriaensen -
Chris Cannam -
Steve Harris