[gmpi] Re: Topic 7: Audio packaging
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 4 Jun 2003 15:00:17 +1200
> For the record, I mostly agree with you about raw access. I don't have a
> problem with a buffer struct, though. Whenever we talk about flags, I
> always ask myself:
>
> Where does it impose the conditional? Connection-time is better than
> per-buffer. Init-time is better than connection-time. I don't have a
> problem with capabilities flags, so long as they don't need to be
evaluated
> every timeslice. We need a solid and well documented set of assumptions.
Yea, very well put.
We're discussing subjects like "do audio buffers include flags (silent or
'running')".
Perhaps we're confusing "audio packaging" and "connection state"?
Is the audio buffer the place to store flags about connection state?
I'm sounding a bit intellectual here.........how can i give a concrete
example?.....
Perhaps we need something like the concept of a pin. Plugins have pins
(input and output). Pins have flags, and pointers to buffers.
So you can ask a pin "are you connected"....or "are you feeding
magic-silence",... or "are you sharing you buffer with an output pin
(process-in-place)"......
You don't ask the buffer, you ask the pin.
There's a seperation between what a buffer does (passes audio data), and
what a pin does (tracks the state of that connection).
Is this a 'cleaner' model?
My justification is that passing buffers consume a large bandwidth, keep
them lean. Setting a 'silence' flag on an input pin is low-overhead (done
when user hits "Mute", not every single buffer).
Oh well, food for thought.....
Jeff "stuck record" McClintock
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
