[Feature Report??] Overdrive screws up forward/send/receive??
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:
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"
}
}
I'd insert a [defer] before the [send].
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.
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.
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++ :/
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)
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.)
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
i see, i didnt look at the original patch, i am an architecture nerd myself.