Re: OCTAL and LADSPA

[David O'Toole]

> 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.

Plugins choose the widget type for each parameter, from a set of
available controls. Now at the moment in the machine interface header
file, there happens to be only one type (slider) :-) but there will be
more by the time we reach 1.0 and probably more will come over time
as machine writers discover what would be good common widgets to share.

Right now there happens to be only code to create horizontal sliders,
but it will be very easy to add more types. GTK+ even comes with a
curve/envelope editor, so we can do things like Buzz's "WaveAss"
interface. Another thing I am planning is a GTK+ widget that presents a
draggable handle box that's set in an x/y grid, so that you can drag this
handle around and modify two parameters at the same time. (I can think of
how to write this easily in GTK, but I have not yet learned how to
subclass widgets.)

One benefit of this is that any new widget type is accessible to any
machine, they won't be locked up in some machine's custom UI code. I think
if there is really a need to create a new widget that controls audio
parameters, other machines might want to use it too.

One minor but nice thing is that each track full of parameters has a
titled GtkFrame that visually sets it off from its neighbors. This should
break things up a little even for machines that use several widget types.

(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?)

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.

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.

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.

4. It is oriented toward effects where you have only one instance of each
parameter (see paragraph above)

5. It makes machines less portable when they refer to GUI specifics

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).

> Anyway, i like what you have done so far, and i am looking forward to a first
> usable release.

Thanks :-)


-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal