Another angle on JACK MIDI

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Another angle on JACK MIDI

Alex Austin
Do we want to implement MIDI in JACK, or do we want to create a Jack
Music Description and Control Protocol? (JMDCP)

 Bringing together several other discussions, I have asked this board
about recommended ways to implement control signals, and even
suggested some.

References:
   http://sourceforge.net/mailarchive/forum.php?thread_id=7944326&forum_id=3040
   http://sourceforge.net/mailarchive/forum.php?thread_id=8264183&forum_id=3040

As far as I see it, if we can develop a robust control architecture,
It's up to the midi driver to convert midi events into jmdcp events. I
have, as can be seen in the links above, previously suggested various
ideas concerning the passing of control data between applications and
plugins within JACK. I have read some gmpi info, but haven't found any
mailing list archives to look at, and find the cached page at
archive.org to be of marginal helpfulness.

I don't think that integrating MIDI directly into JACK as-is is a good
idea. I think that a new music/control architecture would probably be
the best bet since we have sample-accurate timings. Once we get our
architecture working correctly and well-designed, then we can see
about getting MIDI integrated into it at the same level that JACK
connects to ALSA.

What do other people think?


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Fons Adriaensen
On Mon, Nov 07, 2005 at 03:53:26PM -0600, Alex Austin wrote:
 
> What do other people think?

What I'd prefer to see happen with MIDI inside JACK is this:
Midi data is translated to OSC format and presented as such
to all interested clients. So future clients would need only
one interface, and for existing ones a (simple) library could
be made that reads the OSC and presents it as Midi. Given the
format below, that would not be any more complex than the
current interface.

The most obvious encoding would be something like:

/midiblob ,ib <offset_in_samples_from_ start_of_cycle> <raw_binary_midi_data>

Events having the same timestamp could be combined, e.g.:

/midiblob ,ibbb <offset> <data> <data> <data>

Just my 0.02 Euro, of course.

--
FA








-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Jack O'Quin-2
fons adriaensen <[hidden email]> writes:

> What I'd prefer to see happen with MIDI inside JACK is this:
> Midi data is translated to OSC format and presented as such
> to all interested clients. So future clients would need only
> one interface, and for existing ones a (simple) library could
> be made that reads the OSC and presents it as Midi. Given the
> format below, that would not be any more complex than the
> current interface.
>
> The most obvious encoding would be something like:
>
> /midiblob ,ib <offset_in_samples_from_ start_of_cycle> <raw_binary_midi_data>
>
> Events having the same timestamp could be combined, e.g.:
>
> /midiblob ,ibbb <offset> <data> <data> <data>
>
> Just my 0.02 Euro, of course.

There was a rather complete mapping of MIDI to OSC proposed on the
GMPI list a while back.  It handled all messages but SYSEX (IIRC), and
in a rather readable format.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
In reply to this post by Alex Austin
On Mon, 2005-07-11 at 15:53 -0600, Alex Austin wrote:
> Do we want to implement MIDI in JACK, or do we want to create a Jack
> Music Description and Control Protocol? (JMDCP)

We want to implement MIDI in JACK.  Next question? :)

OSC will follow, which can handle whatever 'control protocol' ambitions
anyone has (I certainly do).

If you want to start a 5 year long discussion about implementing The
Ultimate Control Protocol, joing the GMPI list.  We want to get this
done already.

OSC cures all anyway, and it's widely supported and understood.  The
acronym you just mad up on the spot is not. :)

-DR-




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
In reply to this post by Fons Adriaensen
On Mon, 2005-07-11 at 23:19 +0100, fons adriaensen wrote:

> On Mon, Nov 07, 2005 at 03:53:26PM -0600, Alex Austin wrote:
>  
> > What do other people think?
>
> What I'd prefer to see happen with MIDI inside JACK is this:
> Midi data is translated to OSC format and presented as such
> to all interested clients. So future clients would need only
> one interface, and for existing ones a (simple) library could
> be made that reads the OSC and presents it as Midi. Given the
> format below, that would not be any more complex than the
> current interface.

I'm possibly the biggest OSC bigot in linux audio land, and even I see
this isn't going to fly.  People want MIDI, like it or not.  Providing
OSC is a very high priority personal goal of mine, but cramming it down
people's throats isn't going to go over well.

