octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OCTAL and LADSPA


From: David O'Toole
Subject: Re: OCTAL and LADSPA
Date: Tue Jan 30 12:12:04 2001

On Tue, 30 Jan 2001, Fredrik Roos wrote:

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

Probably not, but I think this would be more complicated if the machines
had to deal with constructing another GTK interface themselves and putting
it up or take it down when the number of tracks changes... see below.

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

Either the host creates the layout (since it knows the widgets) or the
user can just expect a weird layout if they override the widget choices.
Which I would be doing a lot with knobs, since I have never seen any
usable knob widgets. A GtkDial might be a slight improvement, but I have
doubts.

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

That has problems. IIRC creating those widgets will cause that thread to
talk to X even if they're not shown. This will cause GTK to blow up, since
two threads will be chattering with X in an unsynchronized way. (See the
GTK+ FAQ.) The solution is to acquire a lock before doing anything GTK,
and releasing that lock after you are done (they have special functions
called gdk_threads_enter and gdk_threads_leave, IIRC).

Now one very important thing about Octal is that the DSP core thread never
blocks or waits for *anything* but the audio hardware itself. Once we have
machine code (which lives in the core thread) talking to GTK in a
synchronized way, the core thread will often try acquiring the lock and
will have to wait for the UI thread to finish drawing or processing
events. This cancels out the whole point of separating the two threads,
which was to prevent a GTK+ slowdown from locking up the audio thread and
causing a dropout in the audio (you don't want this at a live show.)

We probably could have the machine's GtkWidget become owned by the UI
thread. The machine's GUI event callbacks would run in the UI thread, and
there would be no GTK sync problems. However, now those callback functions
need to somehow get the information about parameter changes back into the
core thread so the machine can respond to them.

There are solutions to that:

1. Let machine writers handle a mutex. Now we need to manually port every
octal machine if there is a Windows version, because windows threads are
different. This also presents the same problem I spoke of above, where the
core thread will have to wait for a GUI process to unlock something.

2. Expose the internal mechanism by which Octal's UI hands messages to the
core thread, and let machines use it too. This would essentially make
incidental and likely-to-change details of Octal's implementation part of
the Machine API, which I don't think is a good idea.

The machine's GUI callbacks would also need to relay all parameter changes
to the core. Current parameter values need to be kept track of, otherwise
when we save the current song or setup, the parameters will come back
wrong when we load it again.

It's not like these technical issues are completely impossible to solve,
but I don't think the work would buy us much.

If machine-managed widget layout really becomes important at some point,
there is a way to allow it without breaking portability and without
breaking the threads situation. I'd probably want to test it out before
making it part of the API, but now that I think about it it could work.
We could allow machines to specify, for each of its parameter widgets, a
set of top/bottom/left/right coordinates for the extents of that widget.
These would not be in pixels of course (that only works with skins). The
numbers would be in "table cell units" like those used by the GtkTable
layout container. Could work, would be very simple too.


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]