Group Admins

  • Profile picture of Norbert Schnell

Group Mods

  • Profile picture of Frederic Bevilacqua
  • Profile picture of schwarz
  • Profile picture of borghesi

MuBu for Max

Public Group active 1 day, 21 hours ago

MuBu for Max user group.

tracks disappear from imubu when numbuffers message is sent

Author 2 Subscribed Users |
Profile photo of tothesun

I just started messing around with mubu, so i may be missing something, but but it seems very difficult to keep my track in the imubu when i try to set the number of buffers. The number of buffers updates, but at the same time the track itself is removed and so any data i try to record isn’t visible. In the view section of the inspector it changes to 0 where it used to say the name of the track. Any help?

My patch right now is just the slightly modified help file:

— Pasted Max Patch, click to expand. —
April 4, 2016 at 21:50 #17621
Profile photo of jlarralde


When I run your patch, if I send “numbuffers 3″ as a message to the imubu object, the contents of your “data” track remains and new empty buffers are added.
One thing that may confuse you is that by default the bufferchooser (small tabs allowing to toggle view between buffers) is hidden in imubu.
Try enabling the “Buffer Chooser Visible” toggle in the section “05-BufferChooser” of the imubu object’s inspector, and you will be able to see how many buffers you have and which one is currently displayed.
And also, please notice that even if you record a gesture in buffer n > m, and you have only m buffers, the gesture will be recorded in buffer m.
So you have to be careful to record into a buffer that already exists, otherwise things will become inconsistent.
You can create buffers on the fly, but always before recording into (which seems obvious).
As an alternative to the “numbuffers n” message, you can also use the “addbuffer” message.
Hope the bufferchooser trick will help you better understand what’s happening.


April 5, 2016 at 10:19 #17628
Profile photo of tothesun

Thanks for the tips. It turned out i had an errant numbuffers 0 message coming through just prior to the right one. Still can’t get anything to show up when i record though. Maybe the parameters on the mubu.record aren’t right for my kind of data (25 bark coefficients coming in at regular intervals)? I got rid of @samplerate and @maxsize; should that allow it record every reading it receives?

April 6, 2016 at 04:27 #17632
Profile photo of jlarralde

Sorry for the delay.
Maybe you figured out how to solve your issue …
Anyway, I think samplerate and maxsize are not the problem (and maybe removing them may arise other problems).
Probably you should tell mubu.record how many columns and rows the incoming matrices have.
To do this, use the @matrixcols and / or @matrixrows attributes depending on the format you wish to record.

April 11, 2016 at 10:37 #17678
Profile photo of tothesun

No worries and thanks for the help. I haven’t figured it out yet. I wish there was better documentation on the different attributes. The documentation link in the help file doesn’t seem to go anywhere.

If my input is lists of 25 floats (not a jitter matrix or anything), would I want @matrixcols or @matrixrows set to 25? I assume then I would want the other one to just be 1? I’ve already tried all the different combinations however and no dice.

What about @maxsize; if it’s at 1000, I assume that’s in ms, but what if some of the things I’m trying to record are longer than 1000 ms? What I mean is, what if I can’t determine beforehand what a max size would be?

What if my sample data is already coming at a steady rate? Can I get it to just accept everything it sees? I’m worried that if I set a specific rate with @samplerate I will either get duplicates or a more sparse data set than I might otherwise be able to.

  • This reply was modified 2 years, 11 months ago by Profile photo of tothesun tothesun.
April 13, 2016 at 04:51 #17694
Profile photo of jlarralde


This is weird that setting @matrixcols and @matrixrows attributes don’t solve your problem …
The row or column-wise order depends on what you want to do with the track (with mubu.process for example), but this is not a big deal to exchange them.
Could you post another example patch ?
In the first patch you posted, I have the feeling that you try to give the whole list at once to the mubu.record.
You should try to use zl iter to chunk the big list into vectors/matrices of the desired size because mubu.record won’t do it for you, it will just take the n first elements corresponding to matrixcols * matrixrows and throw away the extra elements of the input list. So you will end up with a track of length 1.

Concerning the @maxsize attribute, it’s in samples so the actual max duration also depends on your samplerate (set with @samplerate attribute).
You have no choice but to determine the maxsize before writing into your track.

Concerning your worries about getting duplicates or missing samples when specifying a particular samplerate, don’t worry, the samplerate is just an information allowing the track to know its duration. Each incoming sample will be recorded once and will have no duplicates. There is no internal scheduler in mubu.record.

Hope this helps.

April 20, 2016 at 14:17 #17748
Profile photo of tothesun

Ah! I’m a silly fool. I believe i have it working now. I had assumed that the help file was sending the input THROUGH the multislider and that was how i set up mine as well. Little did i realize the multislider was a dead end and wasn’t even connected to the mubu.record!

Anyway, thanks for your help nonetheless.

April 22, 2016 at 01:58 #17802

You must be logged in to reply to this topic.

Log in now