Using MuBu for storing continuous and sporadic events/values on a graph-like way

[julienbayle]

Hi there,

I’m fascinated by seeing how far MuBu went.

For a new art project, I have to design a live performance system based on a graph.
The graph description is not yet defined, but we can imagine a graph, with branches.
Each branche has to store values evolving all along the branch itself and sporadic events too.

I think MuBu could really fit this requirement as a branch could be implemented like this;

• continuous evolving parameters could be tracks
• sporadic events could be markers (I don’t know if we can have different markers layers, or if a marker can have multiple properties

I think it fits well.

BUT.
I’d need a graph.
So This graph would mean n-branches.

I guess I can design a system based on branches names, a branch refers to stored data, I “load” a branch it loads these data and I can move all along my branch reading/recalling and interpolating data.
Then, when I go to the next branch, it switches, load the new branch’ data etc.

Is there a better way to do this as a graph ?

I’d have something like only 20 evolving tracks for each branch + 50 markers MAXIMUM.

My main spotted and imagined issues:

• loading time (getting everything in RAM could be better but heavy, maybe). I can preload adjacent branches etc but I’m afraid of issues especially while unloading (would it really unload?)
• easy way to “join” my tracks’ value across branches. I mean: I create a track with a starting value 0.5 and I evolve, evolve, ending at 0.9. I do that for all my branches with different values. I’d need to run a script that would take the previous branch’ end value to 0.5 and the next branch’ start value to 0.9 … avoiding jump. (I know I could interpolate for big jump using a smoothing line… but…)

ANY ideas would be very appreaciated

[beller]

Hi @julienbayle

Partial answer:
“I don’t know if we can have different markers layers” → Yes, you can.

For the hierarchical, you could use dictionaries referred by markers… ?

Best

Greg

[julienbayle]

@beller , thanks a lot.

About the definition of my graph (tree), as each branch is a set of N motion data + M triggers layers, maybe I can store the whole tree into just one MuBu container.

Each branch would be a buffer containing the N + M data.

The MuBu container would have as much buffers as the graph would have branches.

just trying to figure out how I could play a MuBu buffer (only data, no sound) and got smooth transition from a buffer to another. The project would read a buffer ALWAYS from the beginning to the end. At the end of a buffer play, it should goes to another one.

[julienbayle]

Double watching again tutorials,
I feel that the whole graph structure could be one container.
Each branch could be a buffer.

But I don’t feel confortable with that:
should I use one track only with multiwave data ? or as many tracks as I’d have data flows ?

I don’t see the pros & cons of both method.

[schwarz]

very interesting topic! Some ideas:

1. I would definitely go 1 branch = 1 buffer, and use tracks for the different types of data
2. to represent a tree in one mubu, you can use the bufferinfo dict, that gets stored with the mubu. E.g. use an entry “children” with the list of child buffer indices (pbly as a string, then split with “fromsymbol”)
3. interpolation: that’s up to the patch:
   a. mubu.play gives you the events (frames), but you could peek ahead to the value and time of the next event and use that for a line, or
   b. use ramp/phasor for time and the sample message to mubu.track. Then you’ll have to handle changing buffers specifically (unless you append the first event of the new buffer to the current buffer).

[julienbayle]

@schwarz, thanks a lot and what a crazy thing (the bufferinfo dict and parent/child description possible world opening here)

Actually, and for the record, if you are interested, this is a project I started as a collaboration between my studio + Université de Nantes and that would (should) result into an audiovisual live performance. I targeted MuBu as the data flow core, and it is a nice case of use and a nice way to dive into it
I’ll post more here but if you were interested in discussing the project, please pm me. It would be a pleasure.

[beller]

Following !