jack midi api

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

jack midi api

deviant
well, here it is folks. sorry for the long wait.

here are patches and files that add midi support to jack. they are
against 0.99, but will also apply against current cvs. to use it, apply
the patch (!), and put midiport.h into jack/jack/, midiport.c into
jack/libjack/, and midiseq.c and midisine.c into jack/example-clients/.

hopefully the api won't change too much, and how to code with it will be
pretty easy to work out. the example clients are really simple
implementations of a very basic sequencer and a very basic synth. in
case it's not immediately obvious, the data in the midi struct is just
raw midi bytes. although api's like alsa de-munge midi into something
slightly more palatable, raw midi is actually pretty easy to deal with
(see www.midi.org/about-midi/table1.shtml).

things i am considering adding:
- a jack_midi_get_next_event function. repeated calls to this would get
events one by one from the buffer in order, and would be slightly more
efficient.
- some helper functions or macros to provide information on the midi
data in a buffer (think jack_midi_is_that_data_a_note_on_question_mark()
sort of thing).

also included is an ebuild for gentoo. if you want to use that, create
the directory /usr/local/portage/media-sound/jack-audio-connection-kit/,
put the ebuild in there, and put all the other files in this message
in /usr/local/portage/media-sound/jack-audio-connection-kit/files/. you
will also need all the patch files
in /usr/portage/media-sound/jack-audio-connection-kit/files in there
too. then run 'ebuild jack-audio-connection-kit-0.99.0-r2.ebuild
digest', and you should be able to emerge it (as long as you have a
portage overlay directory specified). if you supply the jackmidi USE
flag, the package will be built with jack midi, otherwise it will not.

see the next email for the midi i/o client.

thats all for now,
ian


jackmidi_09dec04.patch (5K) Download Attachment
midiport.c (11K) Download Attachment
midiport.h (5K) Download Attachment
midiseq.c (3K) Download Attachment
midisine.c (3K) Download Attachment
jack-audio-connection-kit-0.99.0-r2.ebuild (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
On May 30, 2005, at 7:27 PM, ian esten wrote:
> well, here it is folks. sorry for the long wait.
>
> here are patches and files that add midi support to jack. they are
> against 0.99, but will also apply against current cvs. to use it, apply
> the patch (!), and put midiport.h into jack/jack/, midiport.c into
> jack/libjack/, and midiseq.c and midisine.c into jack/example-clients/.

Excellent!  I was wondering when we were going to get to see it.

I've attached a small patch to midiseq.c, so that it sets the
noteon/noteoff
velocity.  Also attached is a patch to example-clients/lsp.c (jack_lsp),
which adds a '-t' option causing it to display the port type (audio or
MIDI).

Can somebody remind me of the wisdom of passing raw MIDI?  Doesn't
that mean every single application in the chain has to parse it, in
contrast to e.g. the ALSA sequencer, where the sourcing application
or driver parses the raw MIDI, and everything downstream can count
on receiving whole, preparsed MIDI messages?

Lots of fun!  I'm hacking support into ghostess right now....

-Sean





jack_midiseq-patch (998 bytes) Download Attachment
jack_lsp-patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

sparked
On Tue, 31 May 2005 14:57:04 -0700
Sean Bolton <[hidden email]> wrote:

>
> Can somebody remind me of the wisdom of passing raw MIDI?  Doesn't
> that mean every single application in the chain has to parse it, in
> contrast to e.g. the ALSA sequencer, where the sourcing application
> or driver parses the raw MIDI, and everything downstream can count
> on receiving whole, preparsed MIDI messages?
>

I'll agree here. I have an app in mind that would be much quicker and
easier to code if I could leave out not only a midi parser, but
something to generate midi bytestream also.

--

"Not a bird not a leaf not a sound/And well after the close of time"
        --Front 242

Public Key: http://sparked.zadzmo.org/


attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Paul Davis
>> Can somebody remind me of the wisdom of passing raw MIDI?  Doesn't
>> that mean every single application in the chain has to parse it, in
>> contrast to e.g. the ALSA sequencer, where the sourcing application
>> or driver parses the raw MIDI, and everything downstream can count
>> on receiving whole, preparsed MIDI messages?
>>
>
>I'll agree here. I have an app in mind that would be much quicker and
>easier to code if I could leave out not only a midi parser, but
>something to generate midi bytestream also.

basically, the rationale is this: many people have existing code or
plan to re-use existing code that generates or consumes a raw MIDI
byte stream. in addition, many people have app- or library-specific
MIDI event structs. if we use event structs (ALSA seq or other) within
JACK's MIDI support, we force people to constantly translate between
data structures. by contrast, many apps already are required to
contain a MIDI parser, and can continue to use it. those that don't
can, in fact, use the ALSA seq API as a parser and get ALSA seq event
structs out of it if they wish.

for what its worth, ian and jesse and i debated this several times
during jack-midi's evolution, and in the end the blinding clarity of
my vision and sheer force of personality won out :)

