Jack MIDI API, passsing ports vs passing buffers

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

Jack MIDI API, passsing ports vs passing buffers

Dave Robillard
This is mostly for Ian:

Looking at the MIDI API strictly from the client perspective, is there a
good reason why the buffer is being exposed to the user at all?  I see
the comment in the patch about this, and I think I agree that exposing
the buffer to the user is a bad idea.  If the buffer is not to be
accessed directly, it probably shouldn't be handed to clients at all.

It would be cleaner looking to pass the port itself, and not the buffer
returned by jack_port_get_buffer, and it would avoid the previously
mentioned "what the heck IS this buffer anyway" confusion issue.

However, looking at the implementation of jack_port_get_buffer, it's
expensive enough (lots of branching) that this might not be a good idea
for performance reasons.  Performance vs. API :(

Aside from clarity of API reasons, there's a more important problem:
when this is extended to support event types other than MIDI (ie OSC)
some functions are likely going to need to know what type of events
they're dealing with.  If they're passed a buffer rather than a port,
they can't get at that information - unless it's stored in the buffer
itself.

This is the sole problem I've found with making this support any event
type, BTW.

Thoughts?

-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 API, passsing ports vs passing buffers

deviant
it must be possible to allocate a buffer that doesn't belong to a port
which can be written to. if this can't be done then you can't write data
to a buffer offline and then memcpy it into a port in a process
callback.

On Wed, 2005-11-09 at 13:52 +1100, Dave Robillard wrote:

> This is mostly for Ian:
>
> Looking at the MIDI API strictly from the client perspective, is there a
> good reason why the buffer is being exposed to the user at all?  I see
> the comment in the patch about this, and I think I agree that exposing
> the buffer to the user is a bad idea.  If the buffer is not to be
> accessed directly, it probably shouldn't be handed to clients at all.
>
> It would be cleaner looking to pass the port itself, and not the buffer
> returned by jack_port_get_buffer, and it would avoid the previously
> mentioned "what the heck IS this buffer anyway" confusion issue.
>
> However, looking at the implementation of jack_port_get_buffer, it's
> expensive enough (lots of branching) that this might not be a good idea
> for performance reasons.  Performance vs. API :(
>
> Aside from clarity of API reasons, there's a more important problem:
> when this is extended to support event types other than MIDI (ie OSC)
> some functions are likely going to need to know what type of events
> they're dealing with.  If they're passed a buffer rather than a port,
> they can't get at that information - unless it's stored in the buffer
> itself.
>
> This is the sole problem I've found with making this support any event
> type, BTW.
>
> Thoughts?
>
> -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 API, passsing ports vs passing buffers

Dave Robillard
On Tue, 2005-08-11 at 20:27 -0800, ian esten wrote:
> it must be possible to allocate a buffer that doesn't belong to a port
> which can be written to. if this can't be done then you can't write data
> to a buffer offline and then memcpy it into a port in a process
> callback.

Good point.

Now that I think of it, the only functions with this issue are for
mixing and reading/writing events from/to a buffer.  The type of event
stored in the data member shouldn't be important for these operations.

... or should it?


-DR-

P.S.  Please don't top post either. :)



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