Max hangs & can't see what's precisely causing it; using UDP, speedLim, mc.receive + mc.send, regular receives

    Sep 13 2021 | 4:53 am
    Hello there,
    I've got an interactive installation that is heavily using Max/MSP (75% of project): Interaction tracking (Max), Graphic Animation response (Processing), 7-channel sound response (Max/MSP). I've got a Max bug where, what I've got works, until the program hangs. I can't quite predict WHEN it will hang. Rarely, it hangs shortly after reboot (1-5 minutes). When I try to manually recreate what I surmise is causing it, I can't replicate the problem. Yet, regardless it seems to hang after some interaction, say anywhere from 20-50 triggers over time. This stretch of time could be a 15 minute to 90 minute period, ballpark. I'm looking for insight/leads on what may be causing this. The Max icon says that it's stuck on an abstraction (channelChecker). Yet, not which use of that abstraction. There are 7 uses of that abstraction (with arguments to make their usage unique). Here's the work flow: 1. Computer 1 sends a (channel) value over UDP to Computer 2. This value changes based off data from the Kinect (ie interactivity). Computers are physically linked via router that is constantly running. 2. Both ends of that communication use the speedlim object on either side, to slow down excessive values. Parameters are 500 (Computer 1 output), 1000 (Computer 2 input before passing elsewhere), 500 (Computer 2 at local points within individual abstraction usages). Initially, this seriously mitigated the of Computer 2 hanging. 3. Computer 2 then sends that value to a particular abstraction that then sends it off to another particular abstraction (there are several instances of this particular abstraction). This particular abstraction - "channelChecker" - checks to see if that particular channel (abstraction arguments) is in use, particularly if that channel is triggered ( via value passed in from UDP interaction from Computer 1 ). For example "Channel 1 is triggered. Is channel 1 currently in use? No? Then play. Yes? Then no information passage." If the audio channel is currently in use, a Gate object is closed and the value cannot pass through it. If the audio channel is not in use, the value can then pass through the gate, onwards to play a sound file.
    When Max hangs, it tends to be after so much time or interactions, and the "max not responding" points to this abstraction. Yet, not to the specific one. I'm puzzled as to why it points to hanging here, and not quite consistently. Or, I can't find the consistency just yet.
    I'm grateful to any insights.
    I'm thinking:
    - perhaps there is a flood of messages between when a channel isn't playing and a file is set to play AND when that file starts playing
    - ?
    What might you think? Where/What in particular is causing Max to hang? PLEASE let me know what you posit. 4. Other info: Computer 1: M1 Mac, Big Sur, running Max 8.1.10 (I believe); Overdrive set to "on" Computer 2: High Sierra, Presonus Firepod, using 7 channel, running Max 8.1.10 (I believe), Overdrive set to "on"
    Thank you in advance for your time and consideration. I do appreciate it.
    ~ LadyK

    • Sep 13 2021 | 6:05 am
      I'd say you need to simplify the flow. For example let each player control to accept new file playback or not without any complicated abstractions and iteractions. Simply, if I am playing, leave me in peace. If I am not playing than give me new file to play. Needs only 1 number~ and gate opened if position is not higher than zero. If you look at the rest of it that way, maybe you'll get it functioning without strain and freezes.
    • Sep 13 2021 | 3:29 pm
      completely wild guess, but can try putting deferlow after the udpreceive and replace speedlim with qlim. Could also try putting deferlow prior to any udpsend. Basically get all the networked stuff into the main thread.
    • Sep 25 2021 | 3:53 am
      thank you for your suggestions and tips on deferlow and qlim. I did work those in, yet, I do not think this is a UDP issue.
      I have simplified things to where only 3 channels can play at once. I figured that something might be happening with either some feedback or other sound not completely clearing from the channel (see the patcher "checkChannel"). I've made a gate, which closes if 3 or more channels is active (see the patcher "tooActive").
      Still, and not at a predictable increment of time nor triggers, Max hangs.
      It's not clear to me, what is causing Max to hang.
      The crazy part is: When I check the dock (and control click on the Max icon) when it hangs, Max says that an abstraction, that is not even in use, is "not responding". And by not in use, I mean, no longer present in the patch (nor subpatchers, nor abstractions) AND not present in that file directory. It's also not a directory that is loaded into my Max file preferences. (and yes, I've rebooted, numerous times)
      How can this be??? Is Max getting hung on something, and just coughing up an old message? Is it something with the parent directory?
      I'm baffled.
      Does anyone have any clues? Tips? Background info? Anything?
      I'm grateful for any insights.
      Most sincerely,
    • Sep 25 2021 | 2:04 pm
      Max behaves sometimes strange on windows, can keep hanging even without being shown in the taskbar, one has to go into taskscheduler or whatever the name of that is, and kill that hanging max instance to be able to reopen it. You can't expect from hanging Max to show any usefull information about it's state, because it is hanging. But, beside all that quirks, I will repeat again - you patch is terribly inefficient. You are causing some trouble by trying to get the logic of detecting player states, using that to set the rules and act. Somewhere in the chain you make max irresponsible. look at this little cutouts : why so complicated ? few yellow colored objects do the same.
      example above won't hang max, but it is a principle not to throw too much water out of the bathroom if not needed. next one, patcher "checkChannel"
      and "tooActive"
      In this case you send signal play position of sfplay using mc.send to several places, then try to catch play position, use bunch of onebang and whatever objects to ? I don't know what. And most of the mechanism is repeated and repeated, and you loose control what is state of the players and what makes max hang.
      ------ That is what I meant in my first post, you need to reduce repeated and unneeded actions in order to rule the flow, prefereably place reports from all players into single patch so that you can monitor it all easier. I did not spend much time to analyse the patch you posted, but it looks that you only need playing state, current play position and file length (in order to manipulate volume) why not in a simple way example shows 1 player and "only 3 players in use" gate (this "reduction" to 3 instances will definitely not cure the problem but add to the confusion, as even more objects and gates etc are added to the patch)
      to continue ... You select random file to play, send open message to one player instance.
      You KNOW which instance, because you open it's gate. But instead of setting THAT players file length info to calculate volume change offsets, you repeat sfinfo~ querry in each player again ?
      I think that are enough examples for the time being.