--p


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

deviant
one thing i should have made clearer when i sent out the original email
is that jack midi events really are just one event (thanks to fernando
for pointing this out earlier today!). to clarify, a stream of midi data
as read from a soundcard may contain, for example, 4 bytes, 3 of which
are a note on message, and 1 of which is a system realtime message. that
makes parsing a midi stream harder. but, jackmidiio takes care of that
for you and splits the 4 bytes into 2 messages, one containing the
system realtime message, and the other containing the note on. so all
you need to 'parse' is the first byte of the message to know exactly
what it is. so, althuogh jack midi structs contain raw midi, it really
is pretty simple to deal with.
and paul's point here is excellent. although, i must admit, it wasn't
the blinding clarity of his vision or the sheer force of his personality
that convinced me, but rather the dazzling way in which the light
reflected off his teeth with an audible 'ping!' sound as he flashed his
ear to ear cheesy smile and gave a thumbs up, just like they do in the
washing up liquid adverts.
yours sincerely with tongue in cheek,
ian ;)


On Tue, 2005-05-31 at 19:22 -0400, Paul Davis wrote:

> >> Can somebody remind me of the wisdom of passing raw MIDI?  Doesn't
> >> that mean every single application in the chain has to parse it, in
> >> contrast to e.g. the ALSA sequencer, where the sourcing application
> >> or driver parses the raw MIDI, and everything downstream can count
> >> on receiving whole, preparsed MIDI messages?
> >>
> >
> >I'll agree here. I have an app in mind that would be much quicker and
> >easier to code if I could leave out not only a midi parser, but
> >something to generate midi bytestream also.
>
> basically, the rationale is this: many people have existing code or
> plan to re-use existing code that generates or consumes a raw MIDI
> byte stream. in addition, many people have app- or library-specific
> MIDI event structs. if we use event structs (ALSA seq or other) within
> JACK's MIDI support, we force people to constantly translate between
> data structures. by contrast, many apps already are required to
> contain a MIDI parser, and can continue to use it. those that don't
> can, in fact, use the ALSA seq API as a parser and get ALSA seq event
> structs out of it if they wish.
>
> for what its worth, ian and jesse and i debated this several times
> during jack-midi's evolution, and in the end the blinding clarity of
> my vision and sheer force of personality won out :)
>
> --p
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
On May 31, 2005, at 4:57 PM, ian esten wrote:

> one thing i should have made clearer when i sent out the original email
> is that jack midi events really are just one event (thanks to fernando
> for pointing this out earlier today!). to clarify, a stream of midi
> data
> as read from a soundcard may contain, for example, 4 bytes, 3 of which
> are a note on message, and 1 of which is a system realtime message.
> that
> makes parsing a midi stream harder. but, jackmidiio takes care of that
> for you and splits the 4 bytes into 2 messages, one containing the
> system realtime message, and the other containing the note on. so all
> you need to 'parse' is the first byte of the message to know exactly
> what it is. so, althuogh jack midi structs contain raw midi, it really
> is pretty simple to deal with.
Ah, a very important thing to know, indeed!  Knowing I can depend on
JACK to deliver whole single events, and not have to worry about
separating out system realtime messages or dealing with incomplete
events -- this makes a huge difference.  Given this, I agree with Paul's
arguments for not parsing the data further -- almost.  My reservation
has to do maintaining running status inside JACK, but that can wait
for later discussion, because the need to do so is related to efficient
buffer utilization, and:

I'm having trouble running into the limit of events that can be packed
into a port buffer.  For example, running jackd at '-p64', and playing a
SMF (*.mid) of Mozart's 40th into ghostess/hexter, I regularly get
dropped events because the MIDI port buffer fills.  At '-p64', that's
only 16 or 17 '3-byte' MIDI events per buffer!  Not good.

Running in to this limit also uncovered an off-by-one bug in
jack_midi_write_next_event().  I've attached a patch.

