Jack MIDI, C++, API

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

Jack MIDI, C++, API

Dave Robillard
Hi All,

Not sure who exactly to send this to, but the list can't be a bad
choice:

The latest Jack MIDI patch doesn't work for C++ clients due to extern
"C" missing from midiport.h.  (No comment on the amount of frustration
this caused me).

In obviously related news, I've got working Jack MIDI support in Om now
- driving a modular synth with Lars' Dino pattern sequencer without an
Alsa sequencer in sight.

About the API, would it not be possible to just provide the client with
a simple array of jack_default_midi_event_t structs?  (ie exactly the
same as audio).  The necessity to use a function to get at every event
is a nuisance (at least to me), and adds quite a bit of performance
overhead just to get the buffer I want.  I assume this means the actual
events aren't stored consecutively somewhere? (Sorry, havn't looked into
the implementation much yet).  Doesn't seem very Jack-like.. but just a
thought.  If the events are stored in such a way, it would definitely be
nice for clients to have direct access to that buffer so they can
implement zero-copy processing of MIDI as well as audio.

Also, the function to query how large the MIDI buffer size is seems to
be missing (ie the MIDI analog to jack_get_buffer_size).  Clients need
to know how large to allocate MIDI buffers.

Those aside everything seems to be working perfectly.

Cheers,

-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: Jack MIDI, C++, API

Lars Luthman
On Sat, 2005-11-05 at 02:49 +1100, Dave Robillard wrote:
> The latest Jack MIDI patch doesn't work for C++ clients due to extern
> "C" missing from midiport.h.  (No comment on the amount of frustration
> this caused me).

I ran into this bug a while ago too, but worked around it rather than
reporting it (sorry about that). Today I tried to apply the MIDI patch
to current CVS, but one hunk was rejected. I fixed that and added extern
"C" wrappers to jack/midiport.h, attaching the patch (use -p1 when
applying it).

Is there any reason for not getting this into CVS? It would be very
convenient.

--
Lars Luthman
PGP key:     http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E

jack-midi-20051105.diff (44K) Download Attachment
signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Jack MIDI, C++, API

Jack O'Quin-2
Lars Luthman <[hidden email]> writes:

> Is there any reason for not getting this into CVS? It would be very
> convenient.

I have not been following JACK MIDI development closely.  My
impression was that this patch had not yet been pronounced ready for
mainline integration.

Forgive me if this impression is mistaken.  It is not based on any
personal experience.  I don't have a MIDI setup here to try it with.

Committing it to the CVS trunk is a very serious step with significant
binary compatibility implications for the future.  Are we nearly ready
to freeze these interfaces?

What is the consensus of those who have experience with JACK MIDI?
Should it go into the main CVS trunk, or a separate branch?

Is there some partial patch that would make it easier to add MIDI
features without permaturely committing us to one particular API?
--
  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: Jack MIDI, C++, API

Lars Luthman
On Sun, 2005-11-06 at 11:35 -0600, Jack O'Quin wrote:

> Lars Luthman <[hidden email]> writes:
>
> > Is there any reason for not getting this into CVS? It would be very
> > convenient.
>
> I have not been following JACK MIDI development closely.  My
> impression was that this patch had not yet been pronounced ready for
> mainline integration.
>
> Forgive me if this impression is mistaken.  It is not based on any
> personal experience.  I don't have a MIDI setup here to try it with.
>
> Committing it to the CVS trunk is a very serious step with significant
> binary compatibility implications for the future.  Are we nearly ready
> to freeze these interfaces?
OK, I didn't know you had such strict rules for CVS commits. I don't
really care about the API details, I just want something that works
without patching, as soon as possible. The current version works for me,
but I suspect others might have different opinions.

Any word from the author?


--
Lars Luthman
PGP key:     http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E

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

Re: Jack MIDI, C++, API

Dave Robillard
In reply to this post by Jack O'Quin-2
On Sun, 2005-06-11 at 11:35 -0600, Jack O'Quin wrote:

