Conference napalm::commusic_v1

    In my sequencer, if I have too much data for the MIDI bandwidth
    I just output as fast as I can, falling behind the intended time.
    As the offered data rate decreases I continue to output as fast
    as I can, until I am back in sync.  Thus, my solution is to have
    a slower clock, but it doesn't hurt too much of the rest of the
    sequence since I eventually catch up.
    
    In practice I do not see this problem, since I am careful when
    constructing sequences to not exceed the MIDI bandwidth.  The above
    is thus a theoretical discussion.
        John Sauter

    My QX does the zipper trick, spitting out what it can and just chuckin'
    the rest. Unfortunately, there is no discernable rhyme or reason
    to what data gets canned. Sometimes it's a note off....:^(
    
    All in all, I think I'd prefer glitches in sync to unsynced 'perfection'.
    
    Edd

    He he...  I just tried the pitch bend experiment last night on the
    Steinberg Research 24 track for the Atari-ST, and guess what happened:
    
    		Squeek-GROOOOOOOOOOOOOOOONK.
    
    My DX reported a MIDI error.  I think I over drove it's input
    capability, but I'm not sure exactly what the sequencer did!
    
    Thanks for your input.
    
    Steph.
    

    re: .2--What are "glitches in sync"?  I hope you don't mean that
    discarding a note-off is ever acceptable?
        John Sauter

    Nope, a missing note off is never acceptable, but given the choice
    of a stuck note or data playing 'catch-up' I'd take the obvious
    glitch and start over as opposed to a sublime that I might not catch
    until it's committed to tape. (Assuming studio environment, live
    performance would dictate the opposite.)
    
    Edd

    Sounds like it would be good to select programmably between the
    two behaviors.  (But don't tell me you want to switch mid-song!)
    
    Steph
    

    re: .5--I still don't understand.  You say that a missing note off
    is never acceptable (and I agree!) but you say you would prefer
    an "obvious glitch" to something more subtle.  From the point of
    view of the sequencer implementor, what sort of "obvious glitch"
    would be acceptable?  If I've got a flood of Note Off commands,
    what should I do?
    
    re: .6--I agree that it would be best to have a settable parameter.
    I am trying to figure out what the "other" setting is.  Would it
    be acceptable, in the "never delay a MIDI message" mode, to stop
    the sequencer and turn on a red light?  If so, you probably want
    a continuously variable parameter: ``never delay a MIDI message
    more than <n> milliseconds''.  Then you can set <n> large if you
    are live, and small in the studio.
        John Sauter

    If I may be so presumptuous as to speak for Edd, I think he was
    saying, "make it obvious that something's wrong so I can fix it".
    Delaying events is certainly not as obvious as throwing them on
    the floor.  This approach presumes that you have the opportunity
    to fix things (e.g., thin out your data stream, split the load across
    multiple sequencers, etc.) before you "go public".  One assumes
    that you've auditioned your data before you "perform" it in public.
    This used to be called rehearsing.
    
    Perhaps just a red light on the sequencer would suffice, a silent
    scream that "I'm already dancing as fast as I can".  What you want
    is some more positive way of detecting dropped or delayed messages
    in a 32Kb/s data stream than hearing (or not hearing) them.
    
    len.
    

    Well lets see...
    
    Assume studio work... I prefer my sequencer to be putting data out
    in perfect sync. (I use step-time and quantize functions religiously).
    Now, if I've got more data than the bandwidth can handle, I'd prefer
    to have the sequencer send what it could *in sync* and when the
    bandwidth is exceeded, just throw the rest in the bit bucket. This
    could possibly repress a note off command and leave me with a stuck
    note. This would be an obvious glitch. When data flow is below band
    width, continue. There's always the possiblity that a note off command
    wasn't part of the trashed data...
    
    Mayhaps the confusion lies in the 'never acceptable' statement
    referring to stuck notes. One way of dealing with this unacceptable
    condition is by starting over, possibly with something extracted,
    or at a slower tempo. 
    
    What I'm saying is I'd prefer to be whacked upside the head with
    a glitch than have some slightly outta sync data that kinda looses
    it's 'feel'...
    
    In live performance, I'd prefer the opposite; play catch up. 
                  
    I think your adjustable 'window of sensitivity' (c) is a great idea.
    Let the user define what's acceptable, perhaps not only in terms
    of time delay, but maybe some sort of user definable 'trashable
    data' hierarchy where you can define which data gets repressed first?
    
    The Yamaha QX5 has an interesting feature relevant to this discussion.
    It's called "Thin Out" or something like that. It removes every
    nth message from a continuous data stream, like pitch bend, aftertouch,
    etc., saving acres of memory and insuring adequate bandwidth.
    
    It also makes for some absurd effects...
    
    Edd
    
    

    I wish I'd known you were there, len. I coulda saved all that typing!!
    
    ...but you hit the nail on the head.
    
    Edd

    Thanks for the input guys; I understand now.  If I ever do another
    sequencer (possible, but not certain) I'll include this feature.
        John Sauter