Re: Those API revisions, plus some thoughts

[ben]

> ----------------
> 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. 
> 
I think this is a good idea.  Another benefit is that if your song
contains large chunks of data (like large samples), you're not writing
that data to disk every time you save the song.