trigger vs. delay

    Feb 09 2014 | 10:56 pm
    Hello all,
    I am having a problem trying to use a trigger together with [seq] that is driving me nuts. Basically, I want [seq] to first receive a (read file.MID) message and then receive a bang to start playing it. Simple enough, but I can't make this work - it looks like the reading of the file takes longer than expected. The "solution" so far is to use a [delay 1] object before the bang, so the [seq] objects has time to properly load the file. This is horrible though, because the delay on my patch get accumulated, and soon every channel is out of sync with each other.... (after 100 short MIDI files are played, the delay will be of 100ms comparing to its initial position).
    Is there any way to solve this? Below is a simple patch showing the problem. It uses 2 simple files named 1.mid and 2.mid. The idea is that 1.mid has to be played only once, after which 2.mid will be looped (until the user clicks on the stop message).
    So anyone have any idea how to improve this situation? I also considered using [detonate], but I could not find a way of getting a bang when the midi file is finished (nor do I know if this situation would not be also present with [detonate]).
    Thanks a lot! Gilberto

    • Feb 09 2014 | 11:22 pm
      stay away from [delay] in these situations, it can cause more trouble than helps, in the worst case scenario it can reverse the order of messages.
      does a simple trigger not work?
      "load filename.mid, start" style messages should work with all objects which can load files, as the whole loading process is in the queue.
      i would probably write that
      "filename.mid" | [prepend read] | [t start l] | external
    • Feb 09 2014 | 11:28 pm
      oh, now i see your patch.
      there is a problem with the way you are using the finished flag.
      from the reference:
      Output bang: Out right outlet: Indicates that seq has finished playing the current sequence. (The bang is sent out immediately before the final event of the sequence is played.)
      the current data is the problem, not the next file. :)
    • Feb 09 2014 | 11:47 pm
      Hi 110,
      Thanks a lot for your reply. I totally overlook this detail about the bang being sent before the final event.
      So would you or anyone else have any suggestions on how to solve my situation without using a delay?
      Thanks a lot! Gilberto
    • Feb 10 2014 | 2:04 am
      I would simply use multiple instances of [seq] and preload all midi files. Note that multiple instances of a patch can be created automatically with poly~.
    • Feb 10 2014 | 9:03 am
      Hi Broc, I will give it a try. Thanks a lot!
    • Feb 19 2014 | 9:25 pm
      Hi Broc (and everyone else),
      I finally had the time to give this solution a try, and although I think I understood well how [poly~] works (and also how it can take arguments via "args #1 #2 ..."), I can't find a way of using several [seq] objects when each single one of them should have a different MIDI file preloaded (the MIDI files I am using are named as numbers, as 1.mid, 2.mid, 3.mid etc.).
      Could you or anyone else please point me in the right direction?
      Thank you very much, I really appreciate your help.
    • Feb 20 2014 | 1:40 am
      you can use the flag, but introduce a [gate] after it, which waits for the next event output, then bangs once.
      hint: to "delay and hold" and bang, just transform it into "1".
    • Feb 20 2014 | 10:05 am
      Now I've got it! Thanks a lot Roman!