[ossia-max] Linking multiple ossia.devices in max

[navid]

What can one do if they want to put different processes on either different top-level patchers or different instances of max to take advantage of multi-threading: ie. Audio processes on one top-level patch and interfaces, dmx/midi/mira and HCI stuff on another, etc.
Currently, ossia.device is designed to only “see” anything under it (under the top-level patcher that it is in). So if one were to create two ossia.devices, then would it be efficient to use ossia.remote/clients (currently not even functional) to share namespace and hundreds of messages flowing through params/remotes across the two devices? A viable solution needs to be introduced.

[vincentgoudard]

Decoupling namespace hierarchy from patching hierarchy.
In other words, decoupling model from view.
Which is what MVC is about... :)
...
is this topic closed, really ?

[jcelerier]

Decoupling namespace hierarchy from patching hierarchy.

I mean, the whole point of ossia max is to create a hierarchy of objects from a hierarchy of patches, no? (and it 100% is the point of the other bindings which try to leverage the built-in hierarchy that other environments provide to create an OSC tree). Ideally, it should be a built-in Max feature, not something that one has to workaround with a custom library but well

[navid]

it is not fully closed but we are investigating it for now and trying to articulate better:

Turns out that ossia.remote.client/device does work across two instances of max but it is badly documented and we are not sure how efficient it is for complex inter-dependant architectures. So we are testing its behaviour and efficiency now.

@vincentgoudard and @jcelerier : neither the decoupling model and view nor max's hierarchy addresses the issue. Consider the following scenarios:

You have a big camera tracking patch, working wth muiltple cameras, blobs, and taking up a lot of GPU/CPU and scheduling resources. And then you have another huge sonification patch that needs to run in a separate instance of max with its own scheduler to be concert-efficient. There needs to be communication between the two different instances of max via ossia.devices communicatng flawlessly. This might be working and we are investigating it further. That is why we closed the issue fow noe.

2. importantly: the point of max is not sumbitting to a heirarchy of objects from a heirarchy of patches (but the point ossia.devce might be). Sometimes one needs to have multiple simoultanouse heirarches: sometimes fully independant in parallel, but sometimes interdepenant, and soemtimes cross-communicative.
   Also importantly: in max, within the same instance of max, each top level patch gets processed in its own thread. Many programmers, ircam patches, etc. take advantage of this fact. So, what if we wanted to put models and veiws on different top level patchers in the same instance of max > it won't work because ossia is structured in a heirarchy and would not see the other ossia objects that are on their own top level patchers. This is ok andd we can accept it as an inherent behaviour in ossia. But it also means that efficeint and flexible work arounds are needed for the community to build complex architectures that run across mutiple top level patchers and easly save and share their states.
   If one has three top level patchers: one with HCI stuff, one with LFOs, one with GPU stuff, then three ossia.ddevices are needed and then one needs to synchronzie the preset system to work across them all. If one needs to share data between them then one needs to create multiple remote clients/devices.... all to say: we are currently trying to wrap our heads aroudn how to handle complex multmedia architectures.

[vincentgoudard]

I do not agree with that.
Yes, the whole point of ossia (or jamoma, for older chaps) is to create a hierarchy of models, but not necessarily from a hierarchy of patchers. Although I agree that this may turn out to be convenient in many cases that it does, there are some examples where it is not convenient or even limiting. I have series of examples where it is not handy to have the namespace hierarchy tied to the patching hierarchy.

The patching hierarchy in Max has multiple aspects, including (but not limited to) viewing ergonomy, programming ergonomy, in-code documentation, DSP optimization (what Navid refers to), etc.

Among examples where the link between patching hierarchy and namespace bugs me me in ossia :

• you cannot put several models, each with its own set of parameters, in the same patcher.
• auto-named params/model in poly~ that @matcham explained in [ossia-max] parameter in poly~ always adds voice # to parameter's name #811.
• namespace messed up when encapsulating, de-encapsulating (which I happen to do a lot during the process of elaborating an idea)

Best of both world could possibly be what is done in jitter/GL: bind to the GL context that has been explicitly set as an argument or auto-bind to patcher's context if no explicit context is provided.

But yeah, although I think it would be worth it, I can understand that adding support to this might be a considerable effort.