Those API revisions, plus some thoughts

[David O'Toole]

The new stuff has been put into CVS. The changes are mostly:

1. parameter info is now specified as an array of strings
2. the "param" typedef is now floating-point, so you may have to stick
some (int) in places.
3. several minor name changes, plus the new channel thingy

The documentation (both online HTML and LaTeX in CVS) have been updated
with the new API info... please let me know about any mistakes. 

Luka and Matt and anyone else who's working on machines, please let me
know if you have any questions about the changes... I may have left out
something, or there may be a bug I didn't anticipate. 

Now that these little bits are stabilized, the mixer can be finished,
and we'll reach Milestone 1 in no time! I thank you all for your
interest in the project and your volumes of feedback, ideas,
inspiration, etc. :-)

----------------
Random thoughts on file formats:

I'm thinking we should take advantage of the filesystem. A song is a
directory; inside is a large text file (possibly XML but it doesn't
really matter) containing all the Octal setup info (machine connections,
param states, patterns, arrangements, wave maps). Resources like
wavefiles and such are just 001.wav, 002.wav (or perhaps they keep their
original names.) To deliver a song as a unit we can use .tar.gz on that
directory (or you can use MP3, if you don't need someone else to edit
it.)

Initially I was resistant to doing it this way... I wanted everything to
be thunked into one big file. However, then the host needs special-case
code to deal with any kind of data resource. It might be better to allow
a general resource facility where the host loads the data from disk, and
gives the machines access to it.  What really got me thinking on these
lines is something Neil was saying a while back, about a machine that
used a frequency-spectrum file to define a sound, rather than a straight
waveform.  If these are simply files, we can make UNIX-ish filters for
them and have other programs operate on them or generate them, just as
with wavefiles. 

This sounds pretty simple to do. Instead of specific wave maps, we'd
have "resource maps" that identify a file resource based on some input
parameters. Or something to that effect. Let me know what you think. 

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