[Sensel] Diminished time and space resolution
I was hoping to use the sensel morph as a midi performance tool similar to the linnstrument. So far the max software is vastly under-performing anything you'd need to get a decent musical performance timing wise and the resolution isn't great compared to what it's capable of. The site calls for .1mm resolution and 1ms frame rate.
Is there any chance we could get an "HD" version of sensel and jit.sensel?
@andrewbenson maybe?
Bump? Am I totally nuts here?
You're not totally nuts, but unless we can see what you're doing, it's hard to comment.
@max
I said this in my other reply but, I'm not coding MPC-style drum pads if the time resolution is 15ms. But let's start with that as one potential application?
bump?! I sort of bought this thing thinking I could use it with max.
I'm curious about this thing, but don't have the hardware. So, I can't help you. There is a guy at Sensel I know who is a Max user. Maybe contact their support?
Good call.
I'm testing your patch, and I am seeing rates around 8ms when nothing is happening and much longer intervals (~50ms) when I'm actually touching the pad. As you say, that isn't really great for tight control of percussive gestures.
To some extent, you're limited by Max's scheduler. However, maybe you'd have better luck with one of the overlays and a MIDI (or MPE mode)? I expect those should have better timing.
Yeah even 8ms is way too slow. I wanted to build a linnstrument sort of thing but it looks like that might end up being impossible.
I get a rate of 8ms with when out of edit mode. I guess the sensel external automatically sets the resolution of the sensor to "full", at a frame rate of 125 Hz, which corresponds to the 8ms update rate.
Currently I'm developing an external for pure data to connect the Sensel Morph there, and I get a much higher frame rate when scanning at lower resolution. The documentation promises a frame rate up to 2000 Hz (latency of 0.5ms), which sounds really great and promising for use with sound. But I'm still struggling to balance the load on the scheduler with the API calls. In my pure data external I get to a rate of 0.5ms which is great, but causing dropouts in the DSP thread. I'm still trying to figure out if this is a timing issue with the serial connection or the message scheduler overloading and how this can affect the DSP thread.
It would be lovely if our friends at Sensel published the source code of their Max external for the community to make some improvements. There are other threads on the forum suggesting features like "only output x/y data", or different shapes of the dictionary. I'd love to contribute! :-)
Agreed. I would have bought a linnstrument or a soundplane if I thought I couldn't make my own.
I've been working with the morph in openfameworks doing some basic machine learning tasks:
https://github.com/mzed/ofxRapidLib/tree/master/example-sensel-classify
The Sensel API is relatively clear. http://guide.sensel.com/api/ There are a variety of data that it can provide (touch points, full frame), etc. I'm not sure how these affect timing. The full frame data has 185 columns x 105 rows of "sensels", but the device will do some interpolation to get finer resolution.
Also, when it's acting as a MIDI device then communication is not through the API at all. Once I've had some coffee, I'll try to do some testing on the MIDI time resolution. I think that the Linnstrument sends MPE data, yes? Do you know what the soundplane sends?
My Max experience is that trying to get tight (single digit millisecond) timing in the control/scheduler domain is difficult. The ideal sensor would probably have data coming in at audio rate. That's how David Wessel did it with his SLAB controller: http://www.cnmat.berkeley.edu/content/slabs-arrays-pressure-sensitive-touch-pads
In Max, I'm getting very reliable 8ms delta times for specific events (like ctlin 74 3) using the keyboard overlay with an MPE map. That matches CSAUDIODESIGN's experience; it looks like the morph is sending MIDI at 125Hz. That seems like a fairly reasonable sample rate for that kind of data, especially since it seems to have minimal jitter.
This would suggest that the current path towards best timing is not to use the sensel max object, but to get data in via MIDI. You could setup a custom design with the innovator's overlay.
It would still be interesting to see the code of the sensel object. I'm curious to know where the bottlenecks are for reading more complex data. There are a number of steps between sensor and max patch that could be tricky, and the designers of this object needed to balance usability against raw performance. If I have time, I'll try to hack out an object that spits out some minimal data as fast as possible. But, probably not this week.
My test patch, which is pretty simple:
Another result:
With the drum overlay, I'm getting about 1.5ms deltas for incoming pitch bend data when moving my finger on one pad. That number goes up when I hold fingers on other pads, but never gets as high as 4ms. There is more jitter when I strike one pad while scrubbing on another: I get about 6ms deltas in the pitch bend data when the second pad is struck. Overall, that's quite good.
I found this out on this sensel forum thread, which says:
In MIDI/MPE mode with overlays, we are already doing some additional processing so you will never miss a hit and offer low latency (2 ms with drum overlay, 5-6ms with other overlays).
The sensel object is ideal for free-form interface where you want to take advantage of either force image or gesture. If you want to make a linnstrument or soundplane type thing, I'd highly recommend using the Overlay Designer feature of the SenselApp - http://guide.sensel.com/designer/ - where you can design your own layout of circles, hex, or rectangles.
Unfortunately for that use case its too limited, as it allows only 48 areas max. Its a limitation of the Overlay Designer as there are overlays with much more areas...
I hope it will be updated soon. It is officially in beta, but looks more like alpha...