Unable to stop qlist
May 03 2021 | 11:56 pm
I'm trying to create a qlist that plays back automatically and then pauses to wait for user input at a certain item in the list. Attached is a patch that should to just that. At item 7, the qlist sends a bang to a receive object that in turn bangs a "stop" message to qlist's inlet. The qlist ignores this message. However, if you manually send a bang to the same receive object, qlist does not ignore it. Is this a bug, a feature, or am I overlooking something? Thanks.
- May 04 2021 | 12:35 amOh, this is interesting. I've never played with qlist before... judging by the documentation, seems like one of the more ancient parts of Max.I opened your qlist up and had it send a range of different commands to itself... none of them behaved as they would have if I'd sent the same command manually.This is just a guess, but it seems that qlist does not like receiving commands on the exact same clock/event cycle/thread-whatever that it uses to send out an item. (forgive me, I forget the correct Max terminology for event scheduling)Anyway, here's a dumb fix that may or may not be useful for your purposes:In place of defer you could also use anything that holds back the bang a bit, like a delay.
- May 04 2021 | 1:59 amInteresting, thanks for looking into it! Your patch doesn't work for me, the qlist still continues to read.
- May 04 2021 | 2:03 amOdd, it works for me in Max 8.1.9. What version of Max are you on?Here's a version with delay, that also works for me:
- May 04 2021 | 6:42 pmI'm on 8.1.10, MacBook Pro 2017.
- May 04 2021 | 6:48 pmOdd that neither of these examples work for you, then. I always re-copy and re-paste anything I post here, right after I send it, both examples stop the qlist @7 100% of the time for me...and there's nothing in the 8.1.10 release notes re: any fixes/changes that might impact.But given your original maxpat fails the same way for both of us, I still think the fix lies in not having the qlist receive a command on the same scheduler priority/thread that it uses to send that command. This isn't necessarily consistent with how most other objects in Max behave, but I've seen far stranger inconsistencies between objects from different eras of Max development.
- May 04 2021 | 7:01 pmActually I just tried the delay 0 and it works! Defer still doesn't for some reason, but that solves my issue for the time being.
- May 04 2021 | 7:15 pmMaybe some of your deeper Scheduler preferences got tweaked at some point? This is a good reminder for me to not trust the defer (and maybe also deferlow) objects in patches intended for other people. Anyway, I'm glad to delay0 got it working :)
- May 04 2021 | 8:16 pmThanks! While we're here, I've found a new qlist quirk, maybe you can explain it? Qlist messages seem to be processed differently than regular ones (how or why I've not clue). Attached is a similar patch in which qlist is sending messages to thispatcher.
- May 04 2021 | 8:24 pmSolved!
- May 04 2021 | 10:53 pmNice work!Here's a more direct route:What was happening was that your qlist command had the entire message contained within quotes, which in the domain of Max means that item is treated as a single symbol, not a list of commands. thispatcher needs a list, not a symbol, so "fromsymbol" converts your symbolic entry back to a list. Apologies if any of this is review/needless explanation.
