Posted
Hi,
It seems that it is not doable to mute/deactivate a parameter without deleting it.
This would be a very helpful ability to have.
For example, consider if I have imported MIDI which has complex controller information, perhaps as a Bend. I would like to audition and ultimately use or not use the Bend in various spots. I do not want to delete/destroy the Bend while auditioning with/without it.
If a particular Parameter is no more than an on/off switch then one might argue that deleting it is of no consequence, as it can always simply be re-applied. I would disagree with this, as there are many situations where the suggestion implied by a deactivated Parameter would be very useful to have and/or keep around. So, even in the simplest case, ability to mute/deactivate a parameter without deleting it would be a very helpful ability to have.
Where the parameter is more complex and includes information not easily reconstructed it becomes near-critical to be able to mute/deactivate it without destroying it.
Without this ability we have to walk on eggshells as we do our work, constantly in fear of destroying what we don't want to lose and then have to painstakingly reconstruct (or henceforth do without).
Is it too performance-reducing for rendering to have to check an active/inactive flag on Parameters in realtime? If that is true in the general case, then perhaps we could discuss only allowing this ability for specific parameters, those which contain complex information.
In that regard, I nominate Bend. <g>
Sun, 2024-02-18 - 14:40 Permalink
But perhaps checking to see if a Parameter is "on the list" (e.g. Bend) is as bad or worse than simply checking active/inactive for all Parameters.
In that case, I suggest that the ability be optional. IOW, we can turn if off for performance reasons, and turn it on during non-performance-critical work.
Sun, 2024-02-18 - 16:18 Permalink
You can create a separate container with a zero value for the parameter in question (eg. Bend) in it. Then drag that container to the place in the timeline where you don't want to hear the effect of the parameter. Of course you can delete that container again at any time and then everything is like before.
Sun, 2024-02-18 - 16:26 Permalink
Or move the parameter to the embedded library and move it back when you need it
Sun, 2024-02-18 - 21:35 Permalink
Much needed for Interpretation as well. The list is probably pretty long ...
Thanks for the workaround suggestions. I appreciate them, but they don't really solve the issue, which is a workflow efficiency issue.
One-touch, non-destructive, in-place On/Off - that's what's really needed, IMO. No more, no less.
Mon, 2024-02-19 - 08:33 Permalink
Of course A/B testing is important. Adding an on/off switch to every object is not feasible though. We can deactivate containers, phrases, segments and symbols (mute).
Concerning parameters, I'm torn. The number of parameters and different color indications is already overwhelming. Imagine yet another switch next to every parameter and another shade of colors for the user to interpret. Let alone another distinct shading for the data in the parameter editor/view.
A/B testing at the parameter level usually means you delete it, check the result and either undo the deletion or move on. If you need to put a parameter aside for longer, the new toggle button above the sidebar allows for faster access to the embedded library, so you can use it as a clipboard more conveniently.
Mon, 2024-02-19 - 12:59 Permalink
Imagine yet another switch next to every parameter
Why go that way? You'd have to redo the whole UI!
I'd suggest using a modifier key (e.g. Ctrl-click, or Shift-click) to accomplish the on/off.
A right-click menu item is another possibility.
and another shade of colors for the user to interpret.
A non-issue IMO, because the existing UI design is already perfect to accommodate whatever needs be shown. By this I mean the "traffic light" display, the colored dot that is already part of all Parameters.
Whether you use another color for the dot, or whether you use a "greying out" effect to indicate active/inactive is of very minor (zero, IMO) consequence. What is of major consequence is not having a simple, highly-efficient workflow for A/B of parameters!
Mon, 2024-02-19 - 13:16 Permalink
Let alone another distinct shading for the data in the parameter editor/view.
If you don't want to use another data color, don't. You could choose to just let the traffic light alone indicate on/off.
You could put a text stamp on the data display to indicate "Disabled" if you really feel you want or need a further indication there.
OTOH, using another shading/color in the data display is a "don't care" from the user perspective compared to "care alot!" as to whether A/B testing with Parameters can be done smoothly and quickly. Use (yet another!) color for the data if (and only if) you think you have to for some reason.
Mon, 2024-02-19 - 13:26 Permalink
The number of parameters and different color indications is already overwhelming.
To whom?
Speaking for myself, I don't feel overwhelmed by the colors in Synfire at all.
OTOH, I do feel BLOCKED from the highly efficient workflow that I know could exist, but currently doesn't.
