[ossia-pd][ossia-max] add an alias feature to ossia.view's extended version

[bltzr]

If we follow the reasoning described in #208 wouldn't it be nice also to add an alias feature to this ?

Here's the idea: We could have a second argument (the first one being the node to bind to) which would define the alias's address. When present, the ossia.view (or maybe it would then be renamed ossia.alias) would create an alias node, under which all subnodes (parameters and models) would be also "mirrored".

e.g. if we have such a namespace as:

• rootNode (model)
  • one (param)
  • two (param)
    • sub (model)
    • uno (param)
    • dos (param)

if we added somewhere a [ossia.view /rootNode /myAlias) in which we had

• aliasPar (param)
• aliasNode (model)
  • eins (param)
  • aliasSubNode (model)
    • zwei (param)

That would make the global namespace:

• rootNode (model)
  • one (param)
  • two (param)
  • aliasPar (param)
  • aliasNode (model)
    • eins (param)
    • aliasSubNode (model)
      • zwei (param)
  • sub (model)
    • uno (param)
    • dos (param)
• myAlias
  • one (param)
  • two (param)
  • aliasPar (param) etc...

so, for instance it would be equivalent sending a value to:

• /rootNode/sub/dos or /myAlias/sub/dos
• /rootNode/aliasNode/eins or /myAliasaliasNode/eins

I guess that requires that aliases be implemented first in libossia... but does that sound like a good idea, or am I just saying bullshit ?

Also, as in #208 that would be great that this happen across remote device/client pairs.

What do you guys think ?

[bltzr]

after thinking about this a little, I finally think this is not a good idea rather, aliases should be defined on nodes (and parameters) directly this could be done with a second (or more, if we allow several aliases to a same address) argument(s), or with an @alias attribute (that could accept several addresses, if we allow several aliases...) what do you think, @jln- @reno- @avilleret

but AFAIK, aliases are not supported yet by libossia (right @jcelerier ?), so we have to wait that this is the case before... yet, we can start thinking about it... that's not an easy one, right, @jcelerier ? supposing that's the case I'm setting this to milestone 2.0, we can always change it if that shows up easier than expected

[avilleret]

I'm not sure to understand exactly what you mean... but 1 year and a half later it's more than time to dive into this !

[bltzr]

I don't think that has been ported to ossia-max (and I don't know if that's possible at all) but we have something that can do that - and more! - in score: mapper devices would it be "simple" to implement those in implementations, or would it be a nightmare, @jcelerier ?

[jcelerier]

it's not a nightmare but it adds a dependency to Qt and a JS interpreter to ossia-pd, ossia-max, etc... which may be disliked by some people (and increase the size of the externals).

[bltzr]

yeah, that sounds like something some might not like

[avilleret]

yeah, that sounds like something some might not like

me first :-)