Has anyone put together any debugging tools yet, like a MIDI-to-text
dumper?

-Sean




midiport.c-patch (931 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
On Jun 1, 2005, at 1:27 PM, I wrote:
> I'm having trouble running into the limit of events that can be packed
> into a port buffer.  For example, running jackd at '-p64', and playing
> a
> SMF (*.mid) of Mozart's 40th into ghostess/hexter, I regularly get
> dropped events because the MIDI port buffer fills.  At '-p64', that's
> only 16 or 17 '3-byte' MIDI events per buffer!  Not good.

Okay, I'm learning.  If I set buffer_scale_factor to 8 for MIDI ports,
then in midiport.c jack_midi_write_next_event() hard-code a '* 8'
into the line in midiport.c just after the "/* bad: below line needs
to know about buffer scale factor */" comment, then I don't have
problems with MIDI port buffer overruns.

So how's the best way to fix this?  We could change the API so
jack_midi_write_next_event() takes a pointer to the port, from
which it can get the buffer_scale_factor.  Or we could add a field
to jack_midi_port_info_private_t in which to cache the
buffer_scale_factor.  Should jackd have a command line option
to set the MIDI port buffer_scale_factor?

-Sean



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

deviant
i think that the most likely cause of the problem you are observing is
that jackmidiio is running with normal privileges, and the input thread
is not getting woken frequently enough. so the first thing to do would
be to give the i/o threads elevated privileges.
i do eventually want to do something like your proposal, but to do it
right would require that jackmidiio have access to data that is private
to jackd. this is because every call that accessed the buffer would also
need to know the buffer scale factor. i think eventually something
that will have to be done, because i'm sure people will want to take
advantage of the extra midi bandwidth jack midi can offer clients. they
will most definitely have to be made aware that they should not expect
hardware i/o to offer as high bandwidth as it is possible to achieve
with jack clients.
thanks for the patches - i'm taking a look at them right now.
ian


On Thu, 2005-06-02 at 10:48 -0700, Sean Bolton wrote:

> On Jun 1, 2005, at 1:27 PM, I wrote:
> > I'm having trouble running into the limit of events that can be packed
> > into a port buffer.  For example, running jackd at '-p64', and playing
> > a
> > SMF (*.mid) of Mozart's 40th into ghostess/hexter, I regularly get
> > dropped events because the MIDI port buffer fills.  At '-p64', that's
> > only 16 or 17 '3-byte' MIDI events per buffer!  Not good.
>
> Okay, I'm learning.  If I set buffer_scale_factor to 8 for MIDI ports,
> then in midiport.c jack_midi_write_next_event() hard-code a '* 8'
> into the line in midiport.c just after the "/* bad: below line needs
> to know about buffer scale factor */" comment, then I don't have
> problems with MIDI port buffer overruns.
>
> So how's the best way to fix this?  We could change the API so
> jack_midi_write_next_event() takes a pointer to the port, from
> which it can get the buffer_scale_factor.  Or we could add a field
> to jack_midi_port_info_private_t in which to cache the
> buffer_scale_factor.  Should jackd have a command line option
> to set the MIDI port buffer_scale_factor?
>
> -Sean
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

deviant
In reply to this post by Sean Bolton
i have been thinking about running status a little this week. while it
isn't hard to deal with, it certainly is more inconvenient than messages
that do include the status byte. given that we have much higher
bandwidth with jack midi than we do with hardware midi, it might be a
nice convenience for jackmidiio to add in the status byte when running
status messages are received. the status byte can then be stripped when
data is written to outputs in order to make the most efficient use of
midi hardware bandwidth possible.
however, for this to be truly useful, all clients would have to generate
the status byte for every message. one of those policy things that might
be hard to enforce...
ian



On Wed, 2005-06-01 at 13:27 -0700, Sean Bolton wrote:
> Ah, a very important thing to know, indeed!  Knowing I can depend on
> JACK to deliver whole single events, and not have to worry about
> separating out system realtime messages or dealing with incomplete
> events -- this makes a huge difference.  Given this, I agree with Paul's
> arguments for not parsing the data further -- almost.  My reservation
> has to do maintaining running status inside JACK



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
In reply to this post by deviant
On Jun 5, 2005, at 11:20 AM, ian esten wrote:

> On Thu, 2005-06-02 at 10:48 -0700, Sean Bolton wrote:
>> On Jun 1, 2005, at 1:27 PM, I wrote:
>>> I'm having trouble running into the limit of events that can be
>>> packed
>>> into a port buffer.  For example, running jackd at '-p64', and
>>> playing
>>> a SMF (*.mid) of Mozart's 40th into ghostess/hexter, I regularly get
>>> dropped events because the MIDI port buffer fills.  At '-p64', that's
>>> only 16 or 17 '3-byte' MIDI events per buffer!  Not good.
>
> i think that the most likely cause of the problem you are observing is
> that jackmidiio is running with normal privileges, and the input thread
> is not getting woken frequently enough. so the first thing to do would
> be to give the i/o threads elevated privileges.

Nope, it's not a problem with the input thread -- a native JACK MIDI
*.mid player would run into the same limit.  It's not uncommon to have
sequences that send more than 16 events at once.

> i do eventually want to do something like your proposal [to make the
> buffer scale factor variable], but to do it
> right would require that jackmidiio have access to data that is private
> to jackd. this is because every call that accessed the buffer would
> also
> need to know the buffer scale factor. i think eventually something
> that will have to be done....

I think it's important enough that it should be fixed sooner rather that
later, and the fix is easy once the scale factor is accessible. Maybe
we need to add a jack_get_buffer_scale_factor(client, port) function?

-Sean



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Dave Robillard
On Mon, 2005-06-06 at 00:19 -0700, Sean Bolton wrote:

> On Jun 5, 2005, at 11:20 AM, ian esten wrote:
> > On Thu, 2005-06-02 at 10:48 -0700, Sean Bolton wrote:
> >> On Jun 1, 2005, at 1:27 PM, I wrote:
> >>> I'm having trouble running into the limit of events that can be
> >>> packed
> >>> into a port buffer.  For example, running jackd at '-p64', and
> >>> playing
> >>> a SMF (*.mid) of Mozart's 40th into ghostess/hexter, I regularly get
> >>> dropped events because the MIDI port buffer fills.  At '-p64', that's
> >>> only 16 or 17 '3-byte' MIDI events per buffer!  Not good.
> >
> > i think that the most likely cause of the problem you are observing is
> > that jackmidiio is running with normal privileges, and the input thread
> > is not getting woken frequently enough. so the first thing to do would
> > be to give the i/o threads elevated privileges.
>
> Nope, it's not a problem with the input thread -- a native JACK MIDI
> *.mid player would run into the same limit.  It's not uncommon to have
> sequences that send more than 16 events at once.
>
> > i do eventually want to do something like your proposal [to make the
> > buffer scale factor variable], but to do it
> > right would require that jackmidiio have access to data that is private
> > to jackd. this is because every call that accessed the buffer would
> > also
> > need to know the buffer scale factor. i think eventually something
> > that will have to be done....
>
> I think it's important enough that it should be fixed sooner rather that
> later, and the fix is easy once the scale factor is accessible. Maybe
> we need to add a jack_get_buffer_scale_factor(client, port) function?

On a somewhat related note, is there performance issues with having
monstrous buffer sizes?  (other than the memory usage, obviously)  In
addition to MIDI, I'm thinking of OSC here, which can be implemented in
basically the same way, but will need buffer sizes waay larger to really
be useful.

Frankly I'm not a huge fan of the fixed buffer size for these sorts of
thing in the first place, but I guess fitting something better into
Jack's framework is far from simple. :/

-DR-



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Paul Davis
>On a somewhat related note, is there performance issues with having
>monstrous buffer sizes?  (other than the memory usage, obviously)  In
>addition to MIDI, I'm thinking of OSC here, which can be implemented in
>basically the same way, but will need buffer sizes waay larger to really
>be useful.
>
>Frankly I'm not a huge fan of the fixed buffer size for these sorts of
>thing in the first place, but I guess fitting something better into
>Jack's framework is far from simple. :/

putting it mildly, yes.

all port buffers live in shared memory. since this is allocated by
jackd, and comes in large chunks, and has to be accessed via offsets
from the address where it gets mapped into each client, doing dynamic
buffer sizing is, well, not impossible but, as i might have said some
years back, bloody hard.

--p


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Alfons Adriaensen
On Mon, Jun 06, 2005 at 07:50:36AM -0400, Paul Davis wrote:

> >On a somewhat related note, is there performance issues with having
> >monstrous buffer sizes?  (other than the memory usage, obviously)  In
> >addition to MIDI, I'm thinking of OSC here, which can be implemented in
> >basically the same way, but will need buffer sizes waay larger to really
> >be useful.
> >
> >Frankly I'm not a huge fan of the fixed buffer size for these sorts of
> >thing in the first place, but I guess fitting something better into
> >Jack's framework is far from simple. :/
>
> putting it mildly, yes.
>
> all port buffers live in shared memory. since this is allocated by
> jackd, and comes in large chunks, and has to be accessed via offsets
> from the address where it gets mapped into each client, doing dynamic
> buffer sizing is, well, not impossible but, as i might have said some
> years back, bloody hard.

The alternative is a linked list of fixed-sized buffers.

For midi there should not be a problem AFAICS. Using a midi buffer of the
same size as the audio one, at 44.1 Khz you get the equivalent bandwidth
of 7 physical midi connections, and space for at least one midi event per
frame (excluding sysex). Should be enough in most cases. Even if, for a
particular cycle, you would have more midi than can be fitted into the
buffer, the pragmatic solution of delaying some of it to the next cycle
still gives you way better latency than a physical midi link.


--
FA


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Martin Bayer
In reply to this post by Dave Robillard
> On a somewhat related note, is there performance issues with having
> monstrous buffer sizes?  (other than the memory usage, obviously)  In
> addition to MIDI, I'm thinking of OSC here, which can be implemented in
> basically the same way, but will need buffer sizes waay larger to really
> be useful.

Are there any other problems that discourage really big port buffers?

The background of this question is the possibility of a port type for
video. The size of a single raw video frame goes up to multiple megabytes.

Martin



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Alfons Adriaensen
In reply to this post by Alfons Adriaensen
On Mon, Jun 06, 2005 at 02:09:41PM +0200, Alfons Adriaensen wrote:

> Using a midi buffer of the
> same size as the audio one, at 44.1 Khz you get the equivalent bandwidth
> of 7 physical midi connections,

Correction: 56 physical midi connections (there are 8 bits in a byte :-)

--
FA


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
In reply to this post by Alfons Adriaensen
On Jun 6, 2005, at 5:09 AM, Alfons Adriaensen wrote:

> For midi there should not be a problem AFAICS. Using a midi buffer of
> the
> same size as the audio one, at 44.1 Khz you get the equivalent
> bandwidth
> of [56] physical midi connections, and space for at least one midi
> event per
> frame (excluding sysex). Should be enough in most cases. Even if, for a
> particular cycle, you would have more midi than can be fitted into the
> buffer, the pragmatic solution of delaying some of it to the next cycle
> still gives you way better latency than a physical midi link.

It's more like the equivalent bandwidth of 10 physical midi connections,
because of the metadata JACK includes.

However, comparing JACK's MIDI bandwidth to physical MIDI bandwidth
is missing the point.  The really wonderful thing about MIDI inside the
computer is that it has freed us, to a large extent, from the 'smear'
associated with MIDI's slow physical baud rate.  IIRC, much of
the excitement about a JACK MIDI transport was its potential to deliver
MIDI with near sample-accurate timing in relationship to the audio
stream.  We shouldn't settle for an implementation that retains the
smear,
even if  only one tenth as bad, when a better solution is fairly easy.

Based on a quick look through some of my MIDI source material, ignoring
sys-ex messages, and considering the current implementation, I'd say
that
a practical minimum MIDI buffer size needed to avoid all but the most
occasional 'smear' would be 256 bytes for sources involving up to about
8-voice polyphony, 512 bytes for 16-voice polyphony, and so on.

Note that these sizes are independent of the audio buffer size.  I'd
think
video would be a similar situation.  Previously I'd suggested making
the buffer_scale_factor for MIDI ports configurable from the jackd
command line, but that ties the MIDI buffer size to the audio buffer
size.
Now I'm thinking a way to independently set MIDI (and eventually video
or OSC) buffer sizes would be desirable.

