Jack internal MIDI vs ALSA seq sync

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
Hi!
I was wondering a lot of how to synchronize midi output (ALSA seq or
portmidi) with audio output (JACK), and was very happy to see that
you've now added midi support in jack and that it directly connects to
alsa seq ports as well as other jack midi clients.

I did some tests: I ran jack_midiseq connected to jack_midisine and also
to a hardware synthesizer (through alsa seq and a midi interface) with a
sine patch. I panned them left and right on my mixer and recorded it in
ardour. Looking close at the waveform revealed that the hardware synth
was about 750 frames (at 44100) before the jack_sine.
I then reconnected everything and did another test, now the jack_sine
client was about 150 to 200 frames before the hardware synth.
How come it was so different and in different orders? Could it depend on
what order I connected the jack_midiseq to jack_sine and the midi
interface? And is it possible to do anything about it?

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Dmitry Baikov
On 10/17/07, Jonatan Liljedahl <[hidden email]> wrote:
> ardour. Looking close at the waveform revealed that the hardware synth
> was about 750 frames (at 44100) before the jack_sine.
> I then reconnected everything and did another test, now the jack_sine
> client was about 150 to 200 frames before the hardware synth.
> How come it was so different and in different orders? Could it depend on
> what order I connected the jack_midiseq to jack_sine and the midi
> interface? And is it possible to do anything about it?

It needs an investigation.

Can you, please, also measure the jack-midi jitter?


Thank you,

Dmitry.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
Dmitry Baikov wrote:

> On 10/17/07, Jonatan Liljedahl <[hidden email]> wrote:
>> ardour. Looking close at the waveform revealed that the hardware synth
>> was about 750 frames (at 44100) before the jack_sine.
>> I then reconnected everything and did another test, now the jack_sine
>> client was about 150 to 200 frames before the hardware synth.
>> How come it was so different and in different orders? Could it depend on
>> what order I connected the jack_midiseq to jack_sine and the midi
>> interface? And is it possible to do anything about it?
>
> It needs an investigation.
>
> Can you, please, also measure the jack-midi jitter?

This is very inexact measurements, but I looked at the time between
onsets of the recorded sine notes in ardour: In the internal one
(jack_midiseq->jack_sine) the onsets didn't differ. In the external one
(jack_midiseq->alsa->midi_interface->synth) the span of differ was about
88 frames with the alsa seq driver and 54 with the raw driver.

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Dmitry Baikov
On 10/17/07, Jonatan Liljedahl <[hidden email]> wrote:
> > Can you, please, also measure the jack-midi jitter?
>
> This is very inexact measurements, but I looked at the time between
> onsets of the recorded sine notes in ardour: In the internal one
> (jack_midiseq->jack_sine) the onsets didn't differ. In the external one
> (jack_midiseq->alsa->midi_interface->synth) the span of differ was about
> 88 frames with the alsa seq driver and 54 with the raw driver.


Thanks a lot!

One more question: what kind of MIDI interface do you use?
Is it USB or some PCI card?


Dmitry.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
Dmitry Baikov wrote:
> On 10/17/07, Jonatan Liljedahl <[hidden email]> wrote:
>>> Can you, please, also measure the jack-midi jitter?
>> This is very inexact measurements, but I looked at the time between
>> onsets of the recorded sine notes in ardour: In the internal one
>> (jack_midiseq->jack_sine) the onsets didn't differ. In the external one
>> (jack_midiseq->alsa->midi_interface->synth) the span of differ was about
>> 88 frames with the alsa seq driver and 54 with the raw driver.
>
> Thanks a lot!

You're welcome.
Have I understood it right that with jack alsa seq you leave it up to
alsa to schedule the event, while in jack alsa raw you do it yourselves?

What is the reason you provide both seq and raw alsa midi backends?

I'll make some more tests to really see if the jack midi connection
order affects which receiver who lags behind, as I suspect, or if it
depends on some other factor..

> One more question: what kind of MIDI interface do you use?
> Is it USB or some PCI card?

It's USB: midiman MIDISPORT 2x2

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