> Lars Luthman <[hidden email]> writes:
>
> > Is there any reason for not getting this into CVS? It would be very
> > convenient.
>
> I have not been following JACK MIDI development closely.  My
> impression was that this patch had not yet been pronounced ready for
> mainline integration.
>
> Forgive me if this impression is mistaken.  It is not based on any
> personal experience.  I don't have a MIDI setup here to try it with.
>
> Committing it to the CVS trunk is a very serious step with significant
> binary compatibility implications for the future.  Are we nearly ready
> to freeze these interfaces?
>
> What is the consensus of those who have experience with JACK MIDI?
> Should it go into the main CVS trunk, or a separate branch?

Gleaming over the header, two things that need doing:

- Remove running status rant and function it refers to, explicitly state
running status is not supported in Jack land.  Personally I don't think
this is even worthy of debate, running status has no benefit in this
idealised environment, and makes life of everyone (most importantly
client developers) more difficult.  If anything the checks (branching)
for whether running status is happening will make things _slower_.

- Hooks are _definitely_ needed to know the maximum MIDI buffer size.
One should be added, and comment in the patch about keeping this
information from clients removed.

- I'm still curious about my previous question about just getting a nice
flat buffer of jack_midi_event_t's, but having to use the function
isn't /so/ terrible - but it is slow.  I'll look into the rationale
behind this later.

These last two points boil down to "the current MIDI implementation is
more strange and different than audio than it probably needs to be" (but
in minor ways).

Fix the above, and it's ready for inclusion in mainline, IMO.  I'm
willing to fix these things and properly document the header (for the
documentation generation, that is), if everyone's in agreement.

> Is there some partial patch that would make it easier to add MIDI
> features without permaturely committing us to one particular API?

Just to clarify the scope of this for people who havn't looked at it
much, actual lines of code added/modified by the patch, not including
the example clients and build stuff is about 500 lines, 440 of which are
in seperate self-contained files (jack_midiport.[hc]).  That leaves a
whopping 80 lines of code that affect existing Jack code in any way.


-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: Jack MIDI, C++, API

Dave Robillard
In reply to this post by Lars Luthman
On Sun, 2005-06-11 at 19:42 +0100, Lars Luthman wrote:

> On Sun, 2005-11-06 at 11:35 -0600, Jack O'Quin wrote:
> > Lars Luthman <[hidden email]> writes:
> > Committing it to the CVS trunk is a very serious step with significant
> > binary compatibility implications for the future.  Are we nearly ready
> > to freeze these interfaces?
>
> OK, I didn't know you had such strict rules for CVS commits. I don't
> really care about the API details, I just want something that works
> without patching, as soon as possible. The current version works for me,
> but I suspect others might have different opinions.

At the risk of digression:

Changing the hardware port client names from driver specific idiocy
(alsa_pcm) to something consistent regardless of driver was also stomped
on by (fictitious) "compatibility" citation.

Just to put things in perspective. ;)

-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: Jack MIDI, C++, API

Jack O'Quin-2
In reply to this post by Lars Luthman

> On Sun, 2005-11-06 at 11:35 -0600, Jack O'Quin wrote:
>> Committing it to the CVS trunk is a very serious step with significant
>> binary compatibility implications for the future.  Are we nearly ready
>> to freeze these interfaces?

Lars Luthman <[hidden email]> writes:
> OK, I didn't know you had such strict rules for CVS commits. I don't
> really care about the API details, I just want something that works
> without patching, as soon as possible. The current version works for me,
> but I suspect others might have different opinions.

We do not have strict rules about it.  Perhaps we should, though the
informal advice in README.developers remains useful and relevant.

Because there are now so many JACK applications, we need to make a
strong commitment to maintaining binary compatibility.  Sometimes we
can't do it, but everyone should realize that each such failure
significantly costs our many downstream distributors and users.

A new API introduced into CVS is still subject to change until the
next JACK release (whenever that may be).  So, we should only add it
when we feel that it will be ready to freeze within that timeframe.

It has been a long time since the last JACK release, mainly because
JACK developers were busy working on other projects.  If we really are
ready now to begin an integration cycle for JACK MIDI, it might be
wise to put out an interim release first, giving us more time to shake
out the new API's afterwards.
--
  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: Jack MIDI, C++, API

