Subject: Re: [linux-audio-dev] Mustajuuri -> LADSPA plugins.
From: Tommi Ilmonen (tilmonen_AT_cc.hut.fi)
Date: Wed Mar 28 2001 - 10:39:34 EEST
Hi.
> >2) Many Mustajuuri plugins have a very optimized GUI. While some can be
> >transformed to the (upcoming) LADSPA-XML-spec there are others that are
> >really difficult/pointless to render via XML wrapping. The example is
> >again the EQ plugins. The graphical EQ in particular is a nice example;
> >The current GUI does not a have a single slider, instead there is a graph
> >that can be adjusted by simply drawing on it. A large collection of
> >sliders/knobs/whatever would be a horrible alternative. I don't see
> >any practical way to leavy this rendering process to the host. So anybody
> >wishing to use the EQ with a GUI should be able to upload the Qt-based GUI
> >stuff also. There are other plugins that also rely on heavily involved
> >graphics (level- and tuning meters, oscilloscope). So most hosts would not
> >be able to take full advantage of these plugins.
>
> i think you should propose new XML entities for the GUI spec that
> would allow these to work, plus some text to suggest how the
> host/plugin interaction would actually work. i think these would be an
> excellent idea. and if you don't, i will :)
It is possible to create new XML entities, but there is the down-side that
then all hosts would need to implement them.
Besides, the user interfaces can be really different. We would need new
XML-spec for any new GUI element (right ?). Example: A modeling reverb
plugin might want to show an interactive 3D-model of the room to
the user. So, if you wanted a GUI like that, then we'd need a XML spec for
3D rendering and interaction and everybody needs to implement the XML spec
(or lose the plugin). There are many GUI strategies people have come up
with (and will come up with). If we want to support all of them then the
XML-spec will become huge.
I do agree XML is fine for many (simple) cases. And then there are the
cases where you can just forget it. There is little point in trying to
wrap all possible things behind an XML-layer.
So I am saying that the creation of strongly customized user interfaces is
best left to the plugin programmer, completely unlimited by any XML-spec.
> >3) The parameter systems of LADSPA and Mustajuuri differ. LADSPA has a
> >CSound-like control parameters (updated between cycles), while Mustajuuri
> >has time-stamped event system (with events delivered between cycles). The
>
> who says LADSPA works like this ? i know the header implies that, but
> there's nothing to stop the plugin from completely separating the
> control ports from the actual parameters, and in fact, the good
> plugins (e.g. steve harris' set) increasingly do this. that allows you
> to view a change in the value of the control port as an "event", and
> then adjust the parameter internally as you wish.
This is what I was expecting to do. So the plugin checks all control
parameters to see if they have changed and generates events for itself.
Sidenote: When a user adjusts a parameter in Mustajuuri an event is
generated. This event is passed to the LADSPA plugin wrapper. The wrapper
turns the event to a value change in a control port. A "Harris-plugin"
then converts the value change back to an event and processes it. Cool (!)
> >4) Mustajuuri supports many parameters besides floating point data. In
> >particular it supports strings (for filenames etc.) and MIDI events. These
> >plugins cannot be used at all with current LADSPA API. I guess this is
> >simply inevitable (I know LADSPA is not intended to fit all purposes).
>
> I agree with you. Remember what LADSPA was intended to be useful for:
> the endlessly repeated, audio API independent, pure-computation
> algorithms we all want to see in audio apps. If you keep this in mind,
> it provides more of a justification for why it doesn't handle MIDI or
> string based parameters (though perhaps not *enough* justification :)
I do not complain about LADSPA. It does what it is intended for. I might
be unhappy about some of its features, but that is my problem -- not
LADSPA problem. Right now I am trying to find the optimal way to go about
this. I am also making sure I have understood LADSPA correctly.
Tommi Ilmonen.
This archive was generated by hypermail 2b28 : Sat Apr 07 2001 - 15:40:12 EEST