[gmpi] Re: GMPI reqs draft 1 (part 2) for review, paragraph 4.10

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 4 Jan 2005 10:12:19 -0800

On Tue, Jan 04, 2005 at 09:23:10AM -0800, Crudesoft wrote:
> Knob-like controls belong to the same group as signal
> generators. Button-like controls are events. I am
> talking about knob-like controls.

This is not an argument for your case, this is begging the question.  In
concept, knobs are like signal generators.  It's not necessarily the
*right* way to handle it.

> 1. Events are larger than samples. An event is at
> least a timestamp and a value, but maybe also a type
> and a clue whereas a sample is just a value. At the
> same rate samples are always cheaper than events. BTW,

Unless you modify the event stream with start/stop gates, then sampled
control streams are vastly less efficient for anything < samplerate/4 (or
thereabouts) event rates.

And you're ignoring ramps altogether.  A single ramp event can describe
sample-accurate control events for any number of samples.  Far more
efficient.

> I do not think that the sample rate has to be the same
> for all generators as long as the generators publish
> their sample rate.

You keep saying this, and we keep reminding you that all events must be
sample-accurate.  The control rate needs to be >= sample rate, or you need
to be able to re-align control rate to sample rate on any arbitrary
sample.

> 2. Events are different from samples and thus have to
> be treated and coded differently, which is more work.

Control events are *always* going to be different from audio samples.
We decided a long time ago that we are not building an all-normalized
all-numeric modular system when any output can plug to any input.  It's
more useful to have natural values and natural data types.  Control !=
audio.

> 3. Events are rendered at the destination, thus there
> may be several consumers duplicating work. Samples are
> rendered at the source and only once.

yes, and this is *correct*.  Events are rendered with exactly the level of
accuracty that a receiver can handle.

> 4. Events cannot represent real-time signals because
> you have to wait and see what is happening before a
> decision to send an event can be made.

This is not any different than sampled control streams.  Look.  Grab a
MIDI knob.  Turn it as fast as you can, and record the MIDI events.  Then
plot that against 44.1kHz sample points.  You are massively steppy.  Now
tell me that it makes sense to send all those redundant samples?

Let me explain more.  Let's assume you can spin a MIDI knob completely
from 0 to 127 in .25 seconds.  Let's assume 44.1kHz sample rate.  First
off, MIDI is event driven.  So you get 128 events in 11025 samples.  That
means that you have a step function where each step is ~86 samples wide.
Why do I need to send 86 samples of the same value, when I can just send 1
event?

Realtime inputs are inherently unpredictable, and the best you can do is
to provide the changes with as little latency as possible.

Whether you send a buffer full of control samples or you send a link-list
of events, you have exactly the same problems.  There is no forward
knowledge.  Well, actually, there is a bit - 1 buffer's worth.  So you can
peek ahead by however big your buffer is (and consequently, how bad the
latency is).

> 5. Events cannot represent arbitrary signals unless
> their frequency is high, which is undesirable because
> they are large (relatively speaking that is).

Event streams can be arbitrarily high frequency.  As we've shown, ramps
give you SUB-SAMPLE accuracy for pre-calculated events.  Yes, you pay more
for a very high rate event stream.  But with sample rates currently at
48 kHz or 96 kHz, I'm not worried about it.  I don't think that realtime
event streams will be coming in at 48000 events per second, and especially
not for any extended period of time.  And realtime events are what matter,
because who really cares if there is a bit more overhead during a
non-realtime operation.

So my point again:

1) You can have sample-rate events.
2) You won't see sample-rate events in realtime.
3) You might see sample-rate events in non-realtime, and nothing breaks.

> 6. Handling events is more complicated than samples
> which makes code more complex and less robust.
> Callbacks or interrupts or however you handle events
> are not good for high rates. Think about DMA and IRQs.

I'm a systems guy by design.  I *always* think about DMA and IRQs.  Now
I'm looking to you to explain how DMA and IRQs figure into this discussion
at all.  If you read the reqs, you'll see that event delivery happens
BEFORE a buffer is processed, and is not async.

> Basically you could see samples as events without the
> overhead of timestamps and clues. Or the other way

..and with the overhead of having to be at sample-rate.  Once more.  How
many knobs in a running graph?  I have synths with literally HUNDREDS of
knobs.  At any given time, maybe a dozen knobs are being automated, and
the automation is on the order of tens of changes per second.  Not tens of
thousands.

----------------------------------------------------------------------
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: