[Feature Report??] Overdrive screws up forward/send/receive??


    Mar 26 2020 | 1:05 am
    Can someone explain why turning overdrive on screws up this small concise example? It appears that the set message to the receive object is deferred somehow? Is this really correct?
    Is there anything I can possibly do to fix it without altering the architecture of the patch
    Here's an even clearer example:

    • Mar 26 2020 | 1:06 am
      Support info: { "version" : "Version 8.1.0 (dcf61ce) (64-bit mac)", "platform" : "mac", "arch" : "x64", "osversion" : "Mac OS X Version 10.14.5 (Build 18F132) x86_64", "samplerate" : 44100, "iovs" : 128, "sigvs" : 128, "scheduler_in_audio_interrupt" : "on", "audio_drivername" : "Core Audio", "audio_driver_subname" : "", "license" : "permanent full", "machine_id" : "66d5ed6deae16e8412e19294b0118550", "eventinterval" : 2, "schedinterval" : 1.0, "overdrive" : "on", "pollthrottle" : 40, "queuethrottle" : 100, "sysqelemthrottle" : 1000, "refreshrate" : 33.333332061767578, "schedslop" : 25.0, "eventprobing" : 0, "mixerparallel" : "off", "mixercrossfade" : 0, "mixerlatency" : 30.0, "mixerramptime" : 10.0, "videoengine" : "avf", "glengine" : "gl2", "packages" : { "BEAP" : "1.0.2", "BLOCKS" : "1.2.7", "CNMAT Externals" : "1.0.4", "cv.jit" : "1.8.0", "ease" : "1.1.1", "ejies" : "3.2.4", "jit.mo" : "1.1.2", "mat.oo" : "1.0.0", "max-mxj" : "7.2.5", "mi-gen" : "1.1.0", "Mira" : "1.2.1", "Node For Max" : "1.2.3", "sensel" : "0.4.1", "VIDDLL" : "1.2.1", "Video and Graphics" : "7.2.0", "Vizzie" : "2.0.3", "zsa.descriptors" : "1.2.0" }
      }
    • Mar 26 2020 | 9:44 am
      I'd insert a [defer] before the [send].
    • Mar 26 2020 | 11:36 am
      Doesn't that mean things might come back out of order? Tried it. it appears not but I use this architecture in time sensitive situations. Seems like a kludgy solution to something that should already work fine.
    • Mar 26 2020 | 1:31 pm
      See this article, chapter 'Changing Priority' https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue
      Apparently the set message cannot safely be executed at high priority and thus Max puts it on the low priority thread. So this feature of dynamic routing seems inherently problematic in time sensitive situations.
    • Mar 26 2020 | 1:45 pm
      Apparently the set message cannot safely be executed at high priority
      I get it but this seems like a bug. *Why* can't the set message be executed at high priority? It makes no sense. Is it oh so intensive of an operation? I sort of thought defering things was left for GUI interactions or picture rendering. Stuff that took a little labor. Is it the fact that it has to search the symbol table?
      It means I'm going to have to redesign 90% of my patches from the last 10 or so years because they all use this architecture assuming this didn't happen. Not only that I'll have to withdraw mat.oo from the package library.
      I guess it might be an opportunity to redo them in C++ :/
    • Mar 26 2020 | 6:42 pm
      one of the reasons i try to avoid s/r: you easily loose overview in regards of order and priorities. (possible bugs or "bugs", as seens with poly, bpatcher and m4l, add on top)
    • Mar 26 2020 | 6:46 pm
      the "set" message will create a new namespace, right? are there other examples where this doesnt work in hp? (i dont mean things like buffer, which are bigger than a handful of bytes.)
    • Mar 26 2020 | 8:27 pm
      I really could never give up send and receive. I patch without crossing scheduler rate patch cords with the exception of gate and one or two other objects. I use this method to create object oriented code instead of functional code. It’s a pretty big loss
    • Mar 26 2020 | 8:59 pm
      i see, i didnt look at the original patch, i am an architecture nerd myself.