lars.luthman (Bugzilla)
On Wed, 2007-10-17 at 13:58 +0200, Jonatan Liljedahl wrote:

> Dmitry Baikov wrote:
> > On 10/17/07, Jonatan Liljedahl <[hidden email]> wrote:
> >>> Can you, please, also measure the jack-midi jitter?
> >> This is very inexact measurements, but I looked at the time between
> >> onsets of the recorded sine notes in ardour: In the internal one
> >> (jack_midiseq->jack_sine) the onsets didn't differ. In the external one
> >> (jack_midiseq->alsa->midi_interface->synth) the span of differ was about
> >> 88 frames with the alsa seq driver and 54 with the raw driver.
> >
> > Thanks a lot!
>
> You're welcome.
> Have I understood it right that with jack alsa seq you leave it up to
> alsa to schedule the event, while in jack alsa raw you do it yourselves?
>
> What is the reason you provide both seq and raw alsa midi backends?
Without the seq backend it wouldn't be possible (or at least not very
convenient) to send MIDI between JACK MIDI programs and legacy ALSA
sequencer programs. On the other hand it introduces an extra layer that
is not necessary if you are _not_ using ALSA sequencer programs, thus
the raw MIDI backend.

Hopefully the need for the seq backend will go away in a few years.


--ll

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
Lars Luthman wrote:

> On Wed, 2007-10-17 at 13:58 +0200, Jonatan Liljedahl wrote:
>> Dmitry Baikov wrote:
>>> On 10/17/07, Jonatan Liljedahl <[hidden email]> wrote:
>>>>> Can you, please, also measure the jack-midi jitter?
>>>> This is very inexact measurements, but I looked at the time between
>>>> onsets of the recorded sine notes in ardour: In the internal one
>>>> (jack_midiseq->jack_sine) the onsets didn't differ. In the external one
>>>> (jack_midiseq->alsa->midi_interface->synth) the span of differ was about
>>>> 88 frames with the alsa seq driver and 54 with the raw driver.
>>> Thanks a lot!
>> You're welcome.
>> Have I understood it right that with jack alsa seq you leave it up to
>> alsa to schedule the event, while in jack alsa raw you do it yourselves?
>>
>> What is the reason you provide both seq and raw alsa midi backends?
>
> Without the seq backend it wouldn't be possible (or at least not very
> convenient) to send MIDI between JACK MIDI programs and legacy ALSA
> sequencer programs. On the other hand it introduces an extra layer that
> is not necessary if you are _not_ using ALSA sequencer programs, thus
> the raw MIDI backend.

Ah, I see. So only the hardware ports is available with the raw backend.
Couldn't both be used in a combined backend so that hardware ports is
accessed with the raw backend and alsa seq ports with the seq backend?

> Hopefully the need for the seq backend will go away in a few years.

When apps start to use JACK for internal MIDI communication?

By the way, how much is the jack midi specific to MIDI? I am thinking
that it's a very nice way to have synchronized communication of event
based data between jack clients, so it would be nice if it isn't so
specific for midi format data. I mean, it could just send an "event"
with a timestamp and data as a buffer of bytes and it could be up to
clients to interpret this data. But I guess this could lead to confusion
unless one standardize it somehow and put a 'type' field in each event
also... Anyhow, the biggest problem for me is that the midi standard
only has 7 bit data. Is it possible to send a controller change message
with 3 data bytes instead of 2: 0xBn <cc#> <msb> <lsb> and that clients
who reads the 3rd byte can use it and other clients would just ignore
it? (Or does jack midi automagically create two successive controller
change messages from this?) Or even just skip the midi format all
together and use something like <parm> <msb> <lsb> where all bytes are
8-bit, since I guess the events in jack midi isn't internally separated
by status bytes (8th bit set) but by some other means (or are they?).

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Paul Davis
On Wed, 2007-10-17 at 16:55 +0200, Jonatan Liljedahl wrote:

