< Back to IRCAM Forum

Mixing/Sync playing tracks using mubu.play & mubu.track

MuBu
#1

Hi there,

working hard on the prototype (related to this post), I need some help with that.

I decided to use sample message with mubu.track for interpolating. Works perfectly.
But I also have tracks used with markers (I mean unidimensional data) for which I don’t want any interpolation, just sporadic messages when the “cursor” pass on events.

Is there a way to merge both method one for continuous data and the other one for markers ?

I could always filter by using comparators with a mubu.track reading markers too but I feel it very unefficient.

#2

great to hear you’re making progress!
Just use mubu.play for the markers.

1 Like
#3

Hi @schwarz, thanks for your answer.
Actually, I want to have only one master clock.
mubu.track + sample message for interpolation is the way to go as you have suggested and it is driven by one phasor~. The master and unique single one here.

How can I sync a mubu.play with a phasor ?

#4

if the master time is linear (no speed change, jump) then I’m pretty confident that mubu.play would stay in sync.

If not, you could either

  1. slave mubu.play to the phasor time t in short intervals corresponding to your snapshot period p via play 1 t (t+p) (or have a slightly less frequent snapshot~ for the markers, every p = 100ms, say)
  2. use getnextindex or getfloatindex and gettime to mubu.track to know the time of the next marker and schedule/output it yourself (via delay or when within p ms)
1 Like
#5

We are in the case with no speed change & no jump at all, considering a specific buffer.

Each buffer would have its own “size” (I know size is related to tracks), so as soon as I start to play all my tracks in a buffer, I can “request” the size and setup both my phasor period for my mubu.track and my speed for my mubu.play.

  • for mubu.track, phasor freq to setup is 1000./duration (considering I have a sample rate of 1000. which is actually big, but allow for slowing down the phasor if I want that at some point)
  • for mubu.play, I guess speed 1. is required for nominal speed

Let’s try this right now.

#6

I can’t get it to work fine here.
I guess I didn’t find the way to reset the mubu.play (it shouldn’t be required but even the first phase, it doesn’t seem to be ok as I probably misunderstood how to setup its speed.

obviously, with mubu.track + filtering output, works perfectly for that case. maybe not so efficient but ok.

research_test01.maxpat (18.0 KB)

#7

if you look closely mubu.play is more precise (without the 5ms jitter of sampling markers), but needs @loop 0 (it will loop directly after the last marker, which is on the second to last breakpoint).

1 Like
#8

gosh. I missed it was looping like this.
work perfectly like this.

Thanks a lot.
improving the prototype.

#9

is there a way to reset the mubu.play ?