big picture stuff (was re: widget)

[David O'Toole]

::: I'm sorry.... why do all my emails end up being sooo long? :-)
:::::::::::::::::::::

> The problem is that the musician might not agree with the machine developer
> about what parameters should be global. More configuration options to worry
> about... :)

Yeah. And from what I remember, hardly any Buzz machines that I saw
actually used Global parameters. That's primarily why I left them out of
the base OX_API. This might not be a big problem.

> I was thinking more along the lines of a list of checkboxes. But regardless of
> how you do it, i see this as a very important point. I really liked buzz in 
> the
> early alpha days, when machines where simple and had at the most 5 parameters.
> Then when people started doing more complex synths, the limitations in the UI
> became too much to deal with.

It sounds like what we're looking for is some way for the machines to
communicate groups of parameters. As in,

Params 0-3 are in group "foo"
Params 4-7 in group "bar"

etc. Then the host can construct widgets (collapsible frames or whatever)
that reflect the grouping. Probably shouldn't be too hard... about as easy
as doing the layout extension I talked about the other day (also easy.)

The normal machine_type::param_specs argument is always required, but
extensions could be machine_type::param_groups and ::param_layout, things
like that. Extending it this way keeps things cleanly separated, and also
allows backward-compatibility at the source level.

> What's new in oxapi? New widgets/parameters or bigger changes?

Mostly small changes, fleshing it out to final finishing touches. Yeah,
new widgets etc (maybe not all working though.) There will be at least
package stubs and documentation for the wavetable extension.

1. I am going to give all the enumerated types some more
consistent identifiers like OX_WIDGET_SLIDER, OX_EDIT_SMALL,
OX_WIDGET_BUTTON. This is inspired by GTK's names for enums.

2. I'm going to include a section with guidelines on making machines. I
feel this is important, since machines become part of your song when you
save. If the new version of a machine breaks the parameter format, your
song might become unusable. (This happened to me with Buzz machines, as
well as doing things like installing Buzz on a new computer and not being
able to load any of my songs, and not being able to find machines when I
needed them.)

These are things like: you can add and reorder parameters but don't remove
parameters if you can avoid it.. you can change groups, controls, and
layouts but don't change the format type... you can change the short name
of your machine but NOT the long name as it is a unique identifier
(probably including the author's name like buzz machines did)... each
machine has a version number that should always go up when you do a stable
release of the machine.

Also there could be a flag for "beta" machines, which aren't stable yet,
and it will warn you when saving a song with any beta machines. I'm also
going to make provisions for having a repository, with mirrors, where a
PHP or Perl script will accept the ID of a plugin and spit back the
plaintext source or perhaps a tar file of the plugin.

I'm thinking of the machine repository being something like CTAN or CPAN:
decentralized, ensuring that when you create a song with a released
machine, the source to create that machine again will always be available
somewhere on the web.

In the long term I see OCTAL becoming something rather like TeX. A free,
compact, well-understood, well-documented program and platform for doing
plugin-based music on computers. The host can grow, evolve, change,
improve, etc, while the file format and the machines will always remain
backward compatible at the source level. Meaning that, like TeX, your
work will be safe for a long time. (Buzz and most of my songs made with
it will die with Win98 because the closed source code was lost.)

That's one reason I focused on portability and being able to extend the
API later on. The core functionality is completely unaware of any GUI
specifics, which will make it much easier to port to other operating
systems. (I am already looking into details on Windows 2000 ports.)

This might mean less flashy stuff in the short run, but in the long run it
will make your music *archival* and the platform more universal. I also
intend this to eventually go beyond pure tracking and use alternative
methods of sequencing, like piano roll (already working on that) and even
bending the limitations of step-sequencing.

But for now I'm focusing on the beta test and reaching version 1.0 :-)
Gotta stick to one step at a time.

> Looking forward to it. Actually, if you need any help with the coding, i
> would be more than happy to help out. The sooner i can stop using
> windows for music, the happier i would be. :-)



> Another suggestion: is it / will it be possible to separate the left/right
> channel from stereo machines? A trick i often used in buzz to get some
> interesting effects.

Yes.

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