jamesson

I saw oscrec, but it's a little... overspecified. Anybody do a patch like this?

record-osc

or something I put together awhile back, which gives many more playback options:

https://cycling74.com/forums/sharing-alternative-to-mtr-for-automation

and there's GestureRecord as Andrew mentions in that thread as well.

Lots of fun options... you should be able to modify any of these to suit.

and there's GestureRecord as Andrew mentions in that thread as well. 

Lots of fun options... you should be able to modify any of these to suit.


interesting... why must they use jitter, do you think?

You don't have to use Jitter, but from reading that forum thread there's some really cool ideas there that I'll have to check out sometime.

A really simple way to record OSC is to use a coll object.

Here is a patch I created to record gesture data from my Kinect, it's very simple, and I'm sure there are other ways of doing it, but this works for me!

Chrisconnor: I salute your leet commenting skills sir. One of my pet peeves here is that people forget that merely posting a solution is not as good as helping us understand it.

No problem jamesson, 2 mins of my time is worth saving you 15 mins of trying to figure out what's going on.

jitter was useful in that respect because

1) jit.qt.movie is ready to go, with any resolution you want, and has all the playback options like rate, direction, etc.

2) you can store tons and tons and tons of data easily in a .mov file.

3) it's a jitter matrix, so there's any and all effects you want, if you want to play with the recording after you have it ;)

try things like jit.slide for smoothing, jit.rota for "mirroring" the values, jit.op for...well, just about anything. Super-simple to do things like swap across X or Y, quantize values, blend multiple recordings, etc.

You could also store the values into buffer~ objects using audio signals and [peek~], but AFAIK you have to specify the buffer size beforehand. With jit.qt.movie you don't. Now that I think of it, you could use sfrecord~ too, which doesn't require a length specification either.

If you use MSP, once you have your audio recorded and in buffers~, you could of course have a whole DIFFERENT set of fun ways to mangle it. hmm...I wonder how your gesture recording would play back differently if it was transposed up a tritone and run through a low-pass filter? What about tapin~/tapout~?? Echoes of your gestures...holy moly, I've gotta try that...

So, if you don't have jitter, you have workarounds in MSP. Of course, you could go MIDI with [seq] or [detonate], or use [mtr], [coll], etc...I just love the flexibility you get with the matrix objects, and it's really easy to record many streams at once. But now I think I want to try MSP playback with delays...that would be awesome. No sleep tonight!

1) jit.qt.movie is ready to go, with any resolution you want, and has all the playback options like rate, direction, etc.
2) you can store tons and tons and tons of data easily in a .mov file.
3) it's a jitter matrix, so there's any and all effects you want, if you want to play with the recording after you have it  ;)  

You could also store the values into buffer~ objects using audio signals and [peek~], but AFAIK you have to specify the buffer size beforehand. With jit.qt.movie you don't. Now that I think of it, you could use sfrecord~ too, which doesn't require a length specification either. 

So, if you don't have jitter, you have workarounds in MSP. Of course, you could go MIDI with [seq] or [detonate], or use [mtr], [coll], etc...I just love the flexibility you get with the matrix objects, and it's really easy to record many streams at once. But now I think I want to try MSP playback with delays...that would be awesome. No sleep tonight!


