Re: [Jack-Devel] Proposal: JACK MIDI API extension for system exclusive messages

PrevNext  Index
DateFri, 01 Apr 2011 12:38:58 -0700
From Devin Anderson <[hidden] at charityfinders dot com>
ToPedro Alves <[hidden] at gmail dot com>
Cc[hidden] at lists dot jackaudio dot org
In-Reply-ToPedro Alves Re: [Jack-Devel] Proposal: JACK MIDI API extension for system exclusive messages
Follow-UpTim E. Real Re: [Jack-Devel] Proposal: JACK MIDI API extension for system exclusive messages
On Fri, Apr 1, 2011 at 12:32 PM, Pedro Alves <[hidden]> wrote:
> On Friday 01 April 2011 20:04:02, Devin Anderson wrote:
>> No.  The 'jack_midi_blobstream_t' type would allow file-like
>> operations on blobs.
>>
>> I don't envision blobs growing dynamically.  A client knows the size
>> of sysex messages it's going to send, and should be able to deal with
>> received sysex messages in another thread if memory allocation is
>> necessary.
>>
>> The only exception would be MIDI drivers, which have no idea about the
>> size of sysex messages they might receive.  In this case, I think
>> command-line arguments should be used to specify the number of blobs
>> and the size of the blobs that a MIDI driver should create before
>> starting.
>
> Okay.
>
> And, I understand that a blob always must hold a whole complete sysex?
> Or can we split a sysex over several blobs if we wanted (with a flag
> in jack_midi_blobstream_t indicating there's more to come, or "this
> blob is the next chunk of a previous incomplete sysex").

I think continuing to guarantee one complete MIDI event per
'jack_midi_event_t' object is the best way to go.  It's a disadvantage
for MIDI drivers, but it's simpler for most other clients.

> Alternatively, given you have a stream API, drivers could still preallocate
> a pool of N blob chunks of M size each (roughly, your "number of blobs and the
> size of the blobs"), and those blob-chunks could be moved out of the
> pool and linked-listed per sysex/blob, and released into the
> driver's blob-chunk pool again as readers move past the blob-chunk,
> all hidden from the clients.  If clients aren't fast enough advancing
> their read streams, so that the driver ends up with no blob chunks left,
> clients would get their read streams closed, and their next read would fail.

This sounds too complex, both in implementation and for clients.

-- 
Devin Anderson
devin (at) charityfinders (dot) com

CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
PrevNext  Index

1301686758.14180_0.ltw:2,a <AANLkTi=7Z_K617zLyNUPBJpXTNf3m9HVftHRkkDUbvpC at mail dot gmail dot com>