[ossia-max][ossia-pd] let ossia.param and ossia.model register under ossia.view's bound parameter

[bltzr]

we discussed that and it seemed an interesting feature.

• for ossia.remote: nothing changes
• for ossia.model and ossia.parameter: instead of registering under the nearest ossia.model in the patcher hierarchy above, they would register under the ossia.model to which ossia.view is bound.

A few questions and observations, though:

• what should happen if ossia.view is not bound to anything (or to a unexisting node) ? Maybe the model/param should bind to the next model/view above ?
• what should happen if ossia.view binds to a new node ? should the model/params unregister from the brevious bound nodes, and register to the new node ? I guess so...
• what happens if there is a multiple (such as node.{1..12}) address to the view, should the model/params be duplicated as well ? Won't that be a problem (aka hard to implement) ?

I also thought about the proximity between this and an alias (and the possibility to merge both), but I'll elaborate in another issue.

[bltzr]

also, would that work from a client, i.e. remotely (that would be great !)

[bltzr]

thinking again about names for this:

• we agreed that ossia.node was a good, more generic name for what is currently called ossia.model
• thinking again about it, I would go for ossia.reference for ossia.view's replacement name (which could be aliased to ø.ref for lazy pd-ers... ;-p )

if others agree on that proposal, I guess we could change the names right now, and keep aliases for ossia.model and ossia.view so we don't break any patch

and some day, hopefully we'll implement this new feature of registering model and parameters to the referenced node

[jcelerier]

:+1: for ossia.ref

[bltzr]

I forgot to mention the usual suspects: @reno- @jln- @avilleret

[avilleret]

I think we forgot this issue... @bltzr should we change things right now ? or not at all ?

[bltzr]

this can come later, I think, as those are additions (and if we decide to use those names, we can always set aliases to model and view so they can keep on being called this way)

[avilleret]

I'm wondering if this is not already possible to create paramter under an ossia.view in pd or max... it's worth a try

never the less, now that we support request command in OSCquery protocol, we can use it from pd or max

[bltzr]

I just tested and, nope, it doesn't work - the parameter is created under the “closest" parent model

I guess it's interesting to keep this idea here, so I've just added the enhancement label