-Sean



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Dave Robillard
On Mon, 2005-06-06 at 09:25 -0700, Sean Bolton wrote:

> On Jun 6, 2005, at 5:09 AM, Alfons Adriaensen wrote:
> > For midi there should not be a problem AFAICS. Using a midi buffer of
> > the
> > same size as the audio one, at 44.1 Khz you get the equivalent
> > bandwidth
> > of [56] physical midi connections, and space for at least one midi
> > event per
> > frame (excluding sysex). Should be enough in most cases. Even if, for a
> > particular cycle, you would have more midi than can be fitted into the
> > buffer, the pragmatic solution of delaying some of it to the next cycle
> > still gives you way better latency than a physical midi link.
>
> It's more like the equivalent bandwidth of 10 physical midi connections,
> because of the metadata JACK includes.
>
> However, comparing JACK's MIDI bandwidth to physical MIDI bandwidth
> is missing the point.  The really wonderful thing about MIDI inside the
> computer is that it has freed us, to a large extent, from the 'smear'
> associated with MIDI's slow physical baud rate.  IIRC, much of
> the excitement about a JACK MIDI transport was its potential to deliver
> MIDI with near sample-accurate timing in relationship to the audio
> stream.  We shouldn't settle for an implementation that retains the
> smear,
> even if  only one tenth as bad, when a better solution is fairly easy.
>
> Based on a quick look through some of my MIDI source material, ignoring
> sys-ex messages, and considering the current implementation, I'd say
> that
> a practical minimum MIDI buffer size needed to avoid all but the most
> occasional 'smear' would be 256 bytes for sources involving up to about
> 8-voice polyphony, 512 bytes for 16-voice polyphony, and so on.
>
> Note that these sizes are independent of the audio buffer size.  I'd
> think
> video would be a similar situation.