Jack O'Quin-2
In reply to this post by Dave Robillard
Dave Robillard <[hidden email]> writes:

> At the risk of digression:
>
> Changing the hardware port client names from driver specific idiocy
> (alsa_pcm) to something consistent regardless of driver was also stomped
> on by (fictitious) "compatibility" citation.
>
> Just to put things in perspective. ;)

Good point.  

Compatibility is often more important than making things "better".
--
  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: Jack MIDI, C++, API

Lars Luthman
In reply to this post by Jack O'Quin-2
On Sun, 2005-11-06 at 19:13 -0600, Jack O'Quin wrote:

> > On Sun, 2005-11-06 at 11:35 -0600, Jack O'Quin wrote:
> >> Committing it to the CVS trunk is a very serious step with significant
> >> binary compatibility implications for the future.  Are we nearly ready
> >> to freeze these interfaces?
>
> Lars Luthman <[hidden email]> writes:
> > OK, I didn't know you had such strict rules for CVS commits. I don't
> > really care about the API details, I just want something that works
> > without patching, as soon as possible. The current version works for me,
> > but I suspect others might have different opinions.
>
> We do not have strict rules about it.  Perhaps we should, though the
> informal advice in README.developers remains useful and relevant.
> [...]
> A new API introduced into CVS is still subject to change until the
> next JACK release (whenever that may be).  So, we should only add it
> when we feel that it will be ready to freeze within that timeframe.
Ah, OK. I understood your reply as if you wanted binary compatibility
for every CVS commit, but when I read it again I see that that wasn't
necessarily what you meant.

--
Lars Luthman
PGP key:     http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E

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

Re: Jack MIDI, C++, API

Lars Luthman
In reply to this post by Dave Robillard
On Mon, 2005-11-07 at 11:37 +1100, Dave Robillard wrote:

> On Sun, 2005-06-11 at 11:35 -0600, Jack O'Quin wrote:
> > What is the consensus of those who have experience with JACK MIDI?
> > Should it go into the main CVS trunk, or a separate branch?
>
> Gleaming over the header, two things that need doing:
>
> - Remove running status rant and function it refers to, explicitly state
> running status is not supported in Jack land.  Personally I don't think
> this is even worthy of debate, running status has no benefit in this
> idealised environment, and makes life of everyone (most importantly
> client developers) more difficult.  If anything the checks (branching)
> for whether running status is happening will make things _slower_.
I agree with this. The potential to save space is much much smaller than
the potential to confuse the casual hacker and make client code more
complicated than needed.

One more tiny detail that would be useful would be to #include
jack/midiport.h in jack/jack.h. Or are there any technical reasons for
keeping it in a separate header?

--
Lars Luthman
PGP key:     http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E

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

Re: Jack MIDI, C++, API

deviant
addressing concerns in order:

the api must support running status. if it were ever to get written to a
port, the correct thing must be done. jack midi has to be as robust as
possible.

having said that, the i/o client will never generate running status for
the same reason you mentioned. running status is definitely not needed
inside jack.

i think it is nice to keep the midi stuff in a separate header. midi is
an extension to jack, and not every client will use it.

ian

On Mon, 2005-11-07 at 03:15 +0100, Lars Luthman wrote:

> On Mon, 2005-11-07 at 11:37 +1100, Dave Robillard wrote:
> > On Sun, 2005-06-11 at 11:35 -0600, Jack O'Quin wrote:
> > > What is the consensus of those who have experience with JACK MIDI?
> > > Should it go into the main CVS trunk, or a separate branch?
> >
> > Gleaming over the header, two things that need doing:
> >
> > - Remove running status rant and function it refers to, explicitly state
> > running status is not supported in Jack land.  Personally I don't think
> > this is even worthy of debate, running status has no benefit in this
> > idealised environment, and makes life of everyone (most importantly
> > client developers) more difficult.  If anything the checks (branching)
> > for whether running status is happening will make things _slower_.
>
> I agree with this. The potential to save space is much much smaller than
> the potential to confuse the casual hacker and make client code more
> complicated than needed.
>
> One more tiny detail that would be useful would be to #include
> jack/midiport.h in jack/jack.h. Or are there any technical reasons for
> keeping it in a separate header?