> The most obvious encoding would be something like:
>
> /midiblob ,ib <offset_in_samples_from_ start_of_cycle> <raw_binary_midi_data>
>
> Events having the same timestamp could be combined, e.g.:
>
> /midiblob ,ibbb <offset> <data> <data> <data>

Some kind of pseudo-standard OSC note spec is definitely needed, but is
outside the scope of this discussion.

Dave Griffith's OSC sequencing stuff at pawfal.org already can't drive
Om without hacks, so one of us is bound to fix this problem, more likely
sooner than later. :)

(Including the timestamp inside the OSC message itself, and including a
bunch of raw MIDI data instead of a proper sane note command is almost
certainly not the right way to go about it though)

I definitely appreciate the sentiment though.  OSC for life, death to
MIDI and everything else the 80's spawned :)

-DR-



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alex Austin
In reply to this post by Dave Robillard
On 11/7/05, Dave Robillard <[hidden email]> wrote:

> On Mon, 2005-07-11 at 15:53 -0600, Alex Austin wrote:
> > Do we want to implement MIDI in JACK, or do we want to create a Jack
> > Music Description and Control Protocol? (JMDCP)
>
> We want to implement MIDI in JACK.  Next question? :)
>
> OSC will follow, which can handle whatever 'control protocol' ambitions
> anyone has (I certainly do).
>
> If you want to start a 5 year long discussion about implementing The
> Ultimate Control Protocol, joing the GMPI list.  We want to get this
> done already.
>
> OSC cures all anyway, and it's widely supported and understood.  The
> acronym you just mad up on the spot is not. :)
>
> -DR-

The only problems I have with MIDI or OSC descend from timestamp
formats. How do you convert between a midi timestamp, an OSC
timestamp, and whatever parts of the JACK transport timestamp the
timebase master decides to provide? I don't know how OSC describes
timestamps, but I can't find any info on it either. As for problems
descended from this one, many people have talked about ramped control
data. I see no reason to limit ramping to control data. Why not note
values? Wouldn't it be easier to allow everything to be ramped?

Anyway, that's why I think JACK needs its own control protocol that
can be integrated with either OSC or MIDI through a plugin of some
kind. Lots of applications use the JACK transport control. By
including MIDI or OSC, that makes for another timebase/timestamp to
deal with. Also, I may be wrong, but AFAICT OSC extends beyond what
MIDI/my-theoretical-jmdcp would do, so an OSC plugin would pass
relevent messages to the various parts of the JACK subsystem.

- Alex


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
On Mon, 2005-07-11 at 22:04 -0600, Alex Austin wrote:

> On 11/7/05, Dave Robillard <[hidden email]> wrote:
> > On Mon, 2005-07-11 at 15:53 -0600, Alex Austin wrote:
> > > Do we want to implement MIDI in JACK, or do we want to create a Jack
> > > Music Description and Control Protocol? (JMDCP)
> >
> > We want to implement MIDI in JACK.  Next question? :)
> >
> > OSC will follow, which can handle whatever 'control protocol' ambitions
> > anyone has (I certainly do).
> >
> > If you want to start a 5 year long discussion about implementing The
> > Ultimate Control Protocol, joing the GMPI list.  We want to get this
> > done already.
> >
> > OSC cures all anyway, and it's widely supported and understood.  The
> > acronym you just mad up on the spot is not. :)
> >
> > -DR-
>
> The only problems I have with MIDI or OSC descend from timestamp
> formats. How do you convert between a midi timestamp, an OSC
> timestamp, and whatever parts of the JACK transport timestamp the
> timebase master decides to provide? I don't know how OSC describes
> timestamps, but I can't find any info on it either.

Timestamp = integer offset into current buffer.  Anything else is
inappropriate and overly complex for this.

> As for problems
> descended from this one, many people have talked about ramped control
> data. I see no reason to limit ramping to control data. Why not note
> values? Wouldn't it be easier to allow everything to be ramped?

Nothing is stopping you from sending ramped control values via OSC.  You
can send whatever you want via OSC - that's largely the point.  You're
inventing limits where there are none.

> By
> including MIDI or OSC, that makes for another timebase/timestamp to
> deal with.

False.  "There is but one timestamp, and it's name is sample offset into
current buffer" - Jack 3:14

The current plan is elegant, simple, extensible, and efficient (blah
blah etc).  You really seem to want to bolt on a whole whack of
complexity and force it on everyone, but you don't actually have a valid
reason to do so.

