One-click Parameter Eraser

Just slightly less quick would be a new context menu item:  'Delete in Selected Containers'.

In this case, we'd still need to do just one (Ctrl-) click per container (to select), and then just 2 more clicks - 1 to open the menu, and 1 to  execute the operation.

Either of the above would greatly expedite the workflow over what has to take place now to accomplish it (3-clicks, with navigation in-between, for the container where the erasure is desired).

I will add also that IMO this case is another good example of where a Parameter On/Off ability, or a Parameter A/B ability  (where A or B could effectively be Null or Off) would be super-handy.

Anytime you want a Harmony (or other parameter) to be stashed out-of-the-way (rendered moot until revived), without having to perturb the Structure layout, and without destroying the work permanently this ability would be super-good to have.

The topic of multiple-selection "batch" processing (containers, phrases, pools) is still an open discussion.

I hope so!

Adding menu items for individual use cases won't be a satisfactory solution.

To be clear, that was not proposed.

What was proposed:

a)  a Parameter Erase tool  - not an individual use case, but a general tool with universal applicability

and/or

b)  exactly one more menu item, 'Delete in Selected Containers', which would join 'Delete' and 'Delete in All Containers' to complete the triple of individual/selected/all  - for any parameter  -  again, not an individual use case, but rather a universal, small-footprint approach to a meeting a clear and present need.

Why not just hit Delete and if multiple containers are currently selected, delete the parameter from all of them?

Granted, that's the smallest UI footprint of all - zero!

But that would be dangerous as heck!    You'd be implementing the action of 'Delete in Selected Containers' without making it clear that the user was choosing that.   In order not to be dangerous, you'd have to pop up a dialog to let the user know they were risking multiple deletions.  Much more desirable is to do exactly what the user explicitly asks for, no more, no less.

In that regard, something like Ctrl-Delete or Alt-Delete might serve, as it would be an explicitly different choice than simply Delete.

Keeping track of all the places where parameters are temporarily disabled can get very confusing

You mean to the user?   If so, I beg to differ.

All of us are familiar with 'Mute' in the audio domain.   All of us are familiar with 'Mute' in the MIDI domain.   
Now Synfire has this extra notion, "parameter".    There would be, IMO, no confusion about what 'Mute' (if I may call it that) would mean in the Parameter domain.

Confusion is NOW.   Confusion is "How the heck can I keep my existing work, create, try and judge an alternative, then either accept the alternative or revert to the original - simply, quickly, reliably, universally?".

From the programmer POV, at rendering time, it's merely  "if present AND enabled, then render", instead of "if present, then render".   Right?

I know the on/off option and the A/B option sometimes get talked about together, or interchangeably, and they are not the same, as you've pointed out elsewhere.    However, an implementation of the A/B option can be done so as to include on/off  (being one of either A or B).   This would be ideal IMO.

One huge A/B thing is also on the wish list: Tabs for multiple variants of an arrangement. You could send the current state of the arrangement to a new tab and A/B test simply by switching tabs. It won't be implemented anytime soon, though.

Understood, timeline-wise.    

Sure, this would be nice to have.  I'd be for it rather than against it.  There are many uses to which this could be put.

Two things though:

1.  It immediately invites the question,  "If 2, why not more than 2?".    If the Structure tab were to grow a drop-down menu that allows for variations of itself, yes, that would be quite powerful.  This is the sort of thing that OOP makes relatively simple to do.   Synfire is an OOP, yes?

2. Wrt. the current topic though, duplicating the entire Arrangement in order to test a local parameter A/B or on/off is not a very precise solution.  Such a procedure would be an unnecessarily complex global-level answer to a simple local-level question (A or B,  On or Off) that IMO deserves a simple, local-level answer, elegantly implemented.   ;^)

    

There is no place for a Parameter Erase tool to go. We don't have a toolbar for the structure view and I'd rather not add one.

OK, when we click on a Parameter the Structure view has an awareness of that parameter becoming "current", else it couldn't update the trace display.

So, given that the current Parameter is known, how about having a modifier key (e.g. Alt-, Ctrl-, etc.), while held down, turn the mouse cursor into a Parameter Eraser which will erase the current Parameter from any contain clicked on.

Zero UI footprint, super fast tool for doing the job.    

Anything not to like?

re: using the Delete key - 

Right now the unmodified delete key deleted the selected Container(s) itself.

To have Delete reach in and delete the current Parameter instead, we would have to use a modifier on the Delete key (e.g. Ctrl-, Alt-, etc.)    Yes?

The risk of accidentally leaving multiple containers selected when you are not aware of it is very low.

Well, it seems we just have different POVs on that.

Personally, as a developer (which I have been), I would give very high priority to protecting the user's work.  This is also what I prefer as a user!   

Nevertheless, "Let 'em learn the hard way" is another possible approach, and it is your product.

If, as a user, I'm asking for a capability (and I am), and the developer says OK, but you have to accept it with no guardrails or not at all  -   well, usually I will accept it rather than do without it.

So, if you are willing, bring it on - in the way you best see fit!  :^)