octal-dev
[Top][All Lists]
Advanced

[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










reply via email to

[Prev in Thread] Current Thread [Next in Thread]