19 Dec
2002
19 Dec
'02
5:17 p.m.
On Thursday 19 December 2002 21.09, Steve Harris wrote:
On Wed, Dec 18, 2002 at 07:12:29 +0100, David Olofson
wrote:
> * Raw data blocks belong to the sender.
>
> * Received raw data blocks are only valid until the
> the plugin returns from process().
>
> * Senders can figure out at init time how many
> and how big data blocks they need.
[...]
Well, they would presumably keep the values from the
previous data
block.
Yes, but *where*?
A float control has the whole value in the event, and it's small and
fixed size, so you can just copy it into your internal Control data
array. Then you just throw the event struct away.
With raw data block events, OTOH, you get a block that could be of
any size. *If* you could copy it somewhere, you'd just throw the
event away, and the sender would officially own the block from then
on.
Problem is that if you can't copy the data, you'll need the block
until you get a new one.
We could either have an explicit "free_block()" action of some kind,
or we could just do it implicitly like this:
Cycle Actions (S == sender, R == receiver)
-----------------------------------------------------------
1 S: Sends an event with block X to R.
R: Gets the event and uses block X.
(R owns block X.)
2 S: Does nothing.
R: Does whatever.
(R owns block X.)
3 S: Sends a new block Y to R.
R: Gets block Y, and forgets about block X.
(S now owns block X again.)
(R owns block Y.)
4 (Sender may now reuse block X.)
Note that this *does* work even if R decides to forward the block to
a third plugin. Since blocks are read only, you may even "keep" the
block and still pass it on. The only requirement is that when S sends
a new block to replace it, the old block implicitly becomes property
of S again, before the next cycle begins.
That is, you can't delay raw data blocks with this scheme, without
copying the blocks. No major issue, though, as you're normally
supposed to have your own blocks anyway, if you have raw data
outputs. (You don't *need* to if you're not changing the data in the
block - but we can just consider delaying a form of change.)
This might look a bit hairy, but the rules are quite simple:
* When you get a new block, you must forget about
the old one before returning from process().
* When you send a block of your own, it is property
of the receiver until the cycle after you've sent
a new block to the same control.
This will cause trouble in hosts that have sub-nets with smaller
block size, if you're sending from within such a sub net. You'll
expect a block to be back in the cycle after the one you in which you
send the new block - but if the receiver has a larger block size, it
won't have a chance to run before you want your block back!
Ok, such a host *could* deal with this, but there's another bunch of
RT memory management issues...
No, I think this calls for either ever prevent RT memory management,
or that blocks are handled by the host and marked with their "home
address". That is, any plugin may set up one or more global memory
block pools. The host's "free_block()" call will know where each
block belongs.
//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 -'
--- http://olofson.net --- http://www.reologica.se ---