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

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 04 Jan 2005 10:53:12 -0700

Crudesoft wrote:

I'm not sure that I fully grasp your objections to

events. As currently 


A resume of my previous arguments:

First: Knob-like controls belong to the same group as signal
generators. Button-like controls are events. I am
talking about knob-like controls. 

    Why is there any difference?


Second, my main objections to events:
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,
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.

I concede that a single event is going to be larger than a single sample, because the sample is part of a larger context where the sample rate is published elsewhere. But it is only larger than the sample by the size of a timestamp or duration. This is more than offset by the fact that the variable sample rate of events will almost always result is very significant thinning over a fixed sample rate.



2. Events are different from samples and thus have to
be treated and coded differently, which is more work.
You cannot use just any source as an event generator,
you need special event generators. If you want to mix
you are going to need convertors which complicate
matters even more.

I do not follow here. What is the difference between an event generator and a control rate sample generator? Sure the code is slightly different, but you still need some specialized code. You cannot use any source as a control signal generator either. The types have to match. And unless you are passing sample rate with every sample (or buffer), then the sample rates have to match too. Whereas with events, any like-typed event pins should be able to communicate without problems.



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

Once again, only true if the entire system has a fixed control rate. If not, then you have to resample at each destination. Not to mention that a destination may be recieving from more than one source and you will have to do mixing in either case.


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.


    ??????????

An event is a variable sample rate control stream. It is a super -class of fixed rate control streams. Anything that can be represented by a fixed rate control signal can be, by definition, represented by a variable rate stream that can achieve the same max sample rate. And vice-versa, which is one of the problems with a fixed rate approach - you must choose a high enough sample rate to achieve the precision that user's want, which to me says that it must always be audio rate.
I think that you are too tied up in a conception of an event as meaning a ramp. It doesn't. An event is a sample and a duration. For a live control, the value is held for the duration of the sample. Ramps are an optimization which gives a hint as to how to interpolate between two samples. The exact same optimization can be used in a fixed-rate system when the next point is known. When it is not known, both systems suffer from the same limitation: accurate interpoation cannot occur because the next value is unknown.


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

If you have an arbitrary signal that is changing every sample at audio rate, then yes, the event stream is larger (probably twice the size). However, you must admit that this is an edge case. Most of the time, the arbitrary signal is changing at something less than audio rate. A fixed-rate system would require audio rate bandwidth all the time, for all controls, which surely will result in much more overall bandwidth than variable rate controls for all but a few cases.


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.


    ???????????

Once again, I don't see where you going. Events would be delivered the exact same way that fixed rate controls would be delievered: a buffer of the next parameters passed for the process call.



Basically you could see samples as events without the
overhead of timestamps and clues. Or the other way
round: events are compressed samples. In the first
case you have to handle large sample buffers, in the
second case you have to compress. There are many ways
to gain something through compression, but you always
pay a price somewhere else, the gain is at transport
time, but you pay at zip and unzip time. You can only
have an overall positive gain if you use lossy
compression. Lossy compression imoses limits and
limits tend to be reasons to change later the way we
are doing something now.

Indeed, if you only allow for smooth linear
low-frequency control signals events may be the way to
go, but the price to pay is flexibility.

Well, once again, I believe that a variably-sampled stream is actually more flexible than a fixed rate stream. I think that there is a modest complexity increase for the reciever, but not nearly as large as you have made it out to be. And I think that variably-sampled streams will have a tremendously lower impact on performance than audio rate control streams, which I think is what is necessary to support your proposal.

--
Mike Berry
Adobe Systems

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

  1. Home
  2. gmpi
  3. Archive
  4. 01-2005