[linux-audio-dev] Plugin APIs (again)

[David Olofson]

On Tuesday 10 December 2002 07.56, Tim Hockin wrote:
> > > the RT engine - *unless* you decide on a number of VVIDs to
> > > allocate for each Channel of every plugin, right when they're
> > > instantiated.
> >
> > That sound most sensible. The instrument has to allocate voice
> > table space, so there is likly to be an internal (soft) limit
> > anyway.
>
> so this is the bit about VVIDs that bothers me - inefficient
> carving.
> * Must get more VVIDs than the instrument's polyphony
> * Must get enough so that if something else asks you can dole some
> out
> * Must get as few as possible to limit wastage.

Yes, exactly.

It wouldn't have been a problem if you could just assume that all 
plugins handle the full 32 bit range of values, but that forces 
plugins to do quite some work to find the voices. No big deal with a 
few voices, but with 128 voices, most of which are in use, searching 
starts to consume quite a lot of cycles...


> As was expressed - anyone who has a good idea how to work this out,
> speak up.

Indeed.

Anyone has a fast and simple hash/search solution? Operations needed:

	* Mark object with a 32 bit value that someone gives you.

	* Find previously marked object, using the same 32 bit value.

This is for up to 256 objects or so; the kind of polyphony one could 
expect most synths to deal with. (I assume that with less than some 
15-30 active voices, it's faster to just search the active voices, 
provided they're in a linked list or something.)


Anyway, I think that would be a solution to the wrong problem.

We just need to address objects in a way that doesn't force us to 
wait for someone to tell us which particular object we actually got. 
We want the plugins to be able to do the allocations themselves, mark 
the allocated objects, and then *quickly* find them again, when 
referenced.

There *has* to be a better solution for this.


Hmm... IIRC, someone initially misunderstood my design and thought 
the VVIDs were a common resource maintaned by the host.

Well, why not!?

Have the host maintain a single array of void pointers. A VVID would 
be an index into this array. When someone wants to send events to 
something with voices, it'll ask the host for a range of VVIDs. In 
effect, it will be given those VVIDs, and a corresponding number of 
actual entries in this array.

Now, when you send a VVID to a synth, the synth will take that as an 
index into the host managed array, and so, it has some actual memory 
assigned to this particular VVID, where it may put anything it wants. 
How about an actual pointer to the allocated voice, or NULL when the 
voice has been stolen, or if one couldn't be allocated? (For voice 
stealing, you'd obviously want to mark the voice with the VVID or a 
direct pointer to the VVID entry, so it can be updated as required.)

This is optional for plugins, of course. The VVID is now not just 
Channel unique, but *host* unique, so you can still use the actual 
value for mark/search.


Sounds better?


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---