Looking to record sensor data
Hello there,
I have been trying to figure out a way to make a "recording" of sensor data into a list file, and then use that list file to populate an object that would replay that sensor data later even though the sensors weren't attached. This is probably really easy but I'm not getting it.
The sensor data is scaled to integers between 1-100 (I suppose they could be scaled to anything), and I would like to sample the data at 10hz for at least 15 minutes, though ideally I would like to make recordings that were 45 mins long. I'm trying to simulate my sessions with people interacting with the sensors. I was trying to do this through some combination of pattr and multislider and...maybe preset? I'm not sure because nothing I have tried works. I have noted other posts on the forum that deal with reading buffers to popular multisliders but this doesn't translate yet, for me.
In the end I am going to be using up to 5 sensors simultaneously for the recordings, if anyone has a quick solution for how to do this that would be great.
Thanks! Erin
This should hopefully be an OK start for you. To replay the [coll] object back out, look at the [coll] help file - you'll essentially just use another metro at the same rate your data was recorded, and an unpack object to split the sensor data back up. You might also want to use a [line] or [line~] object to smooth the data a bit.
Though I know very little about your sensors, I would take a guess that integers from 1-100 is going to result in some loss of fidelity (that's really not that many numbers!). If you must use integers, I would go at least 1-1024, but ideally a float from 0.-1. (which is my usual preferred method - it's then very easy to scale to whatever else you might need, and plays well with Jitter and MSP without much extra hullaballoo.)
Here's a version that uses (fake) floats from 0-1, as well as a 'reset' button for the coll.
Cool! I'll take a look at the values, you have a point there.
Here's what I did with your code....now if only there was an elegant way to clear the multislider data quickly..... ;)
Not exactly elegant, but faster, at least.
You'll have to go through and give scripting names to the other multisliders (I only did it for the first one) and duplicate/modify the messages. - I'm just resizing the multislider by one pixel briefly, which seems to clear the internal cache. (if it doesn't seem to work, for whatever reason, change [deferlow] to [pipe 1] or [pipe 5] or so.)
you can also use [mtr] instead of [coll], but you can't view the data as numbers easily like you can by opening up the [coll] window.
With some fiddling you can use a 5-cell jit.matrix and save it as a jit.qt.movie, which means more fun playback options like speed control and scrubbing...if you want it, that is :)
Nice trick with the multislider BTW. Could be a good feature request.
Ah! [mtr] is actually what I was looking for in the first place - but I couldn't remember what it was called, and it wasn't popping up in the 'similar objects' lists of anything I tried.
That multislider trick is something I just happened upon while trying to figure out an easier way of clearing it - oddly, sending it a 'size' command directly changes the number of sliders in the multislider (even though it's a 'common box attribute') - I'm guessing it's like that for backwards compatibility.
Jitter matrices was another angle of attack I toyed with, but it seemed a bit over-complicated for what Erin said she needs - and I've had some issues with QT recording that, while normally fine for video stuff, probably wouldn't work well for this (dropped frames/duplicated frames due to a CPU spike would make for some odd sensor data). I'm sure speed control and scrubbing could be rigged up relatively easily (use a [train] instead of a metro, change the frequency - check for a negative number on the input and use that to change the direction of the playback [counter] object feeding the [coll], for example)
I liek Max. So many different ways to do things!