< Back to IRCAM Forum

Live Control in CataRT

catart-mubu
#1

Has anyone had success using Live Control in CataRT?

I’m starting with the tutorial patch “catart-mubu-tutorial 3 live control.maxpat”, but even there it doesn’t seem to trigger anything as it should. What I get is the same grain repeatedly selected by mubu.knn at onsets or chop rate, depending on the segmentation method I have selected.

What I’ve looked into thus far:

  1. The difference in output between triggering a grain in MuBu.Knn via the imubu scatterplot or from the output of “p target-analysis”, which comes from a pipo desc:onseg/chop. from imubu, only the XY coordinates are sent prepended with a select message. From pipo, there’s a list of 19 floats. I ran a cycle~ object through the real-time analysis and also recorded a snippet of it and ran that through the non-real-time analysis, and I could only find 1 number that corresponded to the outputs, so not sure where to go from there.

  2. Range, it looks like there is a scaling function in mubu.knn, and I am wondering if this might be part of the problem. It defaults to off. I’ve tried setting it to minmax and meanstdev, but it doesn’t seem to help. I am wondering if I need to trigger this at a particular point in time, though.

  3. Messing with the random selection functions. If I open the radius and k values for mubu.knn, I can get a number of grains to playback, but they do not correlate to the target sounds, since they are randomly selected. This reinforces my belief that either the data being sent from p target-analysis isn’t formatted properly for mubu.knn or is out of range.

Any help on this is appreciated!

Thanks,
David

#2

Hi David, thanks for the remark, there was a mismatch in descriptors calculated between offline and live, now fixed in git. Also, the cursor now shows the live analysis, so zoom out will show you where you are.

An even better solution is in catoracle and skatart, which can calibrate to a short example of the live input. This still has to be extracted and made into a tutorial. Anyone would like to have a go?

Cheers!

#3

Thanks a million for your response! I actually just hopped on here to say that I found the getoutlabels message in a pipo help file and saw that the StdDev data was getting sent out with the descriptors. I just ran it through a [zl.slice 1] to snag the duration, [zl.delace] to get rid of the StdDev data, [zl.join] to make it one message again, and everything worked fine. That said, I’ll definitely pull the update from github to see your solution and the live analysis.

As for catoracle and skatart, I will take a look and see if I can figure it out, and also would love to try and make a tutorial if I can. In fact, I would love to see full documentation (including reference files) for CataRT and would very willing to help make that happen if you’re interested in doing that. CataRT is simply outstanding, but admittedly very complex. I’m in the process of digging through all of the nitty gritty details, and full documentation would be helpful. I’d love to see more people using the software and wonder if it would be more accessible with full documentation. I could only help with the English side of things, but let me know if you could use help with that, and we could talk it over.

And Just FYI, the “camu.pipo.descr-onseg.maxpat” has a typo in the attributes list “onset” instead of “onseg”.

Thanks again,
David

#5

You’re welcome!

We (Aaron @Einbond, Chris @cTrapani, and I) had initially hoped that the tutorials would give enough information and examples how to use catart-mubu, as it started out as a rather thin layer around just 5 mubu objects. Admittedly, to get things to work “just right”, some configuration and patching is necessary, and as this is always the same (at least for us) we started to cast it into (too) many abstractions.
I still have hopes that just a few more intermediate tutorials would be necessary, similar to the tutorials 1a–f series. I’d be curious to hear your (and everyone’s) opinion and experience where which bit of information is missing.

BTW, catart-mubu is open source, so already putting questions in a patch and sending a pull request on github would help us advance, here.

right, fixed

Cheers!

#6

I can definitely fork the project, add some questions, and create pull requests to help the project out. That said, I’m finishing up my dissertation this month, so doing that will just have to wait until the summer. :slight_smile:

In general, I would say, I am having a hard time adding my own features/manipulations to the patch without knowing EXACTLY what each object receives as a message and then sends out.

For example, I’m trying to incorporate the “normalization” feature you mentioned from the catoracle patch to the live control tutorial so that it can be included in your package. However, all of the [pipo~ desc:xxx] objects are set to output StdDev, as they were in the “live control” patch you modified for me earlier. However, in this case, it is hard to know if that is another mistake because 1) they are ALL set to do that via arguments in the object box, and 2) this one seems like it should be using the StdDev info because of the normalization patcher. Since I don’t know FOR CERTAIN that mubu.knn does or doesn’t take StdDev info in as a message, I’m tracing messages to and from every outlet in the patch to see what is going on. Whereas, if I knew for sure that mubu.knn doesn’t receive StdDev data, I could just call the “@onseg.stddev 1” and error, set it to 0, and then move on with patching.

That’s just my experience, though. I am constantly looking at the “Messages” portion of Max reference files. So that just might be me… The only other thing that I would say is some of the attributes are not self explanatory, so small descriptions of what they do would be helpful. These are the kinds of things I can throw into a pull request. I just thought that I’d give you a little info here.

Thanks again for all of your amazing work with these patches! They are outstanding. Keep an eye out for some pull requests over the summer!

Best,
David