-------------------------------------------------------
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: Jack MIDI, C++, API

deviant
In reply to this post by Dave Robillard
thanks for pointing out the extern "C" omission. i have some updates to
the i/o client that will be sent out soon (probably tomorrow), and will
include it with them.

thanks too for including support for jack midi to om (and thanks to
everyone else who has started to use jack midi).

the reason there are function calls to access events is that events are
stored in the jack buffer as a byte offset from the beginning of the
buffer. this is a little hairy for individual clients to deal with -
imagine if the pointer was cast to the wrong type before adding the
offset - it is possible to end up at an entirely different location in
memory. it isn't possible to store a pointer to the memory location in
the event struct because shm does not guarantee that the same physical
location in memory will map to the same address for different processes
(i got bitten by that assumption early on in the development of jack
midi - sometimes it would map to the same address and sometimes it
wouldn't). however, when compared to the other processing going on in a
callback, a function call for retreving an event is not significant
(bearing in mind that even high midi data rates typically only leave you
with one or two events in a buffer at most).

also, it is possible to get the port buffer pointer and do a memcpy from
one buffer to another. this is actually done in the i/o client.

the query for obtaining the midi buffer size is indeed missing.
currently, the buffer size is the same as the audio buffer size. this
definitely needs to change. what really needs to happen is to have a
command line option when jack starts to set the midi buffer size and
have jack_buffer_size return the correct value regardless of what type
of data the port is registered to use. i haven't looked into this yet.

ian

On Sat, 2005-11-05 at 02:49 +1100, Dave Robillard wrote:

> Hi All,
>
> Not sure who exactly to send this to, but the list can't be a bad
> choice:
>
> The latest Jack MIDI patch doesn't work for C++ clients due to extern
> "C" missing from midiport.h.  (No comment on the amount of frustration
> this caused me).
>
> In obviously related news, I've got working Jack MIDI support in Om now
> - driving a modular synth with Lars' Dino pattern sequencer without an
> Alsa sequencer in sight.
>
> About the API, would it not be possible to just provide the client with
> a simple array of jack_default_midi_event_t structs?  (ie exactly the
> same as audio).  The necessity to use a function to get at every event
> is a nuisance (at least to me), and adds quite a bit of performance
> overhead just to get the buffer I want.  I assume this means the actual
> events aren't stored consecutively somewhere? (Sorry, havn't looked into
> the implementation much yet).  Doesn't seem very Jack-like.. but just a
> thought.  If the events are stored in such a way, it would definitely be
> nice for clients to have direct access to that buffer so they can
> implement zero-copy processing of MIDI as well as audio.
>
> Also, the function to query how large the MIDI buffer size is seems to
> be missing (ie the MIDI analog to jack_get_buffer_size).  Clients need
> to know how large to allocate MIDI buffers.
>
> Those aside everything seems to be working perfectly.
>
> Cheers,
>
> -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
>
--
ian esten <[hidden email]>



-------------------------------------------------------
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: Jack MIDI, C++, API

Jack O'Quin-2
In reply to this post by deviant
ian esten <[hidden email]> writes:

> i think it is nice to keep the midi stuff in a separate header. midi is
> an extension to jack, and not every client will use it.

Agreed.  There are too many symbols defined already in <jack/jack.h>.

Our current preference is to add new features in new headers, like
<jack/transport.h> or <jack/thread.h>.  Doing that makes the
documentation somewhat more modular, too.
--
  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: Jack MIDI, C++, API

Dave Robillard
In reply to this post by Jack O'Quin-2
On Sun, 2005-06-11 at 19:16 -0600, Jack O'Quin wrote:

> Dave Robillard <[hidden email]> writes:
>
> > At the risk of digression:
> >
> > Changing the hardware port client names from driver specific idiocy
> > (alsa_pcm) to something consistent regardless of driver was also stomped
> > on by (fictitious) "compatibility" citation.
> >
> > Just to put things in perspective. ;)
>
> Good point.  
>
> Compatibility is often more important than making things "better".

This is the design philosophy that made Windows ME such a fantastic
product...

