Re: OCTAL and LADSPA

[Fredrik Roos]

On Mon, Jan 29, 2001 at 06:10:11PM -0500, David O'Toole wrote:
> > Well i think their approach is the only viable (IMHO), if you don't let 
> > plugins
> > draw their own control boxes. One of the most annoying things about Buzz
> > is that the control boxes start to get confusing when you have to deal with
> > more than 5-6 parameters per plugin. So far the only improvement over that
> > i have seen in octal-api is the selection box. What about triggers, vertical
> > range widgets or layout features?
> 
> Those will all be in there.

Glad to hear that :)
> 
> (Notice how the custom-UI model does not account for the multi-tracking
> feature of synth-type/tracker-type machines. How would it behave? Do we
> create another instance of the interface to control the next track's set
> of parameters? If the plugin author used skins, do we draw the whole
> thing over again per track? How big does it get?)

How is it supposed to work now? Is there an alternative to just duplicate 
the UI for each track?

> 
> Doing it this way loses the ability to do pixmap skins or to place
> controls with pixel-precision, but I think it's a decent trade given that
> it's very easy to implement and deals very easily with the other issues.
> 
> > Is there any good reason why plugins can't/
> > shouldn't provide their own gui?
> 
> 1. It doesn't allow preferences. Some people *hate* round knobs onscreen
> and can't use them, some people swear by them. If the knobs are hardcoded
> into the plugin then you can't change them.

True. But how do you create a good widget layout if you don't know if a widget
is a slider or a knob? 

> 2. The same goes for layout. If we want to create "consoles" later on
> where all kinds of controls from different machines can be "docked", it
> will be difficult to do if machines are opening their own GtkWindow.

I like that idea.
> 
> 3. It's complicated and a lot more work. The plugins don't have their own
> thread of execution, so they can't be polling an event queue for changes.
> Machines can't run in the same thread as the GUI, so now each will have to
> deal with synchronization/locking issues when it responds to GUI events.
> That is in addition to the coding a machine writer would have to do to
> make their widgets come up, whereas that is handled by the host in the
> Octal approach.

In VST, the host can handle the UI for simpler plugins, but the plugin is still
allowed to supply it's own. Isn't it possible for  the plugin to construct a 
GtkWidget * and pass it to the host, to be handled by the UI thread? 

> You can solve a lot of the above by creating a new XP-meta-toolkit, but
> doing that is likely to be a larger project than Octal itself. I am not
> interested in reinventing GTK+/libglade. Not only that, but suddenly the
> interfaces no longer look or act like anything native to the OS (see
> Mozilla for an example of making your own toolkit).

Well i have never seen a soft synth UI based on native widgets that actually
works and personally, i don't care about consistency. Maybe this can be
solved by application specific gtk-themes?

    --fredrik