trigger vs. delay

gilbertoagostinho

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

Max Patch

Copy patch and select New From Clipboard in Max.

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

1.mid

mid

2.mid

mid

Roman Thilenius

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

Roman Thilenius

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

-110

gilbertoagostinho

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

broc

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

gilbertoagostinho

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

gilbertoagostinho

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.

Roman Thilenius

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

gilbertoagostinho

Now I've got it! Thanks a lot Roman!