18 Jan
2008
18 Jan
'08
3:55 p.m.
Dave Robillard wrote:
On Fri, 2008-01-18 at 14:38 +0100, Pieter Palmers
wrote:
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.
It is also something that should be 'experimental' in the sense that it
would be there for the adventurous to fool around with and see what
happens, in order to gain experience for jack 2.0. Maybe that will help
to do it in a decent way from the start.
Greets,
Pieter
If someone comes up with a decent 'event
protocol' I'm volunteer to
implement it in jack, alongside the current jack-midi API (as an
experimental feature). From an implementations perspective it's a
no-brainer.
But can someone please tell me what to implement. And not in a vague
way. IMHO that's the real issue, and the 3 points you now mention are
only the first steps along that path. Please don't stop there. Take the
time to write a funded proposal that can be discussed, and then implemented.
I don't think bloating Jack up with umpteen different event protocols is
a very good idea when they can all be transported with virtually
identical APIs.
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)