My approach has been to access the Morph in a separate process and send OSC to whatever other process wants it. This works well for a handful of reasons, including the fact that previously the Morph would timeout and fail when there were pauses (e.g. when you hit a breakpoint in a debugger, or when the program is just too busy doing other things). They finally added a special register in recent Morph firmware that lets you tell the Morph to not timeout. See the last few messages in this topic: Pausing (e.g. in a debugger) causes all subsequent APIs to fail
The handful of advantages of a separate process with TUIO over OSC is occasionally outweighed by the advantage of bundling things into a single process. Now that they’ve provided a way of working around the timeout issue, I’m starting to move toward bundling it in and avoiding TUIO over OSC. One of the advantages of bundling it in is that the Morph API actually gives you START/END events, so you can completely avoid the need to do the polling and “alive” messages that TUIO requires. That’s a significant simplification.
It would be cool/interesting to hear you describe what you’re intending on doing, in Blender. Drawing? Or other control? There’s a serious lack of drawing apps that can use the Morph, it would be nice to see some progress there. While the Morph is amazing for music, its use as a painting controller for visual things is for the most part unrealized and unexplored.
…Tim…
