the behavior of a message or bang when clicked manually vs triggered by automation

bluelemur's icon

Hi everyone,

something maybe stupid:

why the behavior of a message or a bang object change when clicked manually versus when triggered by automation? How to fix it?

Here a simple patch to know the number of lines of different txt file:

If i activate the Metro then at the end of the patch I have that the number of lines of the loaded text file is always wrong (it give me the number of lines of the other txt), if I deactivate Metro and I click on the bang under the metro object each time the number of lines of the text file is correct.

What's going on?

Thanks!

P.

mizu's icon

Maybe a "t query l" after the message "read file" , and a delay before "query", the time for text to access the disk. Maybe Max is considering the chain to execute differently if it kows the time of the next bang ? Or try to place the bang before query higher, near the gate, Max takes care of the place of the objects to execute :-) I don't know why this difference you see, i know an access to disk is something troubling to care around. You can too simplify and replace the gate with "sel 0 1 2". hth

bluelemur's icon

Hey Mizu,

thanks for the replay and the suggestions. The only thing that works is to use pipe or delay after query, and that's ok, I tried before, but this patch is a part of a bigger patch and using a delay there it mess up everything. It's funny because it seems that when the bang is triggered automatically, it doesn't follow the rule (right outlet first then left outlet). But if it's triggered manually with a click, then it does follow this rule, why does this happen?!

Bluelmur

TFL's icon

The issue leaves in the way the Max scheduler works. A bang (and all subsequent actions) triggered by a [metro] lives in the scheduler thread (high priority), while a manually triggered bang (and all subsequent actions) lives in the main thread (low priority).

The action of reading a file is usually done in the main thread, even if triggered by an event coming from the scheduler thread. So here, when using [metro], the query message will effectively be treated "faster" than the read message, hence the wrong result you see. When using a manual bang, both query and read messages will be treated in the same thread, and thus the query message will have to "wait" for the read message to be fully executed, giving the correct result.

Aside from a wacky [delay], there are a few proper ways to address the issue:

  • Defer the automated bangs, either by using [qmetro 3000], or [metro 3000 @defer 1] or adding a [defer] after your [metro 3000]. In the world of Max, "defering" means "put the action (and all subsequent ones) in the lower priority main thread":

Max Patch
Copy patch and select New From Clipboard in Max.
  • Or keep your incoming bangs in the scheduler thread, but rely on [text] middle outlet giving you a bang when the file is done reading to trigger the query message:

Max Patch
Copy patch and select New From Clipboard in Max.

I think the second approach is my preferred as it is the most meaningful to me.

If you want to know more about scheduling in Max, there's this very informative page in the doc!

bluelemur's icon

thanks so much, now everything is clear!