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

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)

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.

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

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 :) Thanks

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