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

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").

If that would be an option, then, it would have the disadvantage
of clients needing to be aware of sysex's in chunks.

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.

No doubt more complicated than your proposal...

-- 
Pedro Alves

1301686362.13904_0.ltw:2,a <201104012032.23843.alves.ped at gmail dot com>