[LAD] Advanced Gtk+ Sequencer aka GSequencer now on GitHub
willgodfrey at musically.me.uk
Fri Apr 3 19:35:29 UTC 2015
On Fri, 3 Apr 2015 20:16:37 +0100
Gordonjcp <gordonjcp at gjcp.net> wrote:
> On Fri, Apr 03, 2015 at 11:46:17AM -0700, Len Ovens wrote:
> > 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.
> I can't help but think that if you're doing something that requires sample-accurate sysex messages, you're doing something a bit strange and wrong :-D
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
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
More information about the Linux-audio-dev