If you do want to invent a new control protocol, by all means go ahead.
It could be sent over Jack in the exact same way MIDI (and eventually
OSC) can.  This is nothing but a simple transport mechanism for
"events".  What those events actually are is basically irrelevant.

I don't mean to sound rude, but have you actually looked at the patch at
all?  Do you understand what it does?

-DR-



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alfons Adriaensen
On Tue, Nov 08, 2005 at 04:34:22PM +1100, Dave Robillard wrote:

> Timestamp = integer offset into current buffer.  Anything else is
> inappropriate and overly complex for this.

I fully agree that timestamps should be relative to the current
audio buffer start, and in samples. If we don't this for e.g.
OSC, little is gained as each client will have to implement its
own mapping OSC-time --> sample index, and that's not trivial at
all.

But please, please make this a _float_ rather than an int. And
please don't say that complicates things for the user - if he
wants an int that is just a cast or a rint() away.

In signal processing terms, there is *nothing* special about
integer multiples of the sample period. Events could very well
start at a fraction of a sample. For things like granular synthesis
being able to specify this is just *essential*.

--
FA




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alfons Adriaensen
In reply to this post by Dave Robillard
On Tue, Nov 08, 2005 at 12:57:26PM +1100, Dave Robillard wrote:

> On Mon, 2005-07-11 at 23:19 +0100, fons adriaensen wrote:
>
> > What I'd prefer to see happen with MIDI inside JACK is this:
> > Midi data is translated to OSC format and presented as such
> > to all interested clients. So future clients would need only
> > one interface, and for existing ones a (simple) library could
> > be made that reads the OSC and presents it as Midi. Given the
> > format below, that would not be any more complex than the
> > current interface.
>
> I'm possibly the biggest OSC bigot in linux audio land, and even I see
> this isn't going to fly.  People want MIDI, like it or not.  Providing
> OSC is a very high priority personal goal of mine, but cramming it down
> people's throats isn't going to go over well.

Please re-read. I don't want to cramm OSC down peoples' throats.
In current JACK MIDI proposal, there already is an API that hides
the representation in the buffer, and provides to user with MIDI
events + timestamps. The only thing I propose is to use an OSC
compatible format for this representation. The API would remain
what it is.

The trivial encapsulation I propose is not meant to replace other
MIDI-over-OSC formats, it just serves as means to locally transfer
raw IDI data over what is in fact an OSC interface. MIDI users will
not see the difference.

But clients that want to read it as OSC could do so, and do their
own interpretation. They could also use the same buffers to send
or receive any OSC command of course, so we have the basis of JACK-OSC
and JACK-MIDI in one go.

> (Including the timestamp inside the OSC message itself, and including a
> bunch of raw MIDI data instead of a proper sane note command is almost
> certainly not the right way to go about it though)

A fully agree that the timestamp should be separate, including
it in the OSC was a bad idea.

As to the proper note command, that's something that can be added
later, the only purpose ATM is encapsulate the MIDI data, so we
don't need separate MIDI and OSC systems within JACK.

In practice, my proposal amounts to this: keep the current
representation but just add /midiblob or something similar
in front of each event, and strip it at the other side.
This turns the current buffer format into legal OSC. Again it's
not meant to be the ultimate OSC command format, just an OSC-
compatible encapsulation to avoid having two interfaces.


--
FA


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
In reply to this post by Alfons Adriaensen
On Tue, 2005-08-11 at 11:17 +0100, Alfons Adriaensen wrote:

> On Tue, Nov 08, 2005 at 04:34:22PM +1100, Dave Robillard wrote:
>
> > Timestamp = integer offset into current buffer.  Anything else is
> > inappropriate and overly complex for this.
>
> I fully agree that timestamps should be relative to the current
> audio buffer start, and in samples. If we don't this for e.g.
> OSC, little is gained as each client will have to implement its
> own mapping OSC-time --> sample index, and that's not trivial at
> all.
>
> But please, please make this a _float_ rather than an int. And
> please don't say that complicates things for the user - if he
> wants an int that is just a cast or a rint() away.
>
> In signal processing terms, there is *nothing* special about
> integer multiples of the sample period. Events could very well
> start at a fraction of a sample. For things like granular synthesis
> being able to specify this is just *essential*.

