AudioMatt

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

comment

message

zl.group

adstatus

toggle

metro

sprintf

button

counter

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?

Can someone explain why turning overdrive on screws up this small concise example?   It appears that the set message to the receive object i

-feature-report-overdrive-screws-up-forwardsendreceive

    "version" : "Version 8.1.0 (dcf61ce) (64-bit mac)",

    "osversion" : "Mac OS X Version 10.14.5 (Build 18F132) x86_64",

    "scheduler_in_audio_interrupt" : "on",

    "audio_drivername" : "Core Audio",

    "machine_id" : "66d5ed6deae16e8412e19294b0118550",

    "refreshrate" : 33.333332061767578,

        "CNMAT Externals" : "1.0.4",

        "Node For Max" : "1.2.3",

        "Video and Graphics" : "7.2.0",

        "zsa.descriptors" : "1.2.0"

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"
	}

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.

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.

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.


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++ :/

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. 

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.)


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 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.

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