< Back to IRCAM Forum

MUBU "in place" methods request

MuBu
#1

Hi “MUBU” team… (sorry for my awful English…)

As was already said, the “MUBU” development is really taking a very good shape.

Translating some patches (ftm.editor to MUBU), it is clair that the mubu.tracks are becoming an alternative to the fmat objects filling a big lack in MAX, more complex “data structures”

In this context, I would like to propose (or to ask) some “in place features” (or methods) to be applied to the mubu.tracks (related to a main MUBU container).

  • The first (method, or set of…) is to be able to send to a MUBU messages like :

(track1 = track2 + track3)

(track1 = (track2/k1 + track3/k2)^2)

(track1 = track2) , track2 content is copied to track1

and so one…

It is important, also the choice of the syntax (infix, prefix or postfix). Even if, more and more languages mix them, just to have coherence with the main cases in MAX, I’ll prefer infix. It makes easier the transition for the standard user coming from “expr” for example. But, the best (imho), is to choose one and try to keep it.

the fmat methods (not their syntax) could be a good begin.

It is obvious that mubu.track is a polymorphic data structure, being able to contain, not only, vectors, but matrix, vectors of matrix, matrix of matrix, and so one. In this case, the methods could be just being applied for homomorphic data structures. It is up to the user to ensure the coherence of his data.

Hoping it could be useful

All the best

Mikhail

#2

Dear Mikhail,

Please accept my apologizes for the enormous delay of my answer – I hope this doesn’t happen any more when the notification of new topics will work in these discussion groups…

Yes, in fact, I have thought of adding an option “inplace” to mubu.process so that, instead of generating a new track, the result of the processing replaces the current track. This would work with PiPo modules or with Max patches (mubu.process can output a stream of values for the given track and you have to feed back values into the external).

The most important feature to add here is the possibility to dynamically change the PiPo chain dynamically.

Here we also could imagine adding a PiPo module that evaluates a JavaScript and/or lua expression (BTW we will release very soon an experimental API for developing PiPo modules and hosts).

Cheers

Norbert

 

#3

 

Hi Norbert,

 

 

Don’t worry, is fine…

 

 

Concerning mubu.process, IMHO, I find that is not a good idea to use it for “inplace” operations.

 

 

Max is, mainly a data flow programming “almost language”, driven mainly by messages to the boxes. For a standard Max user, it is more intuitive to decline the same language structure and syntax model to all the other boxes and process.

 

 

An external object (like mubu.process) to make an operation to another object, without link, and without data flow processing, seems to me less intuitive, and less ergonomic, especially for ‘in place” operations.

 

 

Sending a message to a mubu or imubu (in the case of “inplace” operations), is closer to the general Max behavior, and easier to a standard Max user to understand.

 

 

IMHO, I’ll keep mubu.process (& pipo), more to data flow processing…

 

 

Why not to implement what you already have (some basic methods coming from fmat) to imubu ? It will gave a simple, easy way to do the things…

 

 

Mubu and imubu are ways to rewrite data structures like mat, fmat and visual interfaces like ftm.editor.

This new mubu framework seems very stable and useful.

In this new configuration (again, IMO) seems better to stay closer from the main Max frame,

even if we could find a lot of exceptions (buffers, etc…)…

 

 

This is just to make the new mubu&al. framework more ergonomic…

 

 

Any way,

 

 

Thank you for your answer

 

 

All the best

 

 

MIkhail

 

#4

Salut Mikhail,

Yes, I completely agree that – other than FTM & Co – the syntax of MuBu should stay as close to Max as possible.

Nevertheless, the processing of data streams stored in memory – especially inplace – doesn’t have a lot of examples in Max.

The external mubu.process provides the possibility to defer the processing in separate thread, which is especially necessary when applying complex expressions to long tracks of data.

I am not sure if we should integrated this possibility into an external like mubu.track.

Similar is true for the PiPo host that is integrated into mubu.process, but not in mubu.track and I would insist to integrate the expression evaluator into an independent PiPo module.

Anyway, I would not completely exclude the possibility to provide methods (messages) for mubu/imubu/mubu.track that perform similar processing as mubu.process in the future.

In summary, I would propose the following roead map :

    <li>integrate inplace processing into mubu.process</li>

<li>integrate a PiPo integrating a lua and/or JavaScript (and/or whatever) expression evaluator</li>

<li>see what we can do as messages to mubu/imubu/mubu.track on this basis</li>

Does that sound reasonable?

N.

#5

Salut Mikhail,

Yes, I completely agree that – other than FTM & Co – the syntax of MuBu should stay as close to Max as possible.

Nevertheless, the processing of data streams stored in memory – especially inplace – doesn’t have a lot of examples in Max.

The external mubu.process provides the possibility to defer the processing in separate thread, which is especially necessary when applying complex expressions to long tracks of data.

I am not sure if we should integrated this possibility into an external like mubu.track.

Similar is true for the PiPo host that is integrated into mubu.process, but not in mubu.track and I would insist to integrate the expression evaluator into an independent PiPo module.

Anyway, I would not completely exclude the possibility to provide methods (messages) for mubu/imubu/mubu.track that perform similar processing as mubu.process in the future.

In summary, I would propose the following road map :

    <li>integrate inplace processing into mubu.process</li>

<li>add a PiPo based on a lua and/or JavaScript (and/or whatever) expression evaluator</li>

<li>see what we can do as messages to mubu/imubu/mubu.track on this basis</li>

Does that sound reasonable?

N.

#6

Hi Norbert !!

Yes, it sound reasonable…

After our conversation at the coffee machine, I can say that your arguments have convinced me !

As you said, you should lighten MUBU, as much is possible.

So, waiting for pipo methods…

all the best

Mikhail