I am trying to get Sensel Morph to work inside Blender. I am using a Modal operator which uses a timer to scan the frame from the Morph. However, I can’t get the software to exit the program, forcing me to use a Keyboard Interrupt. When I try to restart the script, the program crashes. I believe this is because I did not properly close the Morph. Is there a way to force close it on restart? I no longer hav the handle function available. I need to figure out how to interrupt better, but it’d be great to be able to ensure that the Morph is not in use before loading.
What OS are you on? On Windows, I’ve never had the Morph be inaccessible after a program (using the SDK) stops abruptly without closing it. However, sometimes a program will be “in the process of crashing/stopping but not yet completely terminated” - are you sure the previous program has completely terminated?
…Tim…
The problem is that the previous program has not completely terminated, leaving some clean up functions undone. I think this is an issue with how I’m using Python inside Blender. I was hoping there might be some function/method in the API to test if a device is already open/accessed in memory. Think I just have to solve on the interrupt side and make sure I get the clean up done properly.
The cleanup functions are nice to do, but aren’t actually necessary, in my experience on Windows. All you have to do is completely kill any/all processes that have previously opened the Morph.
I’m still interested to know which OS you’re running on - if it’s not on Windows, my experience isn’t relevant.
…Tim…
BTW, my C code never calls senselClose(), even when exited normally. I have a separate executable that opens the Morph(s). If your code is running inside Blender, I think you’ll need to kill and restart Blender.
…Tim…
Interesting, I wouldn’t have thought that I would need to kill and restart Blender. But that is the current fix (albeit not by my choice to crash it).
I’m using MacOS. I’m able to open the Sensel device via the Python examples from a terminal, but not if the device is already open on the Blender side. I assume there’s some kind of blocking to prevent concurrent access on the device?
Blender has a Python console and messing around, there seems to be a timeout function that allows me to reconnect to the device without restarting Blender. I’m not sure how to repeat this trick. It is based on the Unix device system, though, so maybe not Windows relevant.
By the way, Tim, I love your set up and am really impressed with your work. I’m taking baby steps, but inspiring to see what others are able to do.
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…
1 Like
Thank you for the link to the Pausing thread! Sounds like a conversation I should be familiar with.
I’ve been considering using OSC. I am very lucky you wrote a library! I’m interested in programming devices so I will check out your code. Someone made a NodeOSC Addon for Blender which could fit my use-case.
My intention is to to replicate a camera controller available for Unreal Engine. Here’s the physical controller: https://store.monogramcc.com/pages/virtual-production
Basically the device controls common camera techniques (pan, tilt, dolly) for a virtual camera. I’m using Blender to create a virtual set for a multicamera production on a green screen stage. I think the control may be a little too complicated for MIDI, but OSC might be appropriate. I’m not as familiar with OSC, although I’ve had some work with the Lemur editor on iPad so it’s not completely new.
Thanks for all your advice and help!
Well, thank you for your help because the sensel.WriteReg to 0xD0 fixed my error! I’m not quite sure what might be happening, but instead of crashing when I try to re-run the Sensel script in Blender, the script continues to work. I still need to figure how to exit better on the Blender side, but this fixed my crashing problem. Maybe it prevented a null pointer from getting referenced? Thanks for sharing your expertise!
ETA: For anyone curious for the exact solution in Python, I just added “sensel.writeReg(handle, 0xD0, 1, [1])” after handle = sensel.openDeviceByID(…).
