(universal ?) stack overflow remover

    vichug
    Feb 11 2010 | 4:16 pm
    Hi,
    here's something some people might find useful (or not)
    basically this works the same way as a "set $1" message box between two sliders, except it will cause output from both sliders rather than having one "slave" slider. The idea behind this should not have worked theoretically : i thought "yeah a message comes in a trigger, bangs a gate to pass through it and right after that it rebangs, so the gate will be closed for the next message wich would have been a fedback otherwise." I didn't think, logically, that the next message to come would retrigger everything, and pass, setting up a loop anyway. Luckily it just works fine, not too sure why, maybe just the time of calculation needed to trigger the thing makes it impossible to have the so feared stack overflow. I tried it with several kind of messages, the trigger objects outputs a list, so far it works fine for any kind of message. Let me know if there is trouble somewhere. So, i guess anyone has its own methode to circumvent that kind of max limitation, but maybe will it be helpfull to some people :)
    • Jesse
      Feb 11 2010 | 6:35 pm
      Not sure if I understand the context in which you're using this, but from my reading this abstraction could essentially be reduced to connecting the inlet directly to the outlet, and doing away with the trigger/gate altogether.
      Correct me if I'm wrong Maxers, but my take on [trigger] is that in most circumstances it guarantees execution of its instructions (in this case the [b l b]) before it processes further input. In this case that means you would always open the gate (b), pass the list through (l), and then close the gate again (b). This basically makes the gate unnecessary and adds overhead to your patch.
      I suppose the caveat in the explanation of trigger's behavior would be if trigger was being fed by a higher priority data stream (i.e. MIDI input) that was sending new data before trigger could fully execute. There are several approaches to dealing with this - you might want to use [speedlim] to thin the input data stream, or run Max in Overdrive to bring the scheduler into the high priority thread. You can also adjust the Max-wide scheduler parameters in the Max preferences dialog accordingly.
      I guess the more important point for those new to Max is that the scheduler is inherently sequential (serial), even though it appears to support many simultaneous actions (parallel). So don't worry too much about concurrence and contention for resources until you really find that it's happening.
    • stefantiedje
      Feb 11 2010 | 10:53 pm
      These are two ways, much better to prevent stack overflows and still passing changed values. The pattr solution is probably more universal, pattr has a built-in feedback detection...
    • vichug
      Feb 11 2010 | 11:51 pm
      i didn't know those two other ways... the "change" thing is interesting but not accurate in my case, where it's lists which i want to "loop". But for the pattr object, i don't know at all how it works and what it does... i'm gonna look that :s and @Jesse : "This basically makes the gate unnecessary and adds overhead to your patch." that's true, but that's anyway what makes the thing working... that's what i was meaning by "it should not work htat way, theoretically" and it's probably a matter of scheduler time caclcul or whatever. Anyway, i should have a closer look at the pattr... but that thing looks like a gas factory...
    • seejayjames
      Feb 12 2010 | 2:32 am
      Interesting about [pattr], I didn't know that. could be quite useful...I wonder how that kind of feedback checking is programmed into the object?
      Here's a way to have dual sliders locked to each other, or each freely moving. Probably there's a simpler way too, there usually is...
    • Guillaume Evrard
      Feb 12 2010 | 10:26 am
      the sw abstraction is your friend here...
      g