Currently it's a jack_nframes_t, which is an unsigned 32bit int.

This is the first time I've heard anyone mention floating point
timestamps (though I could have missed it).

At first thought it seems like a good idea, but I've never even
considered it before.  Anyone else have an opinion on this?

-DR-



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
In reply to this post by Alfons Adriaensen
On Tue, 2005-08-11 at 11:36 +0100, Alfons Adriaensen wrote:

> On Tue, Nov 08, 2005 at 12:57:26PM +1100, Dave Robillard wrote:
>
> > On Mon, 2005-07-11 at 23:19 +0100, fons adriaensen wrote:
> >
> > > What I'd prefer to see happen with MIDI inside JACK is this:
> > > Midi data is translated to OSC format and presented as such
> > > to all interested clients. So future clients would need only
> > > one interface, and for existing ones a (simple) library could
> > > be made that reads the OSC and presents it as Midi. Given the
> > > format below, that would not be any more complex than the
> > > current interface.
> >
> > I'm possibly the biggest OSC bigot in linux audio land, and even I see
> > this isn't going to fly.  People want MIDI, like it or not.  Providing
> > OSC is a very high priority personal goal of mine, but cramming it down
> > people's throats isn't going to go over well.
>
> Please re-read. I don't want to cramm OSC down peoples' throats.
> In current JACK MIDI proposal, there already is an API that hides
> the representation in the buffer, and provides to user with MIDI
> events + timestamps. The only thing I propose is to use an OSC
> compatible format for this representation. The API would remain
> what it is.
>
> The trivial encapsulation I propose is not meant to replace other
> MIDI-over-OSC formats, it just serves as means to locally transfer
> raw IDI data over what is in fact an OSC interface. MIDI users will
> not see the difference.
>
> But clients that want to read it as OSC could do so, and do their
> own interpretation. They could also use the same buffers to send
> or receive any OSC command of course, so we have the basis of JACK-OSC
> and JACK-MIDI in one go.

For one thing, what is the point?  Having two different types of buffers
doesn't make anything more complicated, but some crazy MIDI-in-OSC
scheme does, and it adds overhead to boot.

I don't want to go into it, but there are many, many more complicated
issues involved with putting OSC through Jack than you imply here.  We
should tackle one thing at a time, and let that sleeping dog lay for now
(trust me).

