< Back to IRCAM Forum

Get sum/mean of a track by segment

MuBu
#1

Hello MuBu team.

First of all, I’m a new user of MuBu and it is completely blowing my mind. Very excited to use these tools in all my projects.

I’m wondering if there’s an easy way to get the sum, max or mean of track values based on the segments of a markers track. Like if I wanted to get the average fundamental frequency in each segment.

I’m sure it could be done by dumping out the matrixes of each segment individually then calculating them outside of MuBu, but maybe there’s an easier way?

Thanks for this amazing resource!

#2

Revisiting this post to see if anyone can be of any help.

Is there a recommended way in MUBU to calculate values between different tracks on a given buffer?

To expand on my previous post, I have audio, YIN and markers tracks. I’d like to perform calculations on the YIN data stored within each segment on the markers track. I would then like to save that calculation (like the average periodicity that occurred within that segment, or the pitch classes of all the frequencies that occurred in that segment) as a new attribute on the markers track.

Can anyone help walk me through a solution? I’m attempting it using uzi’s to iterate over the data, then storing it in outside collections, but I feel like I should be able to do this with all MUBU objects.

thanks!

#3

Hello James,

Great to hear you find the library useful !

We plan to add new objects to allow this kind of things but for the moment we use an abstraction based on MuBu objects as a workaround.
As you might have noticed, you can only perform stats on the data you use to compute the segmentation itself, or compute stats on a full track with getmeans etc messages.
The abstraction uses this latter feature with a hidden temporary MuBu inside.
It’s not in the official release, but here it is with a little help file.

Hope this helps,
Joseph

markerstats.zip (8.37 KB)

#4

Thanks Joseph, this looks promising!

Could you clarify what the data in the stats track represents?

I’m having a hard time understanding what is being derived from the YIN and marker tracks to result in the stats track.

Could you point me to where in this mubu.stats abstraction I can add my own custom logic for processing the YIN data on a per-segment basis.

Much appreciated
James

#5

Hi James,

There’s an embedded [mubu.track] object in the abstraction which takes the name you provide as the 3rd argument.
This new generated track contains the same markers as the marker track you give the name as the second argument,
and each of its markers contains the stats you ask in the message as demonstrated in the help file.
It also works on a multi-column source track (such as a yin track which has 4 columns), but not in a multi-row one.
If you compute stats on such a track, let’s say you instantiate a [mubu.stats.marker.track yin seg yinseg] and you send it the message “mean stddev”,
your yinseg track will be filled with 8 columns segments (matching the timetags of the seg track’s segments), corresponding to “Frequency_mean Frequency_stddev Energy_mean Energy_stddev Periodicity_mean Periodicity_stddev AC1_mean AC1_stddev”, these stats being computed on each segment of the yin track.
It will also work with a mfcc track for example (which has 12 columns by default).

So if you want to use the YIN data on a per-segment basis you should refer to the embedded track from another [mubu.track] object.
The abstraction is a warper for [mubu.track].
It can actually be seen as a new track you create as a recipient for a mix of two other tracks, and you can refer to from other [mubu.track] objects.

Happy patching,
Joseph

#6

This is great, exactly what I was looking for.

I’m having trouble using other mubu.track objects in my patch outisde of your abstraction.

I see that the track is getting dynamically named inside your abstraction, but is there any reason why I wouldn’t be able to make other objects such as [mubu.track yinstats stats]?

When I create it and try to get track info, it doesn’t output anything.

I edited your abstraction and tried sending it the same messages from within the abstraction and that worked. Some namespacing issue maybe?

Anyway, thanks for the abstraction!

#7

Hi James,

You’re right, I have exactly the same behaviour here.
I just found what is happening : the readappend message is creating a new buffer when the mubu has predefined tracks (which is the case here because the abstraction needs a predefined track to store the results into).
If you send the message “bufferindex 2” to your mubu.track you will be able to access the data in the right buffer.
It’s not obvious with imubu because it focuses on the last added buffer, but you can see that it automatically switches to the new buffer (2) if you enable the bufferchooser_visible attribute of imubu.
There are several possible workarounds to avoid this empty first buffer behaviour : either use “read” instead of “readappend” so that the sound is loaded in the current buffer (1 when mubu is empty), or use a “clear, readappend somesound.aif @name audio” message combination so that just after clear, the mubu can create the first buffer before checking if it has predefined tracks.

FYI, you can now download the new version of MuBu (1.8.10) on IRCAM’s forumnet.
It has been released today, and integrates the abstraction and its updated help file, as well as new doc patches and some bug fixes.
Hope you will enjoy it.

Best,
Joseph