Re: hi && API && sampler plugin

[David O'Toole]

>       i've made a sampler plugin which seems to work ok.  it needs
> to be cleaned up a bit though.  i don't see the docs on the wave table
> stuff, so as of now, it uses it's own loading and specification file.
> (it's at http://async.cx/octal/ for people's amusement, but it might
> not make a whole lot of sense at this point).

It's good that you checked out that sandbox when you did, since the last
few days' CVS won't compile :-) Anyway, the wavetable API should be in
place as soon as I finish up the mixer tweaks I've been working on---if
this is ed__ from IRC you'll remember basically what it will look like.
That DLS spec was helpful in outlining what basic data should be stored
globally in the sample bank for each wave, so as long as you can get
access to those data, you should be fine. I'll also look at what you've
got online, although without a lot of docs it is a bit tricky to figure
out what goes where.

> which is ok for a mono-voiced plugin, but in the case of a
> poly-voiced one isn't enough information...you need to know the note
> which should be turned off.

That's what the channel parameter is for... the scheme is worked out and
there was some discussion on the list, the only problem is that the
relevant section in the docs hasn't been put in. Essentially the host
keeps track of which voices are in use by a multi-voice machine, and
recieves notifications from the machine when a voice is no longer in
use. (This is so that the host can allocate channels on the fly, and
thereby match up events meant for a particular note with the channel that
note is playing in... after all the decay/release stuff could keep a note
going longer than the host expects, so I felt it best not to rely on
being able to pre-determine channel numbers from plain sequence data.)

Things to discuss soon.... a standard for how machines are packaged and
delivered (source tarball, etc)

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