Compatibility /is/ often more important than quality, but I strongly
suspect the competency of people who 'default' to choosing the former.
This is not one of the cases where that choice is valid:

Anything that relies on said names is completely broken /anyway/ and
isn't even compatible with the /same/ version of Jack run with a
different driver.  This is not a case of compatibility vs "better".
Compatibility itself is what needs to be "better" (the entire reason I
brought this up was because of session compatibility between machines)

Compatibility is a valid concern, but more often than not it's nothing
but a knee-jerk excuse borne of laziness - ie Jack MIDI doesn't even
break anything.  Why is this even being discussed right now?

Regardless, the consensus was reached that the client name can be
specified on the command line, making the point moot anyway.

</digression>

-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: Jack MIDI, C++, API

Dave Robillard
In reply to this post by deviant
On Sun, 2005-06-11 at 23:12 -0800, ian esten wrote:
> addressing concerns in order:
>
> the api must support running status. if it were ever to get written to a
> port, the correct thing must be done. jack midi has to be as robust as
> possible.

This translation is simple to do at the driver level.  It's a choice
between making every single Jack client unecessarily deal with useless
running status, or having it dealt with exactly once in the entire
system.  If there's a good argument for the former (that offsets the
extreme cost in complexity), I sure can't think of what it could be.

Rephrased, the Jack /system/ must support running status (from the
external perspective), but the client API definitely should not.

[snip]
> running status is definitely not needed
> inside jack.

exactly.

> i think it is nice to keep the midi stuff in a separate header. midi is
> an extension to jack, and not every client will use it.

agreed.

-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: Jack MIDI, C++, API

Dave Robillard
In reply to this post by deviant
On Sun, 2005-06-11 at 23:12 -0800, ian esten wrote:

> the reason there are function calls to access events is that events are
> stored in the jack buffer as a byte offset from the beginning of the
> buffer. this is a little hairy for individual clients to deal with -
> imagine if the pointer was cast to the wrong type before adding the
> offset - it is possible to end up at an entirely different location in
> memory. it isn't possible to store a pointer to the memory location in
> the event struct because shm does not guarantee that the same physical
> location in memory will map to the same address for different processes
> (i got bitten by that assumption early on in the development of jack
> midi - sometimes it would map to the same address and sometimes it
> wouldn't). however, when compared to the other processing going on in a
> callback, a function call for retreving an event is not significant
> (bearing in mind that even high midi data rates typically only leave you
> with one or two events in a buffer at most).

So you're saying it's actually impossible for it to be implemented as a
buffer of jack_midi_event_t's (even with a possible redesign)?  If so,
that's understandable, but I wanted to be sure, since from the client
perspective the 'consistent with audio' solution is much preferable (for
both asthetics/simplicity and performance).

Is it the event_t structs that are stored as you described, or the char*
member that contains the actual MIDI data?

> also, it is possible to get the port buffer pointer and do a memcpy from
> one buffer to another. this is actually done in the i/o client.

The problem with this is the client really has no idea what the buffer
is at all.  This is something that needs more explicit defining I think,
I found it very confusing to implement my client.  The buffer is this
void* magic-filled thing, and even now I still have no idea what it
actually consists of.

Speaking of which, that's another thing I forgot in my jack-midi-patch
TODO list - that void* pointer needs to be typedef'd to something.
jack_midi_port_buffer_t*?

> the query for obtaining the midi buffer size is indeed missing.
> currently, the buffer size is the same as the audio buffer size. this
> definitely needs to change. what really needs to happen is to have a
> command line option when jack starts to set the midi buffer size and
> have jack_buffer_size return the correct value regardless of what type
> of data the port is registered to use. i haven't looked into this yet.

Yeah, I have the same issue in Om right now - with the same temporary
solution (audio buffer size), and the same status (I'll get around to
it) :)

The command line parameter should probably be a scaling factor, # of
midi events per sample or similar.  That way you can change buffer size
without having to touch that parameter (this was discussed earlier
IIRC?)

-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: Jack MIDI, C++, API

Jack O'Quin-2
In reply to this post by Dave Robillard
Dave Robillard <[hidden email]> writes:

