< Back to IRCAM Forum

MuBu feature requests

MuBu
#1

Hi Hans,

Thanks a lot for these precious comments.

(I wish I’d now how to transform your reply to this topic into two new topics “MuBu Feature Requests” and " “MuBu Bugs”…)

Anyway, here are some thoughts in reply:

Onset detection will be implemented in pipo I understood and I can hardly wait to use it.

Is there an indication when it will be implemented?

Yes, me neither and we’ll try to be quick with this (rather weeks than months).

Would it be possible to implement ring recording? Like in superVP.ring or like you can use gbr.dline~.

Or is there a nice trick to do this?

Yes! This one is on the top of the features-to-be-implemented list, but I am afraid that it won’t be for next week either.

I am not aware of a trick.

Everything is prepared to do so inside of the container, but there is some code to adapt in the visualizers and synth.

What would be your first scenario?

Related to this. Is there an append mode for mubu.record~ like there is for the normal record~? I did not see it.

There isn’t, but I guess there should be one, right?

Thanks for the feature request.

And also related. Is it possible to delete a portion of the recorded buffer (Preferably with the portion of the associated tracks containing processed data)?

Yes, there are actually some messages missing to treat all tracks of a given buffer together.

I’d like to propose for that a message “select” with some follow-up messages acting on a selection like “crop”, “delete”, “copy”, and “cut”.

The same messages could of course also work for single tracks.

All of the above would be easier for people themselves to implement if communication between MUBU and FTM could be more easy. It would be really nice if something like ftm.jitter which can be used to go back and forth between FTM and jitter could be there as well for MUBU matrices and FTM matrices. But maybe I missed something here as well.

There is really nothing bad about using the “get” message to mubu.track to output a list and construct an FTM fmat by inputting this list into an “ftm.copy fmat”. Even the performance should be actually pretty decent (you’ll tell me?).

and a bug report:

When removing the last existing buffer from an imubu MAX will crash (MAX6, mubu.process help patch)

Oops, thanks, actually it even shouldn’t be possible to remove the last buffer of a MuBu container (which is really not always great, but I don’t know how to get rid of it without being incompatible with too many existing patches).

And a question:

Is there a pdf or WEBpage with a description of all methods of the MUBU objects or is everything only documented in the help patches? I found only this: http://imtr.ircam.fr/imtr/images/Mubu.maxref.pdf

There should be a button “Documentation” on the MuBu page (apparently only in english) that leads you to a page where you can find this link with a PDF that summarizes the latest MuBu Max reference pages. As soon as we’re able to generate ref pages for Max 6, they’ll be back in the help patches too.

http://forumnet.ircam.fr/wp-content/uploads/2012/10/MuBu-for-Max-Reference.pdf

Cheers

Norbert

#2

Dear Norbert,

Thanks for taking these comments so seriously.

About the scenario for a ring buffer recording is to be able to let the buffer follow along while playing and then freeze the situation (of the last 3 to 10 seconds or so) at a convenient moment. It is the way I mostly work (also with superVP.ring). It would also imply that I can use both MUBU and superVP in the same way and that is easier for my brain…

Looking forward to the update!!!

Thanks, Hans.

#3

Dear Norbert,

Any indication on a new update of MUBU with the afore mentioned features? I am on the verge of starting a new update of my patches and it would be nice to implement it.

Best, Hans.

#4

Well, all this will come little by little.

We’ll try to have a first ring buffer mode in spring.

N.

#5

Dear Norbert and team,

Sorry to pry. Just for my planning. When do you intend to release the next version of MUBU? And will it feature a ring-buffer mode?

Best, Hans.

#6

Hi Hans,

We are currently testing the version 1.6.6 internally and should be ready for a new release next week.

Unfortunately, we didn’t advance on the development of the ring-buffer mode, but there are at least some new ideas to speed this a little bit up that I would like also discuss with you.

Imagine, that we would introduce a very first notion of ring-buffer into mubu.record~ and a function (message) that at a certain point would copy the content of the ring-buffer track into a straight track without causing troubles in the scheduling. In the copied straight track you than could apply analysis with mubu.process and synthesis with mubu.concat~, etc.

This way of handling the problem should give us the possibility to explore at least some of the things that one can do with ring-buffers without that we have to change thousands of lines of code right away. In case that you don’t care so much on the temporal continuity of the of the recorded sound you also can apply the analysis/synthesis directly to the ring-buffer (in which case we also can take care that there is aways a minimum of silence behind the last recorded frame).

Please don’t hesitate to discuss this further and especially to share more concrete ideas of what you would like to do with ring-buffers.

Best

Norbert