> By the way, how much is the jack midi specific to MIDI? I am thinking
> that it's a very nice way to have synchronized communication of event
> based data between jack clients, so it would be nice if it isn't so
> specific for midi format data. I mean, it could just send an "event"
> with a timestamp and data as a buffer of bytes and it could be up to
> clients to interpret this data.

and there is the exact problem. the reason why MIDI makes sense is
because it can be transmitted without any real ambiguity over what it
means (though admittedly, receivers can choose to use the data in ways
other than the way it may have been intended). there is no room for
misinterpretation: if the sender wants to deliver "note on #45, velocity
85", the receiver will know precisely what the sender intended.

contrast with OSC: a vastly more flexible format with many, many
benefits over MIDI. but consider just one simple question: how do you
tell an arbitrary set of OSC receivers to start making a noise that is
somehow related to middle C with a volume at about 85% of maximum?

since JACK is there to connect *applications* and not function as a
private bussing system within an application (even if some *cough*
ardour *cough* applications use it that way), it seems unclear what the
benefits are of providing an inter-app routing systems for messages that
have no semantics at all.

--p



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
In reply to this post by Jonatan Liljedahl
Jonatan Liljedahl wrote:
...
> I'll make some more tests to really see if the jack midi connection
> order affects which receiver who lags behind, as I suspect, or if it
> depends on some other factor..

I did some more tests and no, which one who lags does not seem to depend
on the connection order...

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

lars.luthman (Bugzilla)
In reply to this post by Jonatan Liljedahl
On Wed, 2007-10-17 at 16:55 +0200, Jonatan Liljedahl wrote:

> Lars Luthman wrote:
> > On Wed, 2007-10-17 at 13:58 +0200, Jonatan Liljedahl wrote:
> >> What is the reason you provide both seq and raw alsa midi backends?
> >
> > Without the seq backend it wouldn't be possible (or at least not very
> > convenient) to send MIDI between JACK MIDI programs and legacy ALSA
> > sequencer programs. On the other hand it introduces an extra layer that
> > is not necessary if you are _not_ using ALSA sequencer programs, thus
> > the raw MIDI backend.
>
> Ah, I see. So only the hardware ports is available with the raw backend.
> Couldn't both be used in a combined backend so that hardware ports is
> accessed with the raw backend and alsa seq ports with the seq backend?
Don't know. I remember having some problems with accessing the raw
devices when the sequencer kernel module was loaded, so I've just made
sure that the sequencer module is never loaded on my system and use JACK
MIDI exclusively.


> By the way, how much is the jack midi specific to MIDI? I am thinking
> that it's a very nice way to have synchronized communication of event
> based data between jack clients, so it would be nice if it isn't so
> specific for midi format data. I mean, it could just send an "event"
> with a timestamp and data as a buffer of bytes and it could be up to
> clients to interpret this data.

Something like JACK OSC would take care of this quite nicely - you'd
have timestamped events of arbitrary sizes and types that clients would
be free to interpret any way they wanted. Much of the MIDI code could
probably be reused, there is very little in there that is MIDI specific.


> Anyhow, the biggest problem for me is that the midi standard
> only has 7 bit data. Is it possible to send a controller change message
> with 3 data bytes instead of 2: 0xBn <cc#> <msb> <lsb> and that clients
> who reads the 3rd byte can use it and other clients would just ignore
> it? (Or does jack midi automagically create two successive controller
> change messages from this?)

I don't think JACK does anything at all with the written event bytes,
they are probably just passed on to the next client. A JACK MIDI client
that received "0xBn <cc#> <msb> <lsb>" would probably either ignore the
event altogether (since 4-byte events with a 0xB* status byte are not
valid MIDI) or ignore the LSB. In either case, you are not really
allowed to write invalid MIDI to the buffer - some future version of
JACK might decide to check all events and discard invalid ones.


--ll

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
In reply to this post by Paul Davis
Paul Davis wrote:

> On Wed, 2007-10-17 at 16:55 +0200, Jonatan Liljedahl wrote:
>
>> By the way, how much is the jack midi specific to MIDI? I am thinking
>> that it's a very nice way to have synchronized communication of event
>> based data between jack clients, so it would be nice if it isn't so
>> specific for midi format data. I mean, it could just send an "event"
>> with a timestamp and data as a buffer of bytes and it could be up to
>> clients to interpret this data.
>
> and there is the exact problem. the reason why MIDI makes sense is
> because it can be transmitted without any real ambiguity over what it
> means (though admittedly, receivers can choose to use the data in ways
> other than the way it may have been intended). there is no room for
> misinterpretation: if the sender wants to deliver "note on #45, velocity
> 85", the receiver will know precisely what the sender intended.

Yes, you're right.

> contrast with OSC: a vastly more flexible format with many, many
> benefits over MIDI. but consider just one simple question: how do you
> tell an arbitrary set of OSC receivers to start making a noise that is
> somehow related to middle C with a volume at about 85% of maximum?
>
> since JACK is there to connect *applications* and not function as a
> private bussing system within an application (even if some *cough*
> ardour *cough* applications use it that way), it seems unclear what the
> benefits are of providing an inter-app routing systems for messages that
> have no semantics at all.

In my case I'll have a set of custom apps for algorithmic control of
software and hardware synths, but I surely see the point in using a
standardized format. I guess I'll pack my controller values in multiple
midi cc messages until there is JACK OSC. :) At least the speed-limit of
hardware MIDI isn't there, so it shouldn't matter much how many events I
need to send for a simple 16 bit integer...

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Stéphane Letz

Le 17 oct. 07 à 18:03, Jonatan Liljedahl a écrit :

> Paul Davis wrote:
>> On Wed, 2007-10-17 at 16:55 +0200, Jonatan Liljedahl wrote:
>>
>>> By the way, how much is the jack midi specific to MIDI? I am  
>>> thinking
>>> that it's a very nice way to have synchronized communication of  
>>> event
>>> based data between jack clients, so it would be nice if it isn't so
>>> specific for midi format data. I mean, it could just send an "event"
>>> with a timestamp and data as a buffer of bytes and it could be up to
>>> clients to interpret this data.
>>
>> and there is the exact problem. the reason why MIDI makes sense is
>> because it can be transmitted without any real ambiguity over what it
>> means (though admittedly, receivers can choose to use the data in  
>> ways
>> other than the way it may have been intended). there is no room for
>> misinterpretation: if the sender wants to deliver "note on #45,  
>> velocity
>> 85", the receiver will know precisely what the sender intended.
>
> Yes, you're right.
>
>> contrast with OSC: a vastly more flexible format with many, many
>> benefits over MIDI. but consider just one simple question: how do you
>> tell an arbitrary set of OSC receivers to start making a noise  
>> that is
>> somehow related to middle C with a volume at about 85% of maximum?
>>
>> since JACK is there to connect *applications* and not function as a
>> private bussing system within an application (even if some *cough*
>> ardour *cough* applications use it that way), it seems unclear  
>> what the
>> benefits are of providing an inter-app routing systems for  
>> messages that
>> have no semantics at all.
>
> In my case I'll have a set of custom apps for algorithmic control of
> software and hardware synths, but I surely see the point in using a
> standardized format. I guess I'll pack my controller values in  
> multiple
> midi cc messages until there is JACK OSC. :) At least the speed-
> limit of
> hardware MIDI isn't there, so it shouldn't matter much how many  
> events I
> need to send for a simple 16 bit integer...

And small sysex could possibly be used for multi-bytes messages.

Stephane


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
In reply to this post by lars.luthman (Bugzilla)
Lars Luthman wrote:
...
>> Ah, I see. So only the hardware ports is available with the raw
>> backend. Couldn't both be used in a combined backend so that
>> hardware ports is accessed with the raw backend and alsa seq ports
>> with the seq backend?
>
> Don't know. I remember having some problems with accessing the raw
> devices when the sequencer kernel module was loaded, so I've just
> made sure that the sequencer module is never loaded on my system and
> use JACK MIDI exclusively.

I have the seq module loaded all the time and have not experienced any
problems with the raw backend.