> Compatibility /is/ often more important than quality, but I strongly
> suspect the competency of people who 'default' to choosing the former.

Jackit-devel discussions provide a way for smart people to exchange
ideas.  They are generally polite and respectful.  None of us know
everything.  But, few of us have the strength of character to learn
anything useful from someone who attacks our competence.

> Why is this even being discussed right now?

Because you brought it up?
--
  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: Jack MIDI, C++, API

Lee Revell
In reply to this post by Dave Robillard
On Tue, 2005-11-08 at 03:18 +1100, Dave Robillard wrote:

> On Sun, 2005-06-11 at 19:16 -0600, Jack O'Quin wrote:
> > Dave Robillard <[hidden email]> writes:
> >
> > > At the risk of digression:
> > >
> > > Changing the hardware port client names from driver specific idiocy
> > > (alsa_pcm) to something consistent regardless of driver was also stomped
> > > on by (fictitious) "compatibility" citation.
> > >
> > > Just to put things in perspective. ;)
> >
> > Good point.  
> >
> > Compatibility is often more important than making things "better".
>
> This is the design philosophy that made Windows ME such a fantastic
> product...
>
> Compatibility /is/ often more important than quality, but I strongly
> suspect the competency of people who 'default' to choosing the former.
> This is not one of the cases where that choice is valid:

Haha, thank you.  I have been telling people "backwards compatibility is
the root of all evil" for years and they usually just look at me like
I'm crazy.

Lee



-------------------------------------------------------
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: Jack MIDI, C++, API

Lars Luthman
In reply to this post by deviant
While we're talking about MIDI, there is one thing that I think would be
useful to have for JACK MIDI input ports; metadata about what kind of
MIDI events the client expects and what they mean. Something like this
would be nice (very rough sketch):


struct midi_controller {
  unsigned char controller;
  const char name[32];
};

struct midi_program {
  unsigned char bank;
  unsigned char program;
  const char name[32];
};

struct midi_port_metadata {
  /* array of MIDI CC number -> name mappings */
  midi_controller* controller_list;
  /* array of MIDI program descriptions */
  midi_program* program_list;
};


If every JACK MIDI input port had a midi_port_metadata struct associated
with it, JACK MIDI sequencers could use this information to let the user
select programs and make automation curves without having to look up
which CC number controls the suboscillator amplitude or what the program
number is for the string instrument in the synth program, just like you
can do with hosted DSSI plugins for example.

I suppose this would be non-trivial to implement in JACK because it
would have to be stored in shared memory, which would mean that the
arrays either need to have a fixed length (which could waste a lot of
memory for clients that don't set this information), or would have to
use some method for resizing or reallocating shared memory segments.

Does this sound at all feasible? I haven't looked much at JACKs memory
management code.

--
Lars Luthman
PGP key:     http://www.d.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E

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

Re: Jack MIDI, C++, API

torbenh
In reply to this post by Dave Robillard
On Tue, Nov 08, 2005 at 03:38:11AM +1100, Dave Robillard wrote:
>
> > also, it is possible to get the port buffer pointer and do a memcpy from
> > one buffer to another. this is actually done in the i/o client.
>
> The problem with this is the client really has no idea what the buffer
> is at all.  This is something that needs more explicit defining I think,
> I found it very confusing to implement my client.  The buffer is this
> void* magic-filled thing, and even now I still have no idea what it
> actually consists of.

i think this has historic reasons. the first patch did actually have an
array of jack_midi_t.
paul was not happy with that because the same code will be used for
jack-osc in the future.
so having timestamped string events with subtypes such as midi or osc
is only several lines of code away.


for running status i still think it should be forbidden in the api.

think about merging two midi signals.
if you want direct access to the buffer the events have to be sorted.
or some decision has to be made.

if you dont know the inner structure of the port buffer this becomes an
implementation detail which does not endanger binary compatibility.

so this discussion can be delayed, and integration is not slowed down.

i think we can see from this thread that we are not really ready :(

i call you all to be pragmatic (because we all want jack-midi fast)

sorry my 2 hours at home before sleep are over and i have to go to bed.
another 10+hours of work await me tomorrow.



--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


-------------------------------------------------------
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
12