ossia
[ossia-max] Avoid creating intermediate nodes
When an ossia.parameter with a multi-level address is created, ossia creates intermediate nodes for each level of the hierarchy. For example, if an ossia.parameter is created with the address audio/gain/interpolation, the following nodes are created:
device:/model/audio device:/model/audio/gain device:/model/audio/gain/interpolation
If another ossia.parameter is then created with the same name as one of these intermediate parameters (e.g. /out/final), it will wind up with a numerical suffix:
device:/model/audio device:/model/audio/gain device:/model/audio/gain.1 device:/model/audio/gain/interpolation
This makes it easy to accidentally create duplicate node names, which can cause some confusion when e.g. retrieving values or storing presets.
Please see these demo patches:
My question is: is this auto-creation of intermediate nodes desired or useful behaviour? I don't understand what the purpose of this is, but I may very well be missing something. If it's not necessary for some reason, could this behaviour be prevented?
Possibly related to https://github.com/ossia/libossia/issues/628 and https://github.com/ossia/libossia/issues/559 . Tested with b206e461.
I also tested with an older build that I've been working with (7c49e83). In this case, the test patch results in the following nodes being created:
device:/model/audio device:/model/audio/gain device:/model/audio/gain/interpolation
In this case, the node with .1 appended is not being created. I still wonder, though, is it necessary for these intermediate nodes to be created at all?
Intuitively, what I would expect from this patch is just two nodes corresponding to the ossia.parameters that have been explicitly created:
device:/model/audio/gain device:/model/audio/gain/interpolation
short answer : it is not possible to avoid creating intermediate nodes, by design.
long answer : libossia is based on node tree. node could have parameter. and each node has a parent node but the root of the tree (this is how we define the root : it has no parent). If you want to create an ossia.parameter with address /foo/bar without creating the foo node, then what will be the parent node of your parameter ?
concerning the auto-incrementation of nodes names, this is a feature that allows you to easily duplicate model. for example you can load n instances of a model with address /foo/bar.1 in a poly~ and then each instance will have its instance number as a suffix in its address. This is pretty handy.
in the case of your example, its a bit more convoluted. it's an edge case that has not been specified iirc.
You first create [ossia.parameter audio/gain/interpolation] which creates all the needed intermediate nodes.
The you create [ossia.parameter audio/gain]. It will try to create the node audio/gain which already exists, then it creates a new node gain.1 under the audio node.
What is not specified is what we should do when we want a parameter foo while a node foo already exists but without a parameter .
Currently it create a child node called foo with a parameter. The resulting namespace is : /foo/foo.
I thought this is more straightforward like this but maybe not. see:
----------begin_max5_patcher----------
374.3ocuT1saBCBEG+51mBBW2YJsUctWkEyBVYNLs.AnttX7cevg141pSaL5
t4jb9h+7iyocebDdkrkYvnmPOihh1GGEAg7Ah57iv0z1xJpAJCWyLF5FFNIj
yxZsPbA0kQQK+JihZKeiK17hlUZCJjULIMAQx814DuMKaRJZYWGhlZtnhYAg
xNFT1X6iR5hxWChJWs8g48BFJy9ghETCiQK8YNDG6MIiDPA6c2wNfOklKrWj
sEodad14YibR1RGxVA91AfzX3zKBPwT.f4WC.mX3j++Lb.1lnnZ2RnkoQuJk
mgTRN.4zYv1HY50vZ1PVy9aVStK7VKWypFGqDf0E42nwJYjiUPFbEW76+w.2
Te7extQ1nK6OptOtQGurqYFKWPsbo3a0jGp4jutiUm7QnSw.cB3QUpcLsoqX
PB2PbqT6ceLAb4hfK7Vh0rc795CEP0tAm0M0Zzv0B2Nq.GZ0Mj0hFNzcrGNm
jvBxw+35avuGEeH9SbgFakG
-----------end_max5_patcher-----------If we decide that in the case above, the ossia.parameter create only a parameter attached to the already existing node, then your case will be solved, because since audio/gain already but doesn't have a parameter, [ossia.parameter audio/gain] will create a parameter attached to that node.
But this should be discussed as it will break some patchers and presets.
My preference in cases like would be that if a node exists that doesn't have a parameter attached, and then a parameter is created with the same address, the parameter should be attached to that node. Having parameters get auto-incremented in cases where there's a node with no parameter seems quite counterintuitive to me.
In building models, I often create parameters that partly share the same address, but then terminate at different depths. For example,
acc/pitch acc/pitch/invert acc/pitch/active acc/pitch/offset
This winds up creating an extra auto-incremented parameter:
acc/pitch.1
@navid and @petervanhaaften have used the same pattern in their modules, and I suspect that this is something that other users would intuitively do as well. The current behaviour thus seems to me like it might cause some confusion.
what do @maybites @jln- @matcham @vincentgoudard and maybe @bltzr and @jcelerier think about that ?
@avilleret I don't understand your foo/foo example in your long answer and how this relates to this problem. it looks like expected behavior to me. I always thought the [ossia.model] is a parent node of the [ossia.parameter] inside the same patcher.
thats because I tend to take @evanmtp side of the argument and I don't see how this bites each other.
AFAIC, with @evanmtp example, I get this as a namespace, which matches what I would expect (using v1.1.0a4 980a883) :
print: namespace ossia_max_device:/myModel
print: namespace ossia_max_device:/myModel/audio
print: namespace ossia_max_device:/myModel/audio/gain
print: namespace ossia_max_device:/myModel/audio/gain/interpolation
As for @avilleret example, this is also what I would expect, as I also consider a "model" (or device) to be the "parent" of any patcher attached to it. In this respect, it make sense that a parameter foo attached to a model foowould create a parameter address foo/foo.
But as @maybites says, I don't really see how those two bite each other either.
I might have missed some points, but in the zipped examples there shouldn't be any duplicated node (in my current version, 1.0.4-7c75235, there isn't any)
Just made a build from the latest commit (#776351d8b) and tested - still getting duplicate nodes:
@avilleret, @bltzr , what do you think at this point? Seems like @maybites, @vincentgoudard and I are in agreement, and @petervanhaaften and @navid are as well.
I think this is fixed : I don't see any extra parameters with 2da51f3e (should be fixed in v1.2.0-rc1 too)
I still have the duplicate node issue with v1.2.0 built 3476fe7 .
print: namespace ossia_max_device:/myModel
print: namespace ossia_max_device:/myModel/audio
print: namespace ossia_max_device:/myModel/audio/gain.1
print: namespace ossia_max_device:/myModel/audio/gain
print: namespace ossia_max_device:/myModel/audio/gain/interpolation