octal-dev
[Top][All Lists]
Advanced

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

Re: Greetings and a couple of other things


From: David O'Toole
Subject: Re: Greetings and a couple of other things
Date: Mon Sep 24 14:15:05 2001

> I have noticed, however, one small problem (well, one worth mentioning
> :-) It seems that widget type 'entry', while listed in the docs, is
> not implemented. Or at least,  I get:

Yeah, that control is not implemented yet. :-)

> The other thing I noticed is that having the 'param' type be a float
> is very limiting. I'd like to get more info back from the widget than
> merely a number. Ideally, I'd like the entry widget to return a char*.

Do you mean some kind of facility where arbitrary command strings can be
passed to the plugins? I can see how that would be useful, but I prefer
the MIDI approach of named parameters and encoding commands into numbers
delivered to certain "ports", which you can do quite a bit with. 

The whole point of the parameter/type system in Octal is to impose
structure on communication between plugins and the host and
user---thereby enabling a sequencer and GUI that can edit any aspect of
a plugin.

If everything is just strings without consistent structure, well yes we
can store and send strings at the right time, but how do you edit them,
visualize them (like parameter sweeps/curves)? The plugin writer then
would have to choose between either writing an extension so that the
sequencer knows about the new data type (this would be especially the
case with your void* idea) or just not letting anyone sequence that
parameter or port, in which case implementing it is a waste of time (try
restoring a plugin's state between performances if some of its
parameters aren't sequenceable.) 

> But it might be nicer if param was a void*, and then widgets could
> pass back an arbitrary data structure. This would let widget builders
> make more complicated widgets.

There is neither a need for plugins coming with their own widget
builders, nor a facility to add them to Octal anyway---the widget system
is not exposed as part of the OX_API for machine writers to use. The
plugins have to remain toolkit and platform-agnostic, otherwise you have
the problem that plagues a lot of Windows plugins that build their own
GUI---you can't use them anywhere else. 

The problem goes further if you pass void pointers around where the
plugin defines some data structure. Someone needs to manage the object's
lifetime and storage, someone needs to manage how it will be saved and
loaded in *.OXF files, and then we'd need to rely on plugin writers
never changing the save format for that data (or handling old formats if
they do change it.) One requirement for this project is to prevent data
obsolescence, i.e. a new OS or plugin version should not break a song
you made, you should be able to compile the plugins and Octal itself and
get going... plugins streaming ad-hoc data to save files is asking for
trouble. 

But don't worry, I have seen relatively few plugin GUI's that did
anything beyond wheels, sliders, and pulldowns, and for things beyond
that (envelope edit, 2-d axis slider, both planned) we should have a
single implementation that many plugins can use after the need for a new
control type has been agreed upon. 

Wow that's a lot of material... :-) but I guess it shows why the
decision was made.  

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




reply via email to

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