I am 100% fully in support of making the event system protocol agnostic
(as I'm sure most everyone else is).  Forcing MIDI to be wrapped in OSC
is just silly (and ugly) when both can just go over the same transport.
Forcing the buffer to be anything at all is a bad move.  People could
even send video over it, conceptually, or god knows what else.

What /should/ be done IMO is change the "midi" in the API to "event",
and add a type field to jack_midi_event_t (which would presumably be
called jack_event_t).  Then we can have normal MIDI without this
MIDI-in-OSC craziness, and in the future can add whatever event types
anyone can think of (including, of course, OSC).  You're happy, I'm
happy, Alex is happy, people who just want their damn MIDI already are
happy, everyone wins - and all we have to do is s/midi/event/ and add
one field to a struct.

Can anyone think of something in the future for which (time_stamp,
type_tag, size, data) wouldn't be sufficient?  It seems like the Right
Thing(TM) to me, and doesn't even really break the current API.

(For the record, it would be very nice if this discussion could sway
towards the floating point time stamp issue, and the type field thing I
mentioned above.  Let the GMPI people battle endlessley over the Grand
Unified Solution)

-DR-  (Unashamed fanboy of the KISS principle)



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alfons Adriaensen
On Tue, Nov 08, 2005 at 11:30:45PM +1100, Dave Robillard wrote:

> What /should/ be done IMO is change the "midi" in the API to "event",
> and add a type field to jack_midi_event_t (which would presumably be
> called jack_event_t).  Then we can have normal MIDI without this
> MIDI-in-OSC craziness, and in the future can add whatever event types
> anyone can think of (including, of course, OSC).  You're happy, I'm
> happy, Alex is happy, people who just want their damn MIDI already are
> happy, everyone wins - and all we have to do is s/midi/event/ and add
> one field to a struct.

You can encode *any* type of event into OSC, that's the whole point of it.
There is no need for anything 'above' it. And since (in a bright future)
that will be the format used to interconnect things over the network and
in general everywhere, why invent a new language just for use inside JACK ?

 
--
FA



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
On Tue, 2005-08-11 at 13:44 +0100, Alfons Adriaensen wrote:

> On Tue, Nov 08, 2005 at 11:30:45PM +1100, Dave Robillard wrote:
>
> > What /should/ be done IMO is change the "midi" in the API to "event",
> > and add a type field to jack_midi_event_t (which would presumably be
> > called jack_event_t).  Then we can have normal MIDI without this
> > MIDI-in-OSC craziness, and in the future can add whatever event types
> > anyone can think of (including, of course, OSC).  You're happy, I'm
> > happy, Alex is happy, people who just want their damn MIDI already are
> > happy, everyone wins - and all we have to do is s/midi/event/ and add
> > one field to a struct.
>
> You can encode *any* type of event into OSC, that's the whole point of it.
> There is no need for anything 'above' it. And since (in a bright future)
> that will be the format used to interconnect things over the network and
> in general everywhere, why invent a new language just for use inside JACK ?

You can.  You can also encode *any* type of event as a series of english
strings describing hexadecimal digits in full word form.

The overriding question is:  why?

And this new language you speak of, what is it exactly?  I think you're
inventing problems that don't exist.

-DR-



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alfons Adriaensen
On Wed, Nov 09, 2005 at 12:01:00AM +1100, Dave Robillard wrote:

> > You can encode *any* type of event into OSC, that's the whole point of it.
> > There is no need for anything 'above' it. And since (in a bright future)
> > that will be the format used to interconnect things over the network and
> > in general everywhere, why invent a new language just for use inside JACK ?
>
> You can.  You can also encode *any* type of event as a series of english
> strings describing hexadecimal digits in full word form.
>
> The overriding question is:  why?

We want OSC, right ? We don't want arbitrary english text, right ?
Once you have OSC, you don't need anything else because everything
else can be expressed in it. It's trivially simple to encapsulate
raw MIDI in OSC. So let's skip MIDI or whatever other fixed event
set as an internal format, and base everything on OSC. Why is this
so difficult to understand ?

To support clients that want MIDI, it is again trivially simple to
convert the encapsulated MIDI back to the required API, because it
contains a unmodified version of the original data. The only things
you need to add to the existing API code are

- test for the OSC command that represents embedded MIDI
- either skip the entire command or,
- skip over the fixed length command name and format string,

and then interpret the raw MIDI data as you would have done before.

> And this new language you speak of, what is it exactly?  I think you're
> inventing problems that don't exist.

By 'new language' I mean whatever fixed event set you want to use as
the API, referring to your s/midi/event/ proposal. If you start defining
specific events, you will end up with something having the same limits as
midi. As long as this API is used only to get at MIDI events (as is the
case now), that's no problem of course. But a (future) general interface
should definitely *not* have a fixed event set. Only the syntax should
be fixed, and for that I propose OSC, for evident reasons.

There is no fixed event set in OSC, it's up the clients to agree on
something. So the basic JACK services should IMHO be completely neutral,
and only enforce the OSC syntax and nothing else.


--
FA



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
On Tue, 2005-08-11 at 15:02 +0100, Alfons Adriaensen wrote:

> On Wed, Nov 09, 2005 at 12:01:00AM +1100, Dave Robillard wrote:
>
> > > You can encode *any* type of event into OSC, that's the whole point of it.
> > > There is no need for anything 'above' it. And since (in a bright future)
> > > that will be the format used to interconnect things over the network and
> > > in general everywhere, why invent a new language just for use inside JACK ?
> >
> > You can.  You can also encode *any* type of event as a series of english
> > strings describing hexadecimal digits in full word form.
> >
> > The overriding question is:  why?
>
> We want OSC, right ? We don't want arbitrary english text, right ?
> Once you have OSC, you don't need anything else because everything
> else can be expressed in it. It's trivially simple to encapsulate
> raw MIDI in OSC. So let's skip MIDI or whatever other fixed event
> set as an internal format, and base everything on OSC. Why is this
> so difficult to understand ?

The data field of the event struct is a simple array of bytes.  This
array of bytes can hold anything.  Including OSC.  Why is this so
difficult to understand?

> By 'new language' I mean whatever fixed event set you want to use as
> the API, referring to your s/midi/event/ proposal. If you start defining
> specific events, you will end up with something having the same limits as
> midi. As long as this API is used only to get at MIDI events (as is the
> case now), that's no problem of course. But a (future) general interface
> should definitely *not* have a fixed event set. Only the syntax should
> be fixed, and for that I propose OSC, for evident reasons.

So in order to have a protocol agnostic event system, we force a single
protocol to be used for everything?  Riiiight.

Anyway, I made no mention of any "fixed event set" or "specific events"
whatsoever.  Completely the opposite actually - but you did.  I think
you may have mixed myself and you up?

-DR-




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Steve Harris-2
In reply to this post by Alfons Adriaensen
On Tue, Nov 08, 2005 at 03:02:04 +0100, Alfons Adriaensen wrote:

> On Wed, Nov 09, 2005 at 12:01:00AM +1100, Dave Robillard wrote:
>
> > > You can encode *any* type of event into OSC, that's the whole point of it.
> > > There is no need for anything 'above' it. And since (in a bright future)
> > > that will be the format used to interconnect things over the network and
> > > in general everywhere, why invent a new language just for use inside JACK ?
> >
> > You can.  You can also encode *any* type of event as a series of english
> > strings describing hexadecimal digits in full word form.
> >
> > The overriding question is:  why?
>
> We want OSC, right ? We don't want arbitrary english text, right ?
> Once you have OSC, you don't need anything else because everything
> else can be expressed in it. It's trivially simple to encapsulate
> raw MIDI in OSC. So let's skip MIDI or whatever other fixed event
> set as an internal format, and base everything on OSC. Why is this
> so difficult to understand ?

So.... I dont want to agrue against supporting MIDI-over-OSC, but there
are some subtle differences between the way OSC works nad the way MIDI
works that makes it not so trivial.

If you are only using the OSC data encapulation scheme, then there are no
problems, but OSC is also a protocol, as is MIDI. The OSC protocol is
packetised, and has an explicit diestination, whereas MIDI is a serial
stream with an implicit destination. This can make joining up applications
that expect vanilla OSC messages in a way that makes sense to MIDI apps
somewhat tricky.

Personally I see little value in just using the OSC binary packet format
without any interoperability with UDP-based OSC apps. YMMV.

- Steve


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alex Austin
In reply to this post by Dave Robillard
On 11/7/05, Dave Robillard <[hidden email]> wrote:

> On Mon, 2005-07-11 at 22:04 -0600, Alex Austin wrote:
> > On 11/7/05, Dave Robillard <[hidden email]> wrote:
> > > On Mon, 2005-07-11 at 15:53 -0600, Alex Austin wrote:
> > > > Do we want to implement MIDI in JACK, or do we want to create a Jack
> > > > Music Description and Control Protocol? (JMDCP)
> > >
> > > We want to implement MIDI in JACK.  Next question? :)
> > >
> > > OSC will follow, which can handle whatever 'control protocol' ambitions
> > > anyone has (I certainly do).
> > >
> > > If you want to start a 5 year long discussion about implementing The
> > > Ultimate Control Protocol, joing the GMPI list.  We want to get this
> > > done already.
> > >
> > > OSC cures all anyway, and it's widely supported and understood.  The
> > > acronym you just mad up on the spot is not. :)
> > >
> > > -DR-
> >
> > The only problems I have with MIDI or OSC descend from timestamp
> > formats. How do you convert between a midi timestamp, an OSC
> > timestamp, and whatever parts of the JACK transport timestamp the
> > timebase master decides to provide? I don't know how OSC describes
> > timestamps, but I can't find any info on it either.
>
> Timestamp = integer offset into current buffer.  Anything else is
> inappropriate and overly complex for this.
>
> > As for problems
> > descended from this one, many people have talked about ramped control
> > data. I see no reason to limit ramping to control data. Why not note
> > values? Wouldn't it be easier to allow everything to be ramped?
>
> Nothing is stopping you from sending ramped control values via OSC.  You
> can send whatever you want via OSC - that's largely the point.  You're
> inventing limits where there are none.
>
> > By
> > including MIDI or OSC, that makes for another timebase/timestamp to
> > deal with.
>
> False.  "There is but one timestamp, and it's name is sample offset into
> current buffer" - Jack 3:14

