systhread : can i use outlets directly?

    Nov 01 2013 | 7:15 pm
    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 01 2013 | 9:16 pm
      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 02 2013 | 12:26 am
      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 02 2013 | 1:40 am
      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 03 2013 | 6:41 pm
      Thanks again - 1ms is ok, as long as its reliably 1ms, i.e. a small amount of jitter.
    • Nov 03 2013 | 7:03 pm
      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 | 10:46 pm
      @nicolas i would like to see your example but you seem to be deleted on github.?