How to read Unix timestamps in Max/Msp?

Sara's icon

Hi,
I am working on a project where I collect data from analog sensors using an Arduino data logger shield.
This device creates a .txt document of the data with a time stamp. It looks something like this:

"9 1347407185
8 1347407642"

(It creates a list of these 2 columns of numbers, The left number is the number from the sensor between 1-100, and the right is the Unix timestamp in milliseconds of when the data was recorded)

I then want to use this .txt file and input the data to manipulate a pre-made video in Max/Msp/Jitter (such as the opacity,saturation, etc.). I know max/msp has a way to read the left column no problem, but is there a way to read these prerecorded timestamps and have them playback with the correct time delay between each one? Does that make sense? (So for example, if a light sensor recorded a reading of 9 at 8:02am, then a reading of 20 at 8:03am, I could then take this data and when I put it in Max/msp and have it change the level of opacity in a video, the video would start out at a level of 9, and then after one minute jump to a level of 20).

(note:My terminology might be off, I am a novice at max/msp)

Please ask if you need clarification!
Maybe to I am going about this the wrong way? Maybe there is a different software that is better suited for this kind of thing?

Jan M's icon

Hi Sara,
Max can very well do what you like. Where exactly are you stuck? Reading the text file? Take a look the [text] object and the help file for that.
Or do you have problems in working with the timestamp? To get the difference between two timestamps, just subtract them. Btw. I believe from your example that these are not milliseconds, but the "classical" timestamp in seconds, otherwise your example dates would be in 1970 :) - in seconds they date to september 2012.
Are you as well looking to format them to a human readable format?

Cheers,

Jan

Christopher Dobrian's icon

The task is: subtract item 2 of the previous list from item 2 of the current list, and use that as the number of milliseconds by which to delay item 1 of the current list (and you must store item 2 of the current list so you can use it as the "previous" timestamp for the next calculation).

It's actually pretty easy to do in Max using [unpack] to separate the list items, [int] to store the previous timestamp, [-] to get the difference between the two timestamps, and [pipe] to delay the first item (the sensor value).

The only wrinkle is that you want to ignore the very first timestamp so that your first sensor value doesn't get delayed by some ridiculous amount of time (since there is no previous timestamp to subtract from it). In the attached archive you'll find an abstraction called [delta] for ignoring the first value and then getting the difference between the next value and its previous value, a text file for simulating the timestamped sensor values you described, and a test patch called sensordelaytest.

delaysensorvalues.zip
zip
Sara's icon

Jan - thanks for the input! I was asking more about working with the timestamps. You are totally right, I see now it is recording seconds not milliseconds. No I don't need them in a human readable format. They are just there really to determine the amount of time that has passed between each recorded piece of data.

Sara's icon

Christopher-- Thank you so much for the attached archive! It's doing exactly what I need it to. The only small snag is that my arduino is recording the time in seconds not milliseconds (as Jan pointed out). I feel like this can be fixed by just adding a [* 1000] somewhere? I tried adding it between the delta and pipe, but that didn't work. I can try messing around with it on the arduino side so the text file is in milliseconds, but is there a way to fix it on the max/msp side?

Jan M's icon

Hi Sara,
in order for that you really just need to subtract them. Definition of the UNIX time stamp is "the amounts of seconds that have passed since 1/1/1970 - 0:0:0 am". So the difference will give you the delta-time in seconds.The only thing you should add to Christopher's patch is a multiplication by 1000 before sending the time to the pipe object (it works in ms not in seconds). If you want a smooth transition between two sensor values over time take a look at [line] and [line~].

J

Jan M's icon

oupps - cross posting. Your hunch was right. Just take into account that using Christophers values it will take long for the next value to appear. Her's a modified version of his patch with shorter delta-times.

delaysensorvalues-2.zip
zip
Sara's icon

Thanks Jan, I'll look into the line suggestion that might be nice to add in. For some reason though when I try to use my text document it still doesn't work, it appears to just zoom to the last number in the list... I'm attaching it. I'm not sure what the problem is with it.

delaysensorvalues-3.zip
zip
Sara's icon

Maybe it has something to do with the length of the number? No number seems to be outputting from the delta when I use my list of numbers.

Jan M's icon

hmm, here your file works fine. Are you resetting the counter? What do you mean by get't unpacked? In the Max-Patch or do you transfer the files compressed? The Numbers are well in the range and should not pose any problems.

The only difference between your file and Christopher's I see is the use of Line-Feed type. Your's is using windows Line-Feeds, Christophers UNIX Line-Feeds. I converted your's to UNIX LF, try if this works:

timestampedvalues.txt
txt
Jan M's icon

Btw, this a great moment to discover Max debugging - it's very helpful!

right/ctrl-click on the patch chord between the counter and the message-box, and select "add Watchpoint Break". This will enable debugging and you can see in a separate window step by what is happening ;)

Sara's icon

Eureka! Thanks Jan for suggesting the debugging tool, never used it before. I think I figured it out. In the delta patch I had to change all the floats to integers and the [-0.] to [-0]. With the help of the debugging tool I realized something was getting funky with the use of decimal possibilities. I wonder why it worked for you though? And your patches worked fine for me without changing anything? I am running Max 6 on a Mac OS X.

Now how would I add in [line] for a smooth transition between the two sensor values?

Well anyways, took me all day, but it's now running my timestamps correctly. Attached is my working version.

delaysensorvalues-4.zip
zip
keepsound's icon
Max Patch
Copy patch and select New From Clipboard in Max.

My abstraction:

keepsound's icon

Little correction in the patch. It's the - 1 operator for the day number, otherwise you get a 0 instead of the 1 (the first day of the month).

Schermata-2015-09-03-a-03.59.49.png
png
keepsound's icon

And this is the reversed patch, it creates the unix timestamp from the local time.

Max Patch
Copy patch and select New From Clipboard in Max.

`

If anyone finds any errors please let me know. Thanks

Schermata-2015-09-05-alle-16.47.29.png
png