On Fri, 3 Apr 2015, Hermann Meyer wrote: I would also say that in my opinion as a novice coder, the jack MIDI interface is easier to use. Any MIDI event has a known time of arival based on sample number. All incoming MIDI events are presented to the programer as complete events so you don't have to deal with running status. The only downside is longer sysex events. I think there is work underway to deal with this as well, but of course a long sysex no longer would have sample acurate timing (maybe the first part will be time stamped) or at least would have added latency (ie. it would no longer be real time anyway). But that is a problem rawmidi would have to deal with as well. I do not know if there is a particular byte count limit to sysex events or if it varies with jack latency (the length of the cycle). But if you expect users to use this live, then it needs to work with reasonably low latency. -- Len Ovens www.ovenwerks.net

On Fri, 3 Apr 2015 20:16:37 +0100 Gordonjcp <gordonjcp(a)gjcp.net> wrote: From the hardware viewpoint SysEx events can be effectively infinite. The header contains the number of bytes in the block, so the number representation limits the block size, but synths can, and do, send multiple blocks. There is nothing in the spec limiting them! I think my old QS300 sends about 9 or 10 blocks for a complete system save, and takes 4 or 5 seconds to do so. During this time it can do nothing else at all. One of the problems is there is no agreed method of determining when the last block has been sent :( This may have changed of course. The last time I got involved in trying to manipulate MIDI messages was mid to late 1990s. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.

On Fri, 3 Apr 2015 15:37:27 -0400 Paul Davis <paul(a)linuxaudiosystems.com> wrote: I stand corrected. I'd seen it in both Yamaha and Roland manuals and obviously made an invalid assumption :( -- It wasn't me! (Well actually, it probably was) ... the hard part is not dodging what life throws at you, but trying to catch the good bits.

On Fri, 3 Apr 2015, Gordonjcp wrote: Even RPN/NRPNs start to wander from sample accurate.... Both are effectively single events that are sent as 4 events (12 bytes to send 4 bytes of info) A minimal sysex would be 7 bytes for the same task or 9 bytes with extended ID. This is assuming the first byte (of the four data bytes) can also tell the receiver what kind of data is coming. Of course the (N)RPN could be sent as 9 bytes too using running status. In Jack's case the (N)RPN is still 4 events while the sysex is one. Note: this page: http://www.philrees.co.uk/nrpnq.htm Suggests "best practice" for (n)rpn use includes nulling the parameter number with yet another two events, for 18 bytes or 13 with running status. -- Len Ovens www.ovenwerks.net