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 - 16:26:34 EET
On Thu, Jan 15, 2004 at 02:52:45 +0100, Alfons Adriaensen wrote:
> On Thu, Jan 15, 2004 at 11:18:10AM +0000, Steve Harris wrote:
>
> > It's not really possible for the plugin to create a UI independently, the
> > UI control has to be routed via to host to allow automation.
> >
> > I prefer a model when the host is reponsible for requesting the UI
> > creation, the UI talks to the host (eg. via OSC) and the host relays the
> > changes, via th LADSPA API to the plugin.
>
> The best the host can do ATM is to create widgets based on the port hints.
> These do not provide any information on how the parameters may be related
> or interact. Also, not all parameters types are available.
> All this could be in a separate file of course, but I doubt if it's possible
> to define a configuration format that captures all possible interactions
> and relations that a module designer can think of.
I was thinking that the UI code would be a piece of software, not just a
description, that would be run my the host - either a seperate binary or a
part of the plugins .so file.
Its important that it communicates through the host though.
> > > And that's a pity. Since all ports in LADSPA are pointers, even if they
> > > only carry a single value for each call to the process fuction, setting
> > > the pointer to NULL would have been the obvious way to signal an unconnected
> > > port. But it's too late now to do adopt this obvious convention.
> >
> > Obvious, but highly inconvienient for plugin authors. It means you have to
> > check for the connected state of every input and have some kind of
> > fallback plan for when its not connected.
>
> This can be as simple as connecting to your own zero-valued buffer, if
> that is what you prefer to do with an unconnected port.
Yes, but the 95% of plugins that dont have any special behaviours have to
do this, you have to find a buffer of a suitable length from somewhere
(without calling malloc) and its not back-compatible.
NB the GMPI requirements - which are done from scratch - require that
plugins be able to run without any regard for port connection state.
> A better solution would have been to have a bit in the hints saying that
> this port must always be connected by the host, if necessary to a dummy buffer.
> Or even a single bit for the entire plugin. But again it's too late for that.
>
> OTOH, we could introduce the reverse: a bit in the hints requesting the host
> *not* to connect a dummy buffer, but instead to set the pointer to NULL if
> the port is unconnected. This would be backwards compatible, AFAICS.
Yes, but why not just have some way of telling if its the dummy buffer?
The plugin might want to be told, but still have a dummy buffer of the
right size available, and the host still has to have a (single) dummy buffer
available for plugins that dont support it. I dont see any reason to pass
NULL.
> > 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.
>
> I'd agree, but not if the common format is defined to be lowest common
> denominator, and dumbed down to make life as simple as possible for simple
> cases at the expense of the more general. That's the way MS Word was
> designed, and you all know the result :-)
No, that is not the way word is designed. Word has the most complex
interface and system imaginable, to achieve a very simple task. Think of
all the pontless options that appear in buttons when you start work, most
users dont even know what they do, much less use them. Word makes writing
simple docuents hard (a difficult to use and complex style system with
useless defaults whihc makes it easier to use hand styling), and it makes
writing complex documents... hard.
A counter example is LaTeX, writing simple documents is very easy, and if
you need to lay out complex equations, well you can still do it, but its
difficult (its a difficult problem, other tools that try to simplfy it
do it badly).
Take for example table matrix sharing between oscilator plugins in LADSPA
- LADSPA offers no builtin mechanism for doing that, but its still
possible. It means that all other LADSPA plugins are still simple, and the
handful that need table sharing are slightly more complex than they could
have been if LADSPA supported table sharing. That is a net win.
My philosophy is make the 95% common case easy and the 5% hard case
possible. Optimising for the 5% hard case at the expense of the 95% easy
case is a bad idea. Think SGML v's XML, CORBA v's SOAP, VST v's DirectX
(slightly more ontopic).
DirectX is more capable than VST, but its hardly used in comparison
because the API is such a pain, and its so complex. It makes easy things
hard.
> On a more general tone: I think we should be less afraid of complexity
> and learning curves. Dumbing down maybe required in order to be popular,
> but that's not my aim. And finally, I believe diversity is a Good Thing.
I agree about diversity, but disgree totally about the other points. In my
experieince complex systems are generally failures - they rarely offer
anything thats a significant advantage over (comparativly) simple systems,
and modular synth modules are simple systems - if there not then youre
doing something wrong.
- Steve
This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 16:29:03 EET