I wish:
   http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html#timetags
   http://www.borg.com/~jglatt/tech/mtc.htm

Personally, I would prefer to use some space in the "padding" member
of jack_position_t to add a "sample offset into current buffer" value,
then use jack_position_t. As can be seen, though, OSC and MIDI already
have their own timestamp/timetag formats. I don't know if they're
required, but it appears that they're probably pretty widely
supported. At least MIDI Time Code is.

> The current plan is elegant, simple, extensible, and efficient (blah
> blah etc).  You really seem to want to bolt on a whole whack of
> complexity and force it on everyone, but you don't actually have a valid
> reason to do so.
>
> If you do want to invent a new control protocol, by all means go ahead.
> It could be sent over Jack in the exact same way MIDI (and eventually
> OSC) can.  This is nothing but a simple transport mechanism for
> "events".  What those events actually are is basically irrelevant.
>
> I don't mean to sound rude, but have you actually looked at the patch at
> all?  Do you understand what it does?
>
> -DR-
>
>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

stefan kersten
In reply to this post by Dave Robillard
On Tue, Nov 08, 2005 at 10:56:05PM +1100, Dave Robillard wrote:

> > In signal processing terms, there is *nothing* special about
> > integer multiples of the sample period. Events could very well
> > start at a fraction of a sample. For things like granular synthesis
> > being able to specify this is just *essential*.
>
> Currently it's a jack_nframes_t, which is an unsigned 32bit int.
>
> This is the first time I've heard anyone mention floating point
> timestamps (though I could have missed it).
>
> At first thought it seems like a good idea, but I've never even
> considered it before.  Anyone else have an opinion on this?