> Something like JACK OSC would take care of this quite nicely - you'd
> have timestamped events of arbitrary sizes and types that clients
> would be free to interpret any way they wanted. Much of the MIDI code
> could probably be reused, there is very little in there that is MIDI
> specific.

That would be really nice! I know very little about OSC, but is there a
standard for embedding midi messages in OSC? If so then jack could still
handle midi ports but convert them to OSC ports virtually.

>> Anyhow, the biggest problem for me is that the midi standard only
>> has 7 bit data. Is it possible to send a controller change message
>> with 3 data bytes instead of 2: 0xBn <cc#> <msb> <lsb> and that
>> clients who reads the 3rd byte can use it and other clients would
>> just ignore it? (Or does jack midi automagically create two
>> successive controller change messages from this?)
>
> I don't think JACK does anything at all with the written event bytes,
>  they are probably just passed on to the next client. A JACK MIDI
> client that received "0xBn <cc#> <msb> <lsb>" would probably either
> ignore the event altogether (since 4-byte events with a 0xB* status
> byte are not valid MIDI) or ignore the LSB. In either case, you are
> not really allowed to write invalid MIDI to the buffer - some future
> version of JACK might decide to check all events and discard invalid
> ones.

I see, so I should avoid any non-midi tricks with the jack midi system.

But is there any plans for something like JACK OSC? It would be really
great to have audio-synched control between apps where one could send
for example floats as parameter control instead of something as strange
and old as 14-bit unsigned ints!

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

lars.luthman (Bugzilla)
On Wed, 2007-10-17 at 18:12 +0200, Jonatan Liljedahl wrote:

> Lars Luthman wrote:
> ...
> >> Ah, I see. So only the hardware ports is available with the raw
> >> backend. Couldn't both be used in a combined backend so that
> >> hardware ports is accessed with the raw backend and alsa seq ports
> >> with the seq backend?
> >
> > Don't know. I remember having some problems with accessing the raw
> > devices when the sequencer kernel module was loaded, so I've just
> > made sure that the sequencer module is never loaded on my system and
> > use JACK MIDI exclusively.
>
> I have the seq module loaded all the time and have not experienced any
> problems with the raw backend.
It may depend on hardware or drivers. Some devices have many subdevices
that can be opened independently, some don't. Then again, I may simply
have done something wrong.


> > Something like JACK OSC would take care of this quite nicely - you'd
> > have timestamped events of arbitrary sizes and types that clients
> > would be free to interpret any way they wanted. Much of the MIDI code
> > could probably be reused, there is very little in there that is MIDI
> > specific.
>
> That would be really nice! I know very little about OSC, but is there a
> standard for embedding midi messages in OSC? If so then jack could still
> handle midi ports but convert them to OSC ports virtually.

I don't know about MIDI in general, but MIDI events with 4 bytes (or
less + padding I suppose) has the type signature "m" in OSC:
http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html


> >> Anyhow, the biggest problem for me is that the midi standard only
> >> has 7 bit data. Is it possible to send a controller change message
> >> with 3 data bytes instead of 2: 0xBn <cc#> <msb> <lsb> and that
> >> clients who reads the 3rd byte can use it and other clients would
> >> just ignore it? (Or does jack midi automagically create two
> >> successive controller change messages from this?)
> >
> > I don't think JACK does anything at all with the written event bytes,
> >  they are probably just passed on to the next client. A JACK MIDI
> > client that received "0xBn <cc#> <msb> <lsb>" would probably either
> > ignore the event altogether (since 4-byte events with a 0xB* status
> > byte are not valid MIDI) or ignore the LSB. In either case, you are
> > not really allowed to write invalid MIDI to the buffer - some future
> > version of JACK might decide to check all events and discard invalid
> > ones.
>
> I see, so I should avoid any non-midi tricks with the jack midi system.
>
> But is there any plans for something like JACK OSC? It would be really
> great to have audio-synched control between apps where one could send
> for example floats as parameter control instead of something as strange
> and old as 14-bit unsigned ints!
As Stéphane said, there is already a method for sending
application-specific data in MIDI; SysEx messages. That would add 3
bytes of overhead (0xF0 0x7D <data> 0xF7) but since JACK already adds at
least 12 bytes of overhead per event (timestamp + data offset + data
size) it's not as big a deal as it sounds like.


