< Back to IRCAM Forum

Mubu write to file: bugs & suggested improvement

MuBu
#1

Hello,

I would like to report some bugs and suggest some improvements with the saving workflow of mubu (tested with imubu object).

  1. only “writeall” saves all the structure of the mubu object correctly (buffer names, tracks…).
  2. it would be very nice to save buffer names and tracks inside a mubu file when using writealltracks instead of just getting the .txt file with raw data
  3. in my tests, “writeall @buffer X” does indeed save the data of the buffer X but the name of the buffer is saved as the name of the buffer 1 instead of buffer X in the file
  4. i think I saw the same behavior with writetracks, ie that buffer names and labels were not saved accurately in the files
#2

It would also be nice to have a clearer documentation on the subject. Indeed, some attributes that are shown in the main write/read tabs are specific to certain file formats, in other occasions, the attribute is not named correctly (for instance, bufferid instead of buffer…).

The difference between read, readall, readappend, readtrackappend… and their behavior could be detailled much more, so I suggest the following approach:

For each data type (txt, mubu…):
For each command (read, readappend…):
Detail the structure of the command and its valid attributes/arguments

In the general level: show only attributes that are shared in all commands/data types

Finally, I struggle making what I thought would be a simple action.

I have my data structured as following:
./data
/track_name (corresponds to the input name)
/buffer_name + unique_id (.mubu or .txt)

When I am loading my buffer file (corresponding to one track only), I would like mubu to add the corresponding buffer name and add the track if it did not exist already. I would also like mubu to be able to merge two files that have complementary track information (ie, files corresponding to the same buffer but a different track).

I unfortunately wasnt able to perform this using built in methods.

#3

Here is an important bug:

when using

writeall <filename .mubu> @buffer

the buffer is saved correctly but named and labeled as the first buffer in the mubu obj.

#4

Hi Aparment, thanks for your feedback.
Point 3. is indeed a bug, we’ll look into it.
For 2., you could check the .json output, which keeps all metadata and structure and is still text. BTW, .mubu files are in SDIF format.
What do you mean by “merge two files that have complementary track information”?
Best regards

#5

Thanks for your answer!

I’ll definitively check the .json output.

by “merge two files that have complementary track information”, I meant the following:

  • imagine that I have saved track1 of buffer1 into file1 and track2 of buffer1 into file2
  • then I would like that when loading file1 and file2, the buffer1 gets fully reconstructed with track1 and track2
  • either by loading the metadata from the file (track name, buffer name…) or by allowing to mention the track and buffer name as a command, whatever the file type is and the loading mechanism is.
#6

Hello!

I found an other bug with Mubu.

The situation:

1° I create a track in the Mubu object
2° I remove all buffers (if any) from the Mubu object with the following node.js code

async function clearbuffers() {

await update_buffers_and_tracks();

p("Clearing buffers");

for(var i = mubu_buffers.length; i>0; i--) { // here we decrease
	
	p("Removing buffer " + i);
	o(["to_imubu", "removebuffer", i]);
}

// WARNING: a buffer "1" is automatically created by mubu }

3° Although the track still appears in the Imubu object and never was deleted, Mubu says that is does not exists (hastrack returns 0 and mubu.record says it can’t connect)

SO I don’t know why would deleting all buffers also remove my track… yet it happens!

#7

TO be even more precise, if I delete all but the first buffer, the problem does not appear.
I think there’s something wrong with Mubu not accepting having zero buffers…

#9

ad 2, as Ricardo @Borghesi already answered, mubu always having 1 buffer is a feature, not a bug.
ad 3, that seems to be a missing refresh of the editor, if you reopen it, or send printall to mubu you see it is gone.
Cheers!

#10

Sorry, I think I did not make my message clear (“Although the track still appears in the Imubu object and never was deleted, Mubu says that is does not exists (hastrack returns 0 and mubu.record says it can’t connect”)

Here I meant that

  • may aim is to delete only the buffers
  • the result is that if I delete all buffers (including the buffer 1) one or several tracks are also deleted (which is not the expected behavior)
  • as a workaround I never delete the buffer 1