i strongly second fons' suggestion. it's possible to
schedule bundles with subsample accuracy in OSC, i don't see
why this feature should be dumped in a jack implementation
...

<sk>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Alfons Adriaensen
In reply to this post by Dave Robillard
On Wed, Nov 09, 2005 at 01:12:51AM +1100, Dave Robillard wrote:

> So in order to have a protocol agnostic event system, we force a single
> protocol to be used for everything?  Riiiight.

Indeed. And you would add one more on top (*), but it adds nothing
new. Whatever it allows you to express could as well be represented
as an OSC blob.

The bottom line is: there *has* to be single top level protocol,
otherwise your data can't be interpreted at all. And my point is:
OSC is flexible enough to be that top level protocol, and since
we want OSC anyway, there is no need to put anything on top of it.


(*) If whatever you propose can be parsed into individual events,
then it constitutes a 'single protocol' as well, in no way more
neutral than OSC.


--
FA








-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another angle on JACK MIDI

Dave Robillard
In reply to this post by Steve Harris-2
On Tue, 2005-08-11 at 14:14 +0000, Steve Harris wrote:

> On Tue, Nov 08, 2005 at 03:02:04 +0100, Alfons Adriaensen wrote:
> > On Wed, Nov 09, 2005 at 12:01:00AM +1100, Dave Robillard wrote:
> >
> > > > You can encode *any* type of event into OSC, that's the whole point of it.
> > > > There is no need for anything 'above' it. And since (in a bright future)
> > > > that will be the format used to interconnect things over the network and
> > > > in general everywhere, why invent a new language just for use inside JACK ?
> > >
> > > You can.  You can also encode *any* type of event as a series of english
> > > strings describing hexadecimal digits in full word form.
> > >
> > > The overriding question is:  why?
> >
> > We want OSC, right ? We don't want arbitrary english text, right ?
> > Once you have OSC, you don't need anything else because everything
> > else can be expressed in it. It's trivially simple to encapsulate
> > raw MIDI in OSC. So let's skip MIDI or whatever other fixed event
> > set as an internal format, and base everything on OSC. Why is this
> > so difficult to understand ?
>
> So.... I dont want to agrue against supporting MIDI-over-OSC, but there
> are some subtle differences between the way OSC works nad the way MIDI
> works that makes it not so trivial.
>
> If you are only using the OSC data encapulation scheme, then there are no
> problems, but OSC is also a protocol, as is MIDI. The OSC protocol is
> packetised, and has an explicit diestination, whereas MIDI is a serial
> stream with an implicit destination. This can make joining up applications
> that expect vanilla OSC messages in a way that makes sense to MIDI apps
> somewhat tricky.
>
> Personally I see little value in just using the OSC binary packet format
> without any interoperability with UDP-based OSC apps. YMMV.

This is the can of worms I was desperately hoping to avoid openings, for
the time being. :)

-DR-




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
123