Improve Automation creation

[bltzr]

Quand on crée une automation en jetant une adresse sur un intervalle/slot (ou en ajoutant l’adresse dans l’inspecteur après avoir créé le process), s’il y a des valeurs pour cette adresse dans les states :

• De début et de fin : Utiliser le contenu des states
• De début : utiliser le contenu du state de début et utiliser la valeur actuelle (query) pour la fin de l’automation
• De fin : utiliser le contenu du state de fin et mettre en mode tween
• Nulle part : utiliser la valeur actuelle (query) pour la fin de l’automation et mettre en mode tween

[avilleret]

2 llines sumup with ternary operator :

• startState.hasValue() ? use it : (else) make a tween;
• endState.hasValue() ? use it : (else) use current node value;

[avilleret]

point 2 is already there...

[avilleret]

this doesn't work with vecnf (at least vec3f)

[avilleret]

should be fixed with https://github.com/OSSIA/score/commit/ae84889254dd08552bf253c252177424e741674f

[bltzr]

The last case

Nulle part : utiliser la valeur actuelle (query) pour la fin de l’automation et mettre en mode tween

doesn't work : it creates an automation from the min to the max value

[bltzr]

there's the same problem when there is a start value: the max value is used for the end of the segment, instead of the queried value

[bltzr]

did you explicitly fix this @jcelerier ? or was it automatically closed by the history rewrite ?

[jcelerier]

huuuh yeah it seems. The commit name has changed and since it was marked fixed already by @avilleret it must have re-closed it

[bltzr]

apparently, when there is an unit to a parameter, it seems not to match the addresses the values in the states: everything happens as if there were no values

also, something's wrong with vecnfs: we get a 0. to 1. ramp whatever the values (0-1 because of the bug with the domains, aka #679)

maybe this should be thoroughly revised when also implementing the new intepolation process (issue to come)

[bltzr]

as reported in #791 we still have this problem (which is a bit embarassing) :

Nulle part : utiliser la valeur actuelle (query) pour la fin de l’automation et mettre en mode tween

doesn't work : it creates an automation from the min to the max value

[bltzr]

just upping this one because I think it's really an important one (and I suppose it's not the hardest, but I might be wrong)

[jln-]

Upping this one as well as I was documenting this. ATM, case 1 does not work as of v3.0.0-a15.

Assuming two states with a gain parameter stored with respectively -12dB and 0dB, dropping gain parameter on the interval creates an automation in tween mode between 0 and 1

[jln-]

A bit late to the party, I know, but sharing some thoughts on these use cases as I try to emphasize the drag&drop workflow for the documentation.

While these are super handy, I am a bit concerned that creating a simple automation is a bit complicated ATM:

• mouse over to the interval
• click + to add process then select desired process (automation)
• click the process to bring the inspector
• mouse over to the D-E
• grab your parameter
• then mouse over all the way to the inspector to drop the address

Phew... 't was quite a trip... :)

My impression is that use case °4 (dropping an address when no value is stored in start and end states) should just create an automation.

4th use case listed by @bltzr could still be provided by dragging an address while holding 'alt' key or something.

Opinion ?

[jcelerier]

While these are super handy, I am a bit concerned that creating a simple automation is a bit complicated ATM:

hm, what I'd like to move to is only using the process library (or the explorer) for that :

• drag the process from the library to the interval creates an automation
• double-click on the process in the library when an interval is selected creates an automation

what do you think ?

My impression is that use case °4 (dropping an address when no value is stored in start and end states) should just create an automation.

but, isn't this what happens right now if you drop an address from the DE ?

[jln-]

hm, what I'd like to move to is only using the process library (or the explorer) for that :

• drag the process from the library to the interval creates an automation
• double-click on the process in the library when an interval is selected creates an automation

what do you think ?

You mean this and remove being able to grab addresses directly to create processes ?

If so, I would spontaneously disagree. It may be hard to argue briefly here (not to mention that it is 2.00 am ;-) but from a UX pov, I'd rather stick as much as possible to a workflow starting from "what we want to control" (a sound or image parameter) rather than "how we need to control it".

Not sure this is clear. But we can chat over Gitter.

My impression is that use case °4 (dropping an address when no value is stored in start and end states) should just create an automation.

but, isn't this what happens right now if you drop an address from the DE ?

Sorry for bad explanation. I meant simply creating an automation without involving tweening or querying. Just dragging a parameter to create an automation with slot's min and max set to parameters range bounds and whatever default linear segment. Noting fancy.

[jcelerier]

If so, I would spontaneously disagree. It may be hard to argue briefly here (not to mention that it is 2.00 am ;-) but from a UX pov, I'd rather stick as much as possible to a workflow starting from "what we want to control" (a sound or image parameter) rather than "how we need to control it".

eh, I'd say I agree but then I don't understand why keep the "+", as adding things like that are even less related to the "what we are controlling"

I meant simply creating an automation without involving tweening or querying. Just dragging a parameter to create an automation with slot's min and max set to parameters range bounds and whatever default linear segment. Noting fancy.

hm, I think that tweening by default was @bltzr 's request, maybe we can make that a setting ? edit: yes, it was in precisely this issue XD