Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature-request] node aliases #346

Open
pchdev opened this Issue Dec 16, 2016 · 21 comments

Comments

4 participants
@pchdev
Copy link
Contributor

pchdev commented Dec 16, 2016

up for debate, and following the idea developed in jamoma if I'm not mistaken: allow a node to have an name/address alias, in order to make some unchangeable osc addresses clearer.

i.e.: in reaper, I have a parameter I want to modulate at the address "/track/1/fx/1/fxparameter/2/value" and I'd like to assign it a clearer name.

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented Dec 16, 2016

If I understand that well, does that mean that you permanently want to address this with e.g. /some/address in i-score (while the actual OSC address Reaper expects is /track/1/fx/1/fxparameter/2/value) ?
If so, maybe a more general idea would be to be able to have a kind of OSC mapping, where we could substitute a tree in i-score to the OSC tree the remote device understands
there could also be some pattern-matching magic, in order to "tidy up" some namespaces (e.g. Dlight, if my memory is good) and make them more relevant to the way things are managed in i-score
I think this was discussed in the first OSSIA workshop in Lyon, and that we took notes about this
maybe we should add this to the discussions to address in Montbéliard... @theod @reno- ?

@pchdev

This comment has been minimized.

Copy link
Contributor Author

pchdev commented Dec 16, 2016

@bltzr yes, exactly!

@theod

This comment has been minimized.

Copy link
Member

theod commented Jan 3, 2017

maybe we should add this to the discussions to address in Montbéliard...

yes ! a very first feature would be to have a new node type called "alias" that allow to point to another node in existing devices.
so you don't allow a node to have one alias but you allow to create as many aliases you need for one node. this sounds a more powerful feature to me.

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented Jan 17, 2017

@jcelerier jcelerier added enhancement and removed enhancement labels Feb 25, 2017

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

maybe a way to use it would be by adding a alias field just below the name (when editing a node)
then the node shows up in the device tree with the alias (instead of its "built-in" address
if it has children, they are nested under this aliased address (?)
opinions, @OSSIA/users ?

@pchdev

This comment has been minimized.

Copy link
Contributor Author

pchdev commented May 15, 2017

hmm, ok for me

/track/1/fx/1 would have an alias for example : /reaper/filter

now, say you want to give /track/1/fx/1/fxparameter/2/value an alias (/reaper/filter/cutoff)
you click add child on /reaper/filter
maybe type fxparameter/2/value for the absolute node adress
and then just “cutoff“ for the alias

is that suitable?

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

what do you mean by "cutting off the alias" ?

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

oh sorry, I misunderstood :-D

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

well why not... I guess that's mainly a question for @jcelerier if that's doable ?

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 15, 2017

IMHO, what would be best, would be that subnodes can inherit from their parent's (or ancestor's) alias, but that they can have their own particular aliases too.

In the given example:
the user gives /track/1/fx/1 the alias /reaper/filter
its subnode /track/1/fx/1/fxparameter/2/value is automatically given the alias /reaper/filter/fxparameter/2/value
which they can replace (by editing this node's alias) to /reaper/filter/cutoff
(we can help the user on this by automatically selecting the specific part in the editor, i.e. fxparameter/2/value)
or even, if they want it so, to /my/amazing/cutoff, thus having this node's alias existing outside of the parent's alias sub-hierarchy
would that make sense to you ?

@pchdev

This comment has been minimized.

Copy link
Contributor Author

pchdev commented May 15, 2017

yes, even better!

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented May 15, 2017

the user gives /track/1/fx/1 the alias /reaper/filter its subnode /track/1/fx/1/fxparameter/2/value is automatically given the alias /reaper/filter/fxparameter/2/value

isn't there a risk of a ton of duplicated nodes ?

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 16, 2017

why/how ?

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented May 16, 2017

its subnode /track/1/fx/1/fxparameter/2/value is automatically given the alias /reaper/filter/fxparameter/2/value

The address " /reaper/filter/fxparameter/2/value" would be visible from the device explorer right ?

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 16, 2017

nope, it would be replaced by its alias IMO

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 16, 2017

we can consider having two display modes for the tree: absolute or aliases

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented May 16, 2017

nope, it would be replaced by its alias IMO

ok, that's a big difference :p this should go in the "device explorer work package" then I think.

@bltzr bltzr added this to the release/1.1 milestone May 16, 2017

@bltzr

This comment has been minimized.

Copy link
Member

bltzr commented May 16, 2017

sure, done - though, maybe that can be done in a second batch, once the main refactor is done, right? or should it be considered from the start of the refactor (if so I'll move it to the 1.0 milestone)

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented May 16, 2017

I think that it should be considered from the start - it may be a big change

@jcelerier jcelerier modified the milestones: release/1.0, release/1.1 May 16, 2017

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented May 16, 2017

(but I really doubt it will be done by then)

@jcelerier jcelerier modified the milestones: To discuss, release/1.0 Jun 1, 2017

@jcelerier

This comment has been minimized.

Copy link
Member

jcelerier commented Nov 6, 2018

would the current "Mapper" device be enough to cover this FR ? (reminder of how it works : https://github.com/OSSIA/score-user-library/blob/master/Devices/Mapper/Mapper.qml)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.