I don't see your reasoning.

If the buffer size represents the passing of 4 times more time (ie 64 ->
256), surely you'd want to be able to handle 4 times as much MIDI?

If you (hypothetically) had a buffer size representing 5 seconds, you'll
need more MIDI data per cycle than if your buffer size represented 10ms.

-DR-



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
On Jun 6, 2005, at 5:52 PM, Dave Robillard wrote:

> On Mon, 2005-06-06 at 09:25 -0700, Sean Bolton wrote:
>> Based on a quick look through some of my MIDI source material,
>> ignoring
>> sys-ex messages, and considering the current implementation, I'd say
>> that
>> a practical minimum MIDI buffer size needed to avoid all but the most
>> occasional 'smear' would be 256 bytes for sources involving up to
>> about
>> 8-voice polyphony, 512 bytes for 16-voice polyphony, and so on.
>>
>> Note that these sizes are independent of the audio buffer size.  I'd
>> think
>> video would be a similar situation.
>
> I don't see your reasoning.
>
> If the buffer size represents the passing of 4 times more time (ie 64
> ->
> 256), surely you'd want to be able to handle 4 times as much MIDI?

Sorry, I didn't express myself very well.

MIDI events tend to be clustered in bursts, often with a bunch of
events clustered around something you might call a 'beat', then
relatively few events happening until the next 'beat'.  With short
period lengths, the MIDI buffer size requirements are more
dependent on the number of voices than on the temporal length
of the buffer.

