gilbertoagostinho

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

trigger-vs-delay

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.

"load filename.mid, start" style messages should work with all objects which can load files, as the whole loading process is in the queue.

"filename.mid"
|
[prepend read]
|
[t start l]
|
external


there is a problem with the way you are using the finished flag.

bang: Out right outlet: Indicates that seq has finished playing the current sequence. (The bang is sent out immediately 

 the final event of the sequence is played.)

the current data is the problem, not the next file. :)

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

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?

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~.

Hi Broc, I will give it a try. Thanks a lot!

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.

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.


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

trigger vs. delay