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

  • From: Crudesoft <crudesoft@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 4 Jan 2005 09:23:10 -0800 (PST)

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

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.

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.

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

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.

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

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.

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.

Crudesoft


                
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com 

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