Of course, if we're talking large period sizes, say the difference
between .25 seconds and 1 second, you're absolutely right --
you would want to be able to handle 4 times as much MIDI, but
then, the buffer sizes would be way above the practical minimums
I was suggesting above.

Is that more clear now?

-Sean



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Alfons Adriaensen
In reply to this post by Sean Bolton
On Mon, Jun 06, 2005 at 09:25:38AM -0700, Sean Bolton wrote:

> It's more like the equivalent bandwidth of 10 physical midi connections,
> because of the metadata JACK includes.

More than 400% overhead ? That's a lot.
 
> Based on a quick look through some of my MIDI source material, ignoring
> sys-ex messages, and considering the current implementation, I'd say
> that
> a practical minimum MIDI buffer size needed to avoid all but the most
> occasional 'smear' would be 256 bytes for sources involving up to about
> 8-voice polyphony, 512 bytes for 16-voice polyphony, and so on.
>
> Note that these sizes are independent of the audio buffer size.

If you assume events are clustered around 'beats', and the period is
shorter than a beat, yes. But I can easily imagine some types of music
where that would not be the case.

--
FA


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack midi api

Sean Bolton
On Jun 7, 2005, at 4:24 AM, Alfons Adriaensen wrote:
> On Mon, Jun 06, 2005 at 09:25:38AM -0700, Sean Bolton wrote:
>> It's more like the equivalent bandwidth of 10 physical midi
>> connections,
>> because of the metadata JACK includes.
>
> More than 400% overhead ? That's a lot.

Yeah, 12 bytes per event, plus buffer header.

>> Note that these sizes are independent of the audio buffer size.
>
> If you assume events are clustered around 'beats', and the period is
> shorter than a beat, yes. But I can easily imagine some types of music
> where that would not be the case.

I _knew_ one of you would point that out!  Thanks, Fons. <grin>

-Sean



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12