--ll

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Jonatan Liljedahl
Lars Luthman wrote:
...

>> But is there any plans for something like JACK OSC? It would be really
>> great to have audio-synched control between apps where one could send
>> for example floats as parameter control instead of something as strange
>> and old as 14-bit unsigned ints!
>
> As Stéphane said, there is already a method for sending
> application-specific data in MIDI; SysEx messages. That would add 3
> bytes of overhead (0xF0 0x7D <data> 0xF7) but since JACK already adds at
> least 12 bytes of overhead per event (timestamp + data offset + data
> size) it's not as big a deal as it sounds like.

Yes, that's a good idea. And actually one might even skip the 0x7D as
long as you don't connect that port to some synth that could get
confused by it. But anyhow, I think jack OSC would be great sometime in
the future, since a lot of software (and some hardware) supports it.

--
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Paul Davis
On Wed, 2007-10-17 at 22:09 +0200, Jonatan Liljedahl wrote:

"think jack OSC would be great sometime in the future, since a lot of
software (and some hardware) supports it."

in which case, i repeat my question: how would you get all the software
(and the new hardware) that supports OSC to start making a noise based
on middle C with volume at about 85% of maximum?

i believe your answer (or rather, the lack thereof) will reveal why
"JACK OSC" isn't the panacea its something thought to be (by me also)

--p


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Florian Paul Schmidt-2
On Wednesday 17 October 2007, Paul Davis wrote:

> On Wed, 2007-10-17 at 22:09 +0200, Jonatan Liljedahl wrote:
>
> "think jack OSC would be great sometime in the future, since a lot of
> software (and some hardware) supports it."
>
> in which case, i repeat my question: how would you get all the software
> (and the new hardware) that supports OSC to start making a noise based
> on middle C with volume at about 85% of maximum?
>
> i believe your answer (or rather, the lack thereof) will reveal why
> "JACK OSC" isn't the panacea its something thought to be (by me also)

By having a convention. If you don't need the flexibility, use MIDI ;)

I actually fail to see why the above should be a reason against implementing
OSC..

Regards,
Flo



--
Palimm Palimm!
http://tapas.affenbande.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Dmitry Baikov
On 10/18/07, Florian Schmidt <[hidden email]> wrote:
> I actually fail to see why the above should be a reason against implementing
> OSC..

How would you like to see the OSC API in jack?
As another type of time-stamped raw buffers, as the MIDI API?
Or some kind of liblo API?


Dmitry.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Florian Paul Schmidt-2
On Thursday 18 October 2007, Dmitry Baikov wrote:
> On 10/18/07, Florian Schmidt <[hidden email]> wrote:
> > I actually fail to see why the above should be a reason against
> > implementing OSC..
>
> How would you like to see the OSC API in jack?
> As another type of time-stamped raw buffers, as the MIDI API?
> Or some kind of liblo API?

OSC already has a notion of timestamps.. jack would be just another means of
transport i guess.

Flo


--
Palimm Palimm!
http://tapas.affenbande.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack internal MIDI vs ALSA seq sync

Dmitry Baikov
On 10/18/07, Florian Schmidt <[hidden email]> wrote:
>> As another type of time-stamped raw buffers, as the MIDI API?
>> Or some kind of liblo API?
> OSC already has a notion of timestamps.. jack would be just another means of
> transport i guess.

OSC's timestamps are different. They represent absolute time.
Jack sees continuous time as discrete periods, so jack's timestamps
actually mean relative time inside current period.

IMHO, any OSC-message scheduling (processing of OSC-timestamps) should
be left for applications.
Then, JACK OSC API can look like MIDI API:

int jack_osc_event_write(portbuf, timestamp, data, size);
void* jack_osc_event_reserve(portbuf, timestamp, size);
int jack_osc_event_read(&event, portbuf);
...

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12