Chris Rolfe

Is a qelem still required for thread safety when accessing Max outlets from within the MSP audio perform routine (ie, w/in main system audio thread)?

Can one now access outlets without such considerations under Max 8 (seems to be the case in my test object, at least no crash or complaint)?

Also, are qelems still the recommended mechanism for thread safety; or would a clock and critical sections be the more modern usage? I became a bit lost following the SDK documentation on threading changes from Max 5 to 6 to 8.

max-sdk-8.0.3/html/chapter_scheduler.html

max-sdk-8.0.3/html/group__qelems.html#details

Is a qelem still required for thread safety when accessing Max outlets from within the MSP audio perform routine (ie, w/in main system audio thread)? 

Can one now access outlets without such considerations under Max 8 (seems to be the case in my test object, at least no crash or complaint)? 

Also, are qelems still the recommended mechanism for thread safety; or would a clock and critical sections be the more modern usage? I became a bit lost following the SDK  documentation on threading changes from Max 5 to 6 to 8.

see: 

max-sdk-8.0.3/html/chapter_scheduler.html
max-sdk-8.0.3/html/group__qelems.html#details

Is a qelem still required for thread safety when accessing Max outlets from within the MSP audio perform routine (ie, w/in main system audio

updating-max-5-to-max-8-externals-are-we-still-using-qelems

I vaguely remember dealing with this in the Granular Toolkit / LowkeyNW package. In case it proves useful, here is the source code for [nw.grainbang~] circa 2006:

https://github.com/nwolek/LowkeyNW/blob/774b2283e26ee143d9b5d5e303fa9ffaa3b2a6ea/source/nw.grainbang%7E/grain.bang%7E.c

https://github.com/nwolek/LowkeyNW/blob/master/source/projects/nw.grainbang_tilde/nw.grainbang_tilde.cpp

However, it looks like my "overflow" outlet is outside the perform method. Cheers.

Chris:
I vaguely remember dealing with this in the Granular Toolkit / LowkeyNW package. In case it proves useful, here is the source code for [nw.grainbang~] circa 2006:

https://github.com/nwolek/LowkeyNW/blob/774b2283e26ee143d9b5d5e303fa9ffaa3b2a6ea/source/nw.grainbang%7E/grain.bang%7E.c 

https://github.com/nwolek/LowkeyNW/blob/master/source/projects/nw.grainbang_tilde/nw.grainbang_tilde.cpp 

Thanks for the examples, Nathan (nice work on the LowkeyNW release, btw: it's kind of you to publish the source).

Defer seems the way to handle Max messages which (may) arrive at high-priority.

But after a little more digging: the 8.02 SDK states one "cannot use qelems or outlets" [1] within a perform routine: a clock is the *only* safe mechanism.

The reference further says that a call to defer() "creates a qelem" and then calls qelem_front(). Unless the docs aren't quite up-to-date, that would seem to put the kibosh on calling defer() or defer_low() from perform. I think the issue is that the audio hardware driver callback isn't actually on EITHER of the two main Max threads: it's a callback from CoreAudio or whichever hardwire driver.

I haven't had any issues yet with qelems in older objects (used to be how one did it, at least in the Max 4/5 era), but perhaps I need to run more stressful testing. Anyway, a clock should work for my purpose. 

Thanks for the examples, Nathan (nice work on the LowkeyNW release, btw: it's kind of you to publish the source).   

Defer seems the way to handle Max messages which (may) arrive at high-priority. 

But after a little more digging: the 8.02 SDK states one "cannot use qelems or outlets" [1] within a perform routine: a clock is the *only* safe mechanism.  

The reference further says that a call to defer() "creates a qelem" and then calls qelem_front(). Unless the docs aren't quite up-to-date, that would seem to put the kibosh on calling defer() or defer_low() from perform. I think the issue is that the audio hardware driver callback isn't actually on EITHER of the two main Max threads: it's a callback from CoreAudio or whichever hardwire driver. 

I haven't had any issues yet with qelems in older objects (used to be how one did it, at least in the Max 4/5 era), but perhaps I need to run more stressful testing. Anyway,  a clock should work for my purpose. 


[1][Max SDK 8 "The DSP Method and Perform Routine"]  The perform routine is not a "method" in the traditional sense. It will be called within the callback of an audio driver, which, unless the user is employing the Non-Real Time audio driver, will typically be in a high-priority thread. Thread protection inside the perform routine is minimal. You can use a clock, but you cannot use qelems or outlets.

[2][Max SDK 8 ] The audio perform routine is run inside a thread that is controlled by the audio hardware driver. In order to eliminate excessive thread blocking and potential race conditions, the thread protection offered inside the audio perform routine is far less comprehensive, and as discussed in the MSP section of the API documentation, the only supported operation for perform routines to communicate to Max is to use a clock. This will trigger a function to run inside the Max scheduler.

Good questions. The mechanism you should be using for getting data from the 

 and then from the clock's callback to use a 

If you are using the Min-DevKit you can use a clock that you specify to automatically defer.

Good questions. The mechanism you should be using for getting data from the audio thread to the main thread should be to use a clock and then from the clock's callback to use a qelem or defer().

Just to ask, do ITM's qualify? I gather they're clock-based.

ITM is a layer build upon the clock, so yes: all the same rules apply.

Updating Max 5 to Max 8 externals: are we still using qelems?