18 Jan
2008
18 Jan
'08
7:58 p.m.
On Fri, 2008-01-18 at 20:54 +0100, Pieter Palmers wrote:
Dave Robillard wrote:
It is indeed a no-brainer: no downside, and a heck of a lot of wins. I
was very disappointed when it was rejected the first time around :/
Nitpick:
I realized an oops on my part here. (Unlike LV2) Jack /events/
themselves don't need a type field, since a port would presumably only
transport events of one type. So all events can use the same
(conceptual) "struct" and API, the /port/ type would say what the type
of the events actually are.
Cheers,
-DR-
An event in Jack is just a certain length of
bytes with a timestamp
anyway, you /could/ theoretically just cram OSC messages into a Jack
MIDI port if the receiving app was expecting it... there's just no type
field in events, and the names of the functions in the API imply it's
MIDI specific (which it isn't, really)
The similarity is why I indicate it at as a no-brainer btw. As fair as I
can see it comes down to introducing a type field in the event structure
and generalizing the current _midi_ functions to _event_ ones. And
providing _midi_ wrappers. That on itself would allow people to
experiment with whatever event they prefer, without interfering with
normal jack behavior.