[gmpi] Re: Topic 3: Cross Platform

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 6 Mar 2003 23:38:52 +0100

On Thursday 06 March 2003 17.58, Silver Blade wrote:
[...MIDI style byte streams...]
> I think this idea is OK, although MIDI has many limitations, such
> as the inability to read a controller's value (set only, not get.)

I don't think the point was MIDI, but rather using byte streams. What 
goes on between Xlib and the X server on Un*x systems would be 
another example of such a protocol.


> However, using "opcodes" is a good idea, IMO. The parameter types
> depend on the type of opcode specified. Similar to how VST works
> between plugin and host.

But VST passes these through two function calls, which can only take 
one "event" at a time, and no timestamps... I can see the similarity, 
but it's pretty far fetched, IMHO.


> For example, the opcode for "sendnote" could have parameters for
> timestamp, note, and velocity.

This sounds exactly like the XAP event system. "Actions" are passed 
around as linked lists of structs. The main advantages with this over 
a byte stream protocol that I can think of right now:

        * No actual parsing is needed. Just get an event struct
          and switch() on the opcode.

        * No need for circular buffers, which would have to
          support dynamic reallocation to avoid overflows) or
          true dynamic memory management. (All event structs
          are of the same size.)


> I'm not sure how exactly everything could be encompassed into
> opcodes and parameters (operands?), but it's certainly a good idea
> for networking purposes (the opcode and parameters are effectively
> a packet of data).

This doesn't really work with timestamped real time events. 
"Something" has to adjust timestamps, "fix" late events over soft RT 
connections and stuff like that, so you'll most probably have to 
parse and recode all data at least once on the way. Turning XAP style 
events into a byte stream and then back into events on the other side 
would be easier and faster, and it's also easier and faster to deal 
with inside single threaded nets - which is probably what we'll be 
dealing with 99% of the time.


> Who knows - maybe a dedicated external device or
> expansion card could process the data!

Sure. I've been thinking about that kind of stuff for ages. :-)

Beowulf clusters running RTLinux or RTAI would be a rather interesting 
variation on this theme, I think. Ethernet NICs have practically zero 
latency on the hardware level, and since we're dealing with ordered 
graphs, the latencies caused by the time it takes to transmit blocks 
become pretty much irrelevant. This makes it very different from 
typical cluster based supercomputing; simpler and more effective.


> And if the amount of data
> uses little bandwidth, it could also be sent through a MIDI cable
> as SysEx data perhaps?

Doesn't take much to max out a MIDI wire with 32 bit FP control 
events... High speed serial lines, USB or 1394 might be interesting, 
though.


//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://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---


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