create a j.node object

[jln-]

The order of j.parameter's priority are not preserved when addresses have sub node.

For example, if one has the following in his model:

[j.parameter sources/number @priority 1]
[j.parameter source.1/position @priority 2]

When storing a state, for example, "source.1" will get stored first, then "sources/number" since "source" and "sources" nodes do not have priority, hence are stored alphabetically.

[bltzr]

to me, that seems normal, because priorities can only happen under each
node, or it would just be impossible to generalize...

Yes, I agree with that. I'm actually mixed regarding this "issue".

As an end user, "sources/number output" then "source.1/position output" is what I want so it would be nice to have things dealt with implicitly, rather than having to explicitly set nodes order in order to get the leaves in the desired order. But should we make the code more complicated etc. to hide such a complexity to the end user, I dont know. Hard to balance.

Another feature that I've been missing these last days was being able to
set tags to nodes that are not declared anywhere (e.g. filters of an
equalizer~.model that are implicitly declared through j.parameterArrays)
so in this example we could have :
[j.node filter.1 @priority 1]
[j.node filter.2 @priority 2]

But in this case, this should already work this way, right, since without priorities, parameters are sortes alphabetically, right ?

In the past (about two years ago, at the beginning of 0.6), we solved this
problem with [j.model component] which was basicly the same thing than
[j.model @amenities none] - though I have the impression (but I might be
wrong) that this is somehow too heavy for this kind of usage to have a
full-fledged j.model object, when all we do is to add a couple of
attributes to a node that already exists in the namespace tree (even if it
does implicitly)

[bltzr]

Back to this issue, I feel more and more that a j.node (or j.nodeMarker... but it's a bit long to type...) would be useful to set attributes to certain implicit nodes of a model (for example when sorting the sound file under a /sound node, it is important that this parameter is recalled first...)

of course, we can always create a j.model @amenities none, but it feels a bit heavy, doesn't it ?

should we discuss this in Bergen ?

[reno-]

I like this j.node idea which could be useful. I don't want to declare a model each time I declare a node.

[bltzr]

I have renamed this issue in order to better reflect what we want to act upon

Reno, as you won't be there in Bergen when we'll discuss that, what would be your specifications for such an object. If you can prioritize them, that would be even better !

[jln-]

Since I wont be in Bergen either, here are a couple of things I'm wondering:

• Are their other things we would like to set for a node beside priority ? Description maybe ? If so that could be useful though that's very low priority to me.
• If we are to use a [j.model @amenities none] to set priority, what other feature should need to be removed to have a light implementation of this ? My first impression is that a model is a bit heavy as well, but I dont know to what extend is it true.

[bltzr]

I'm thinking of the tag attribute

I'll think more...
Le 24 févr. 2014 21:36, "Julien Rabin" notifications@github.com a écrit :

Since I wont be in Bergen either, here are a couple of things I'm
wondering:

Are their other things we would like to set for a node beside priority
? Description maybe ? If so that could be useful though that's very low
priority to me.

If we are to use a [j.model @amenities none] to set priority, what
other feature should need to be removed to have a light implementation of
this ? My first impression is that a model is a bit heavy as well, but I
dont know to what extend is it true.

Reply to this email directly or view it on GitHubhttps://github.com//issues/388#issuecomment-35932651
.

[bltzr]

Also, I guess it would be useful that j.node works like j.model, patch-wise (so that all objects in the same patcher and its subpatchers subscribe to its node)
Actually I think that not doing that would be confusing....

[bltzr]

description attribute might also be handy
maybe alias too ? (if that doesn't add too much weight)

[bltzr]

summary of j.node's requested attributes:

• priority
• tag
• description
• alias ??

it should also bind all j.parameters below itself (like j.model does)

[bltzr]

conclusions:

• no alias
• j.node doesn't parameters to its address, it just declares attributes for a node
• wildcards can be used
• subnodes can be used (e.g. [j.node some/sub/node])

if a parameter with the same name exists, j.node is discarded (j.parameter wins)

[bltzr]

side-effect : priorities of parameters are declared for the last node only
e.g. : [j.parameter some/sub/node/param @priority 2] -> priority only applies under the "node" node (and competes with other children of the "node" node)

[bltzr]

This object now exists - you can see it in action in the Priorities tab of j.parameter.maxhelp (until I make a j.node.maxhelp, very soon...)