plugin gui's

> 4.- This implies that writting a Unit ( event generator, sound generator,
> sound modifier, Audio,input,audio output) becomes
> very complex compared with ie Buzz, VST Instrument/effect,DX Instrument
> effect,etc). To solve this i suggest the unit developers
> make a draft and a support library to simplify the common questions ( a
> default simpe UI for every  of the basic units type,etc)

The OX_API as it exists is not significantly more complicated than the
Buzz API, and I don't anticipate it changing too much from here on out.
That's because an OX_API plugin deals *only* with the following:

1. audio input
2. audio output
3. parameters (i.e. like MIDI controllers or the columns in a tracker)
4. accessing shared resources (like samples, instruments, envelopes,
etc)
5. system utilities (the musical pitch table, etc)

> 5.- Units should be developed independent from it's own UI. A unit should
> have all of its functionality and then develop a UI to
> manipulate the programa OUTSIDE the unit ( ie develop Two classes. one that
> works and One that shows)
>
> 6.- UI of any unit should be replaceable

Hmm...

I would also like to clarify one issue related to GUIs at least for the
first major release. An octal plugin must run in any version or port of
Octal without changes, on any operating system or GUI, period. Remember
that portability of one's music files is one of the main listed goals of
the project. 

Hence plugins themselves are banned from touching any GUI code, or
anything else that is OS-dependent (including the file system.) Instead,
plugins make a basic description of what kind of controls they want,
using OX_API. There is no separate OS-dependent GUI module to be written
for a plugin---no callbacks, no pixmaps, period. 

We can cover 99.9% of plugins by simply specifying "plugin parameter 2
needs a horizontal slider" or "parameter 6 needs a pulldown menu filled
in with the names from ox_describe" in the plugin's definition. Octal
then builds a control box where the controls are labeled and configured
to send events to the plugin (this already works in the main code.)
Without much additional work it will be possible to split up a control
box into tabs, for instance when there are a lot of parameters to
control, and that should keep things tidy. 

New versions of Octal can add new prebuilt control options. For
instance, an x/y axis control that allows one to control 2 or more
parameters with a single widget. Likewise for any of the zillion widgets
that audio plugin GUI's have in common: envelopes, spectra, etc. 

Making some kind of platform-independent generic UI toolkit for plugins
to use is really out of the question. Octal is not Mozilla/XUL. 

(Obviously visualization plugins need special handling but this can
definitely be handled without wrapping all of GTK :-)

> .- (only an opinion)  This is only an idea. DTO Attn: We should think a way
> that FORCES a Unit developer that his UNITS can only be  public,free,Open
> Source code. GPL or LGPL is not enought. We need something that explicitly

That can be achieved by making it useless to distribute plugins in
binary form. Plugins must compile against the OX_API headers and agree
on structure layouts. I don't anticipate people breaking the license and
doing closed-source plugins, but if it happened I could happily play
with structure layouts so that each version of Octal was subtly
different. Since the system build script would automatically recompile
all the legitimate plugins from source, nobody would notice unless there
were binary-only modules sitting around. 

I discussed the plugin issue with RMS when the project first
started---closed-source plugins would violate the license (since they
link directly at runtime with a GPL host program and use GPL header
files). I don't think breaking bin-compat would really be an iron-clad
solution if someone were really determined to make closed-source plugins
but I don't think it will really come up either. 

> prohibits any wayof making money with any (all
> parts of the project in any way, in any future,in any situation. A kind of
> Unit Official registry coudl be usefull

There is nothing wrong with selling GPL software for money. Nor would
there be anything wrong with making a music CD with Octal and then
selling the music (sans original files, even.)  
 
> We have obviously two kinds of singnals: Audio an control. And althought i
> suspect the correct way of work for the engine should be make no difference
> between them. In the way of optimization we could agree that will be treted
> differenlyu ( there' no need to process control signals 44100 times per
> second). This implies that units should declare wich input/output signal is
> audio and wich is control. But the engine should not make any asumptions on
> this.

It's unlikely that Octal will support interchangeable control and audio
"signals." Control is MIDI-like, with controller numbers and discrete
event messages when a parameter value changes. (This scheme may also
incorporate timestamps.) OX_API has no notion of generic "ports".  

I'm sure there are interesting things you can do in Max/MSP that will be
difficult or impossible because of these decisions. But I don't see how
this criterion carries any weight. Octal was never meant to be a generic
audio processing language where the user builds a one-voice FM synth by
connecting 187 primitive blocks. :-)