systhread : can i use outlets directly?

Nov 1, 2013 at 12:15pm

systhread : can i use outlets directly?


I mentioned in another thread, Im developing a USB interface to an Eigenharp

in the above thread, Im considering using a MSP signal approach, but as a intermediate step i decided to try to continue using Max, and using a separate thread via systhread.

It works fine, but im unsure of one thing.
In my thread (threadproc function) is it valid to use outlet functions (e.g. outlet_list) ?

It works, but im wondering if I should really be using Qelem to queue these back into the main thread…. if this is the case, is there a list/guidelines of max methods can be used within your thread?


Nov 1, 2013 at 2:16pm

Yes, you should really be using Qelems for outlet calls in custom threads.
Please, look at the simplethread example in the Max/MSP SDK.

- Luigi

Nov 1, 2013 at 5:26pm

thanks, Ive seen the example, yes it uses qelem, but it doesn’t say it has to be this way, or explain why…

there seems to be no written explanation/guidelines as to what is thread-safe and what is not, this is critical in multi threaded apps.
Am i to assume that no max functions can be called, other than in the max main thread? but if thats the case, how come the schedule_delay example (run in the schedule thread at high prio) shows output in that thread?

my issue, is if i use a qelem then I am at the mercy of the scheduler as to when that queue will be processed, how can I know it will be processed in a timely manner (with respect to other events).

I can put it at the front, … but if its a low prio thread picking it up, its still potentially delayed.

essentially, as a controller device, its important the events get processed before other events which are less time critical – how do you do this in max?
( for controllers, a user can ‘feel’ unresponsiveness incredibly quickly)

Im an experienced programmer in multi threaded systems, but cant see how I can push high priority events thru the max system.

Im struggling to see the threading model in max, and the sdk doesn’t really document it, above saying the normal stuff about avoiding locks/memory allocs (which multi threaded programmers know anyway)

Don’t get me wrong, i know, i just need to understand the ‘max world’ better, so if someone can explain its ‘view’ im more than happy to adapt :o)

Nov 1, 2013 at 6:40pm

Many max objects and the inlet/outlet calls have threading assumptions. So you’ll need to either use defer/qelem for main thread or schedule/clocks for scheduler thread outlet calls. Most other commonly used API calls should be fine. Let us know if you encounter other problems.

Nov 2, 2013 at 8:01am

An approach: ( ).

Anyway keep in mind that even if you implement something very precise it will be limited down to 1ms as soon as you come back in the Max/MSP world.

Nov 3, 2013 at 10:41am

Thanks again – 1ms is ok, as long as its reliably 1ms, i.e. a small amount of jitter.

Nov 3, 2013 at 10:50am

To be more precise it is limited by the “Scheduler Interval” (for which the minimum is 1 ms).

Nov 3, 2013 at 11:03am

Yes, Id noticed all timing in max (delay, clocks, scheduler etc) were all 1ms minimums. the jitter concern is if this is accurate.
ie. if i reschedule will i get called 1,1,1,1,1,1ms or 1,2,1,1,1,3,1

you have all given me enough to give it a try, and I can see how it goes :)

Apr 14, 2014 at 3:46pm

@nicolas i would like to see your example but you seem to be deleted on github.?

Apr 14, 2014 at 10:41pm


GitHub sucks!

Below my email (in a copy-compressed patch).

– Pasted Max Patch, click to expand. –

You must be logged in to reply to this topic.