[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Those API revisions, plus some thoughts
From: |
luka |
Subject: |
Re: Those API revisions, plus some thoughts |
Date: |
Sun Mar 25 17:15:01 2001 |
User-agent: |
Mutt/1.2.5i |
> The new stuff has been put into CVS. The changes are mostly:
hoo! good news
fixing starts tomorrow... :)
shouldn't take soo long
> 1. parameter info is now specified as an array of strings
this sounds good, except maybe we could set the first char of the string to be
the
delimiter, so ":ha:ha:12:ha:" would work, as well as "|ha|ha|12|ha|"
so colons could stay in the strings :)))
is 'generic' now a format (type), and what about 'velocity'?
widgets are probably still 'slider','option','trigger' right?
docs are a bit inconsistent
sorry i am away from my dev machine so i havent got the source yet
> 2. the "param" typedef is now floating-point, so you may have to stick
> some (int) in places.
this is definitely a good thing, since most things are float, it seems (inside
octal anyway). now param and samp are the same...
> 3. several minor name changes, plus the new channel thingy
will look at this...
> 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. :-)
heh if constant nagging for releases is insipiring, then youre welcome!
how long till we can edit patterns? :))))
no seriously what is todo on the mixer and do you have any more ideas about
how you might implement the sequencer?
> 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.)
i agree with this attitude. it has proved itself in themes (or winamp skins)
and this could work even when a 'song' is really a 'song+animation'...
> 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
its easy to separate 'handlers' for resources by mime types
> 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.
well, i've always wanted a tracker that could read text files
(lyrics are usually text files)
> 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.
to identify a resource, i think its best to use a name/mime type pair of strings
machines can request a resource as a mime type glob and the ui/core would send
it only
valid names. if a machine needed a specific (instead of user-settable)
resource, it
could just request it directly, without a resource param.
for the machine, the specifics of files and 'handlers' are not important...
it will only get a pointer and a length of a buffer, maybe some more data if
it is a standard (sound) file. of course a mechanism that supports many
different
files that a machine can understand is a good thing.
LF