< Back to IRCAM Forum

MuBu mosaicing question(s)

MuBu
#1

Hello forum!

Been playing with MuBu and really liking the sounds I’m getting.

I have run into a couple of issues on how to actually implement MuBu into my general patches/workflow.
What I would like to do is to record audio into a regular Max buffer~ (using karma~) and then use mubu.knn/mubu.process/mubu.granular~, like in the MuBu mosaicing example, to create granular mosaicing of real-time incoming audio.

My questions are as follows:

  1. How do I get mubu/mubu.knn to refer to an existing buffer? (Or a specific section of that buffer?)
    I’ve tried all sorts of approaches by creating a named mubu container (same name as the buffer~ I’m recording in to) and then trying to refer/point mubu/mubu.knn to it. Nothing seems to work. I did find an example (http://forumnet.ircam.fr/user-groups/mubu-for-max/forum/topic/copy-associated-buffer-example/) about copying a buffer into a mubu, but this seems like a pretty round about way to do this (using peek~ to uzi a whole buffer into a mubu).

  2. How do you get the mubu.knn that drives mubu.granular~ to work in a concat-y way where it doesn’t find a match if the incoming audio is quiet (or no nearest match is found). At the moment, as long as “enable selecting” is engaged, mubu.granular~ will stay on the same grain blasting away forever, even if there is no incoming audio at all.
    At the moment I’ve cobbled together a hack here where I’m banging individual grains out of mubu.granular~ and using onebang/delay and a randomised position to emulate positionvar/durationvar parameters. It works, but it’s not elegant.

Sorry if some of these questions have glaringly obvious answers, I’ve just been going through all the help files and testing tons of different approaches, and haven’t been able to find ways to accomplish both of the above things.

Thanks!

#2

Hi Rodrigo,

Did you look at my question from a few months back? I had the same problem. The @audio attribute can be used to refer to an existing MSP buffer.

http://forumnet.ircam.fr/user-groups/mubu-for-max/forum/topic/mubu-track-on-mubu-buffer/

Best, Hans.

#3

Hello Hans!

Yes, I did see that, but it’s quite confusing as well, given all the mubu/imubu/track/buffer(real, or buffer-in-a-mubu)/etc… terminology! Very lingo-y!

Plus, I’m not using mubu.concat at all, at the moment anyways. Just trying to get mubu.process and mubu.knn to work with what I’ve recorded into a Max buffer~. I’m using mubu.granular~ out of convenience, but it could be anything playing it back at this point.

I do have a mubu with the same name as the buffer~ I want to use, and the audio from the buffer~ does show up in the mubu (e.g. [buffer~ testing 15000] and [mubu testing] show the same audio), but when I try to get mubu.process to analyze [mubu testing] I get “mubu.process: invalid buffer index in message bang”, which is not especially verbose. I’ve tried setting different indexes, and adding/naming tracks and buffers (as in the mubu buffers) always get that same error message when I try to process [mubu testing].

I’ve also checked the mubu.process help file, which is primarily centered around processing mubu.record~ stuff, which isn’t how I want to get stuff into a buffer~ anyways.

Could you post your patch that took a Max buffer~ and used it in a concat workflow?

#4

I guess that mubu.process only works on mubu tracks and that a buffer~ inside a MUBU is only a reference to that buffer~ (see the subpatcher named (poly)buffer in the MUBU help file). MUBU developers please correct me if I am wrong. For me it is also confusing that mubu.process seems to work only on mubu tracks while mubu.granular for example works on a normal buffer~ but also on a MUBU track (if you use the @audio attribute). I am using mubu.record~ in my patches nowadays so I don’t have Rodrigos problem but if you have a lot of patches using the normal buffer~ object I can understand that you don’t want to change everything. There are quite a few externals out there that work on ‘normal’ buffers. You don’t want to go back and forth between a MUBU track and a buffer even if that has been made much easier with the copy objects.

Maybe the MUBU developers can explain a little bit of the inner workings of the MUBU externals so we don’t start to look for solutions that are not there… It would help if there was some text in the data format part of the mubu help patch describing the difference between buffer~ and a mubu audio track and where they are related or can both be used by the same objects. It is there but intuitively you expect something different. The problem that Rodrigo describes is very similar to my own first encounters with MUBU. MUBU is great but in order to get a larger user group it should be a little less confusing and more accessible. Most of my students are less patient then I am and they don’t use it because of the complexity, which is a pity because they miss out on some great sounding externals. Would be better for my ears as well ;-).

FTM and Gabor are not easy either but as far as consistency goes they are easier for me. Especially when coming back to my patches after a while it is easier to pick up on FTM and Gabor then with MUBU. The original idea was to increase the accessibility I thought…

Sorry for the critical note developers. I admire your diligence work on these (free) audio tools from IRCAM. I only hope for a bigger user group because the work you put into this deserves it.

Best, Hans.

#5

Hi Hans and Rodrigo,

using mubu.process on audio in a buffer~ is not possible right now, but very, very high on the TODO list.

Cheers…
…Diemo

#6

@Diemo
Is it not possible to get the contents of a (Max) buffer~ fully into a mubu buffer (in order to mubu.process it)?

@Hans
That could be it, that it’s just a pointer to the buffer, and not actually IN the mubu buffer.

For my part, I only really looked at CataRT with the mubu version as it meant I could incorporate it into what I was doing without taking on the massive dependency on FTM/Gabor. The last version of CataRT I looked at was FTM-y head-to-toe pretty much, whereas the mubu-based version is still Max-y, just using the mubu externals for the actual heavy lifting.

It’s definitely not straight forward to get in to, even coming from a pretty technical place. I decided to start with straight mosaicing, as it has the least amount of ‘moving parts’, and still haven’t been able to figure out how to do things yet (though it looks like what I was trying to do may not be immediately possible).

I guess I can try writing the part of the buffer~ I want to use to a file, and then read that into a mubu, but it seems a really round about way to do that.

#7

Hi Rodrigo!

I’m sorry I just caught up on this thread. A couple of suggestions:

At the moment that you record your buffer, you could simultaneously record it with mubu.record~, which will make it accessible for mubu. Then depending on how you set your mubu.process you can get an immediate segmentation and analysis or defer it.

Then I would try mubu.concat instead of mubu.granular. Check out Diemo’s subpatch [p trigger-mode] in catart-by-mubu for a nice explanation of the different triggering parameters. It sounds like what you might want, based your original question, is “fence,” which corresponds to “play 0, allowrepeatmarkers 0”

These objects are integrated into some more involved patches in catart-mubu-live and catoracle – in particular you can find mubu.record~ in the subpatch [p target-analysis].

Happy concatenating!
Aaron

#8

@Aaron
I thought about using mubu.record~, but I often do varispeed recording (via karma~), which means that it wouldn’t be possible to record the same thing into both buffers consistently. The immediate segmentation of mubu.record~ is quite attractive though.

I’ll have a closer look at mubu.concat too.

In the end I’m looking to do two kinds of concat-ing. One is really fast/smeary mosaicing on the contents of a (small) buffer~, and then a more robust implementation using proper corpora, both of them being driven by audio input.

#9

I stumbled on the same problem today. The help patcher for mubu.process (in MuBu 1.9.9) indicates: The mubu name should be the same as the buffer~ name and the name of the audio track referenced by mubu.process should be the literal “[audio]” (without quotes).