ok, so a quick update, I have a rough patch which records gestures into buffer~ (just the X and Y of a pictslider). Works fine once you get the settings right for playback (very very slow sig~ because you're recording sample-by-sample). Cool stuff and works great.

I then tried the tapin~ and tapout~ but it's not really what I was thinking. The "echoes" work fine, but of course they override the current values. So the result is totally stuttery. Makes perfect sense now that I think of it though. I suppose you could split off the echoes to control a different output gesture or gestures, that would be interesting.

There are some great possibilities---use [waveform~] and you can loop certain parts that you want to repeat, granularize the gestures, etc. That way it's a lot more visual for selecting what you want. And you can always fill the buffers~ with sine waves or other functions, to get a smooth "carrier" to start with, or use LFO's to give your gestures "modulation". So a big sweeping motion with your arm becomes one with little wavelets in it. Plenty of fun to be had with some experimenting...!

i've made a graphical recorder/editor with tracks and timeline

play with spacebar, rewind with left arrow, move cursor on the tracks

edit function (E key or check toggle) or record in tracks

use record.maxpat for send and receive from tracks

there is only 3 tracks in this version, but it's possible to add more manually in groupe-func.maxpat

Any returns appreciated, i still work on it

hello,
i've made a graphical recorder/editor with tracks and timeline

launch FUNC.maxpat
play with spacebar, rewind with left arrow, move cursor on the tracks
change zoom, down arrow for zoom out
edit function (E key or check toggle) or record in tracks
save with testsauve

Any returns appreciated, i still work on it
bye


I had created free OSC recorder/editor KuStudio, as a separate app (OSX/Windows), for synchronizing timeline and audiotrack: 

https://sourceforge.net/projects/kustudio/

It's robust when working with long audiotracks, and we use it in our live performances/shows.

I had created free OSC recorder/editor KuStudio, as a separate app (OSX/Windows), for synchronizing timeline and audiotrack:  https://sourceforge.net/projects/kustudio/
It's robust when working with long audiotracks, and we use it in our live performances/shows.


Thank you so much for your great information, It is too useful for me.

I should record everything that is received via OSC on port 8010 of my pc in local host and then, once the recording is stopped, I should save this data directly in a text file. How can I do this?

Thanks in advance to everyone for your help!

Hi guys!
I should record everything that is received via OSC on port 8010 of my pc in local host and then, once the recording is stopped, I should save this data directly in a text file. How can I do this?

Matteo, you can use the mubu package and record to a mubu container. This allows for nice visualisation as the recording is made. Once you have everything recorded it normally saves all tracks to a single binary file, but from the container itself you can export each track as a text file.

Main downside of using mubu is that you need to specify the size of the buffer you will be writing to. So basically you need to estimate how many seconds/minutes or hours you will be recording

Wow!
This old thread brings back memories :)
Matteo, you can use the mubu package and record to a mubu container. This allows for nice visualisation as the recording is made. Once you have everything recorded it normally saves all tracks to a single binary file, but from the container itself you can export each track as a text file.
Main downside of using mubu is that you need to specify the size of the buffer you will be writing to. So basically you need to estimate how many seconds/minutes or hours you will be recording

Patch-memories hahahha... Anyway, thanks a lot for your help Zancudo!

Basically you mean I still have to use udpreceive and its "route" objects, then make a "pack" and put them into MuBu? As I have never used MuBu I wanted to ask you more about how to do this.

The recordings will be up to 45 minutes long and I will have to sometimes stop the recording and sometimes restart it because I will not always need it to record OSC data.

Patch-memories hahahha... Anyway, thanks a lot for your help Zancudo!
Basically you mean I still have to use udpreceive and its "route" objects, then make a "pack" and put them into MuBu? As I have never used MuBu I wanted to ask you more about how to do this.
The recordings will be up to 45 minutes long and I will have to sometimes stop the recording and sometimes restart it because I will not always need it to record OSC data.
Thanks in advance! 

Please see the attached patch which might seem complex and send you in a different direction. This is my understanding of how mubu works and maybe some of the regular Ircam members can share a more straight forward way. This is what I've understood of the help files etc.

Yes, you would need to get your OSC from [udpreceive]. From here you would only need to pack the streams if you want everything into a single text file which by default are space-separeted values. Otherwise you can write different tracks to different independent files.

Hi Matteo,
Please see the attached patch which might seem complex and send you in a different direction. This is my understanding of how mubu works and maybe some of the regular Ircam members can share a more straight forward way. This is what I've understood of the help files etc.
Yes, you would need to get your OSC from [udpreceive]. From here you would only need to pack the streams if you want everything into a single text file which by default are space-separeted values. Otherwise you can write different tracks to different independent files. 

Thank you very much for your help Zancudo!

test_recOSCMMRL.maxpat

Do you think I'm doing something wrong? If I want to have separate txt files, I simply don't use the pack object, but make 4 different "MyRecorders" I understand. Thanks in advance for the help!

Thank you very much for your help Zancudo!
I have set up the patch in this way


Do you think I'm doing something wrong? If I want to have separate txt files, I simply don't use the pack object, but make 4 different "MyRecorders" I understand. Thanks in advance for the help!

Thank you very much for your help Zancudo.

Do you think I'm doing something wrong?If I want to have separate txt files, I simply don't use the pack, but make 4 different MyRecorders I understand.

Thank you very much for your help Zancudo.
I have set up the patch in this way:



Do you think I'm doing something wrong?If I want to have separate txt files, I simply don't use the pack, but make 4 different MyRecorders I understand.
Thanks in advance!

You are correct. Separate text files you don't use pack and do 4 different [mubu.record] pointing to individual tracks.

your patch looks correct to me but since you mention that you want the time reference there are arguments for [mubu.record] like '@time tagged yes'.

I did a quick test but this is not working for me at the moment. 

I vaguely remember having this worked out at some point, but to be honest it's been a while since I've delved into the details of mubu. But I do have patches for recording sensor data that have been runing for years in older computers which are 'good enough' for what I needed at the time.

Not sure if I've just forgotten the details or if there have been changes in recent (last couple of years) in the mubu package. If I were in your position, I would take a 2-pronged approach:

1.- You can generate your own time stamp using [metro] and [counter] and have that be your leftmost input to [pack i f f f f]. (not sure why you specified 50 columns but you do you :) This would mean that you are only sampling at the SR you specify in metro. This might mean that some values are lost if they are faster than your metro interval and you'd get repeated values if the OSC streams arrive at a lower SR. This compromise might be or not be important depending on the level of accurracy that you need but is a quick solution.

2.- Create a separate post on the forum asking specifically about the timetagg attribute in mubu so that the Ircam members might pick it up and provide a better solution to your specific use case.

I would go with both. First the DIY No. 1 to get something working quickly, and see if the Ircam lads can make a better suggestion.

I am mostly self taught in Max and constantly jump between getting good enough results to get the task at hand work but also inquiring about the 'correct' way of doing things.

I have deep respect for all the great objects we get for free from Ircam but often find that there are gaps in my understanding of how exactly they work and how to make the best use of them. Diemo and the gang are great at answering direct questions so they might have better solutions. 

Hope this is helpful for you and look forward to answers you might get if you use option 2. I might learn something myself :)

Hi Matteo,
You are correct. Separate text files you don't use pack and do 4 different [mubu.record] pointing to individual tracks.
your patch looks correct to me but since you mention that you want the time reference there are arguments for [mubu.record] like '@time tagged yes'.
I did a quick test but this is not working for me at the moment. 
I vaguely remember having this worked out at some point, but to be honest it's been a while since I've delved into the details of mubu. But I do have patches for recording sensor data that have been runing for years in older computers which are 'good enough' for what I needed at the time.

Not sure if I've just forgotten the details or if there have been changes in recent (last couple of years) in the mubu package. If I were in your position, I would take a 2-pronged approach:

1.-  You can generate your own time stamp using [metro] and [counter] and have that be your leftmost input to [pack i f f f f]. (not sure why you specified 50 columns but you do you :) This would mean that you are only sampling at the SR you specify in metro. This might mean that some values are lost if they are faster than your metro interval and you'd get repeated values if the OSC streams arrive at a lower SR.  This compromise might be or not be important depending on the level of accurracy that you need but is a quick solution.

I would go with both. First the DIY No. 1 to get something working quickly, and see if the Ircam lads can make a better suggestion.

I am mostly self taught in Max and constantly jump between getting good enough results to get the task at hand work but also inquiring about the 'correct' way of doing things. 

I have deep respect for all the great objects we get for free from Ircam but often find that there are gaps in my understanding of how exactly they work and how to make the best use of them. Diemo and the gang are great at answering direct questions so they might have better solutions. 

Hope this is helpful for you and look forward to answers you might get if you use option 2. I might learn something myself :)

Thank you very much for your prompt feedback.

I will do just as you suggested. Regarding the SR there should be no problem because I can specify in the device how many ms it should send me the OSC data and currently it sends me every 100ms so I set the [metro] with the value of 100.

I had misunderstood the [matrixcols] parameter :D 

I have now set it to 2 as I need the time in one column and the values in the other. I'll try to test it over the weekend and update you.

In the meantime I will check if '@time tagged yes' works and if it doesn't, I will open a new post on the forum to ask directly. Thanks again and have a great weekend Zancudo!

I had misunderstood the [matrixcols] parameter :D 
I have now set it to 2 as I need the time in one column and the values in the other. I'll try to test it over the weekend and update you.
In the meantime I will check if '@time tagged yes' works and if it doesn't, I will open a new post on the forum to ask directly. Thanks again and have a great weekend Zancudo!

you need to count each stream. 1 for the time tag and 1 for each stream. So base on your qxyz you need 5.

One for the time tag and 1 for each data stream.

Wee word of advice.
Don't set it to 2.
you need to count each stream. 1 for the time tag and 1 for each stream. So base on your qxyz you need 5.
One for the time tag and 1 for each data stream.

Yes, yes, in fact now I was reading well the attributes of MuBu and I realized that 2 was not good...thanks a lot again! By the way, I was seeing that instead of [metro] and [counter] I could also use [clocker] directly.

I tried the patch with the external device and everything works inside MuBu. 

I only have a problem regarding the export. How do I export the .txt file ?

I also tried to look well at MuBu but I didn't come to a solution. I tried to add "writetrack qwxyz data.txt" and nothing comes out while if I write "writetrack qwxyz.txt" the console gives me error. 

Did you managed to export to txt? Thanks in advance and have a good day :)

I tried the patch with the external device and everything works inside MuBu. 
I only have a problem regarding the export. How do I export the .txt file ?
I also tried to look well at MuBu but I didn't come to a solution. I tried to add "writetrack qwxyz data.txt" and nothing comes out while if I write "writetrack qwxyz.txt" the console gives me error. 
Did you managed to export to txt? Thanks in advance and have a good day :)

Got a notification to my email but the post seems to be missing here in the forum. In any case, the message I got from you was:

"writetrack qwxyz data.txt" is the correct syntax. Now, if nothing happened (no error message) then it is likely that something did happen but not what you wanted. Search for "data.txt" file and you might find it somewhere else in your folder tree.

Since a few versions of Max, when you save a file from a patch it does not place it where the patch is located. Instead, it saves to the last folder you saved anything from Max. So if you creatred files for a different project, your 'data.txt' file might be there.

I don't know if this is a Max issue or an OSX issue but it is quite frustrating. The way I solve it is by generating the full path to my top level folder sending "path" message to [thisfolder] then using [combine] to parse things up. Your final message to [mubu] then should look something like:

"writetrack qwxyz /Users/Matteo/whereverYourTopPatchLives/data.txt"

I don't know if this is necessary on windows but it should be compatible even if not necessary

Hi Matteo,
Got a notification to my email but the post seems to be missing here in the forum. In any case, the message I got from you was:

I tried the patch with the external device and everything works inside MuBu. I only have a problem regarding the export. How do I export the .txt file ? I also tried to look well at MuBu but I didn't come to a solution. I tried to add "writetrack qwxyz data.txt" and nothing comes out while if I write "writetrack qwxyz.txt" the console gives me error. Did you managed to export to txt? Thanks in advance and have a good day :)

"writetrack qwxyz data.txt" is the correct syntax. Now, if nothing happened (no error message) then it is likely that something did happen but not what you wanted.  Search for "data.txt" file and you might find it somewhere else in your folder tree.

Since a few versions of Max, when you save a file from a patch it does not place it where the patch is located. Instead, it saves to the last folder you saved anything from Max. So if you creatred files for a different project, your 'data.txt' file might be there. 

I don't know if this is a Max issue or an OSX issue but it is quite frustrating. The way I solve it is by generating the full path to my top level folder sending  "path" message to [thisfolder] then using [combine] to parse things up. Your final message to [mubu] then should look something like:
"writetrack qwxyz /Users/Matteo/whereverYourTopPatchLives/data.txt"

I had deleted the message because then I had solved it.

Anyway, thank you very much again for your help!

Just click on "name.txt" as a message and the text file is saved correctly in the same folder of the patch.

It would be interesting if it possible to save the values as csv file, but in any case with the analysis-tools there should be no problems with txt files either. Anyway, everything is working correctly!

I had deleted the message because then I had solved it.
Anyway, thank you very much again for your help!
Just click on "name.txt" as a message and the text file is saved correctly in the same folder of the patch.
It would be interesting if it possible to save the values as csv file, but in any case with the analysis-tools there should be no problems with txt files either. Anyway, everything is working correctly!
Have a good week! :)

record osc