Zone parameters are not propagating edits to the current selection

[ztnl]

While double-clicking on a group appears to select all of the component samples, it is then not possible to apply a velocity crossfade to all samples in the group, but only one at a time...

...

EvilDragon
—
7:13 AM
double-clicking the group when in GROUPS pane will select all zones in that group
jl
—
7:20 AM
Must be missing some critical detail. Can only get it to x-fade on one sample at a time...
Image
Dbl-clicking on the group seems to make no difference.
EvilDragon
—
7:21 AM
that's a bug
jl
—
7:21 AM
Same for either of the groups here...
Image
EvilDragon
—
7:22 AM
add it to the issue you created for mouse gesture to set up the fades
jl
—
7:22 AM
Ok.
EvilDragon
—
7:23 AM
actually hold on
this is a separate issue. ALL the zone params in the right hand pane there (root, low/high key, etc) are not propagating edits to all selected zones. they should
jl
—
7:24 AM
Create a new and separate issue then?
EvilDragon
—
7:24 AM
yup

[mkruselj]

Here's some expectations on various gestures and behaviors here:

• Dragging the edges of a leader zone should apply relative edits to other zones in the selection. Constraints need to be applied so that low must be < high for all secondary zones in the selection, which can in some cases end up in them becoming 1-wide/tall. This is fine.
• Value edits should always show data from the leader zone.
• Dragging the value edits should behave as if you dragged a zone, relative edits.
• Typing in a value should apply absolute edits to other zones in the selection. Constraints also need to be applied.
• Typing in a value prefixed with - or + should apply relative edits to other zones in the selection. This makes sense for key/vel ranges and key/vel crossfades. For parameters which are already bipolar (pitch bend, volume, tuning), it gets trickier. + could still apply a positive relative offset, but what do we do with -? My suggestion is to also allow a secondary prefix character, =. So if you type =-3, this would subtract 3 from pitch bend which might already been set to -2, say.

[Andreya-Autumn]

Ok. I read the convo on Discord and here's my two cents.

Ahortcircuit XT without multi-zone boundaries/fade editing at all is still 10x more interesting and useful than anything comparable, to pretty much anyone. And of course, ∞x more interesting to literally anyone than if they haven't heard of it in the first place because it's not released.

I don't mean to say it ain't worth the trouble at all. But I feel absolute edits definitely can wait.

• The situations where they make intuitive sense are way rarer than those where relative edits do (like that Kontakt screen you showed on Discord ED).
• As Paul points out, they are not easy to implement.
• Even if they were, without undo they are really dangerous for the user.
• Thus we should probably not have them until we have undo.
• Undo is also not easy to implement.

Hence I propose before beta we do the first three of ED's proposals above, and maybe the last.

[Andreya-Autumn]

The exception could be the volume/tune/pan/keytrack ones params. For those, absolute is easier. And a little less crazy dangerous maybe. But I suppose if we're doing relative for the others anyway we may as well do for these also.

[mkruselj]

To me it makes no sense to pick favorites which ones should do the absolute thing and which won't.

I disagree we should wait for undo before absolute edits are in. A modicum of discipline (and saving variations somewhat regularly) when editing the mapping can make up for the lack of undo.

Shortcircuit XT without multi-zone boundaries/fade editing at all is still 10x more interesting and useful than anything comparable, to pretty much anyone.

Context matters, and what you like to do with a sampler might not be what "pretty much anyone else" might want to do with it. So I wouldn't generalize like this. Multi-zone boundary/fade editing is a very basic gesture that is expected to be there in 1.0 I'd say, based on my experience with other virtual samplers from their early days (none of them had undo at the outset, for example, but they all had absolute edits - I'm not saying this is how things should be or that we can't do better, but statistics are pretty damning in this case).

[Andreya-Autumn]

I don't disagree, but remember, our plan is "get to beta at all costs". A bunch of beta testers telling us this is the what they miss most sorely would confirm your intuition that we must get this all for 1.0. I'm not saying I know that won't happen but I am saying it's not obvious that it will.

Again, I'm not opposed to doing the relative multi-edits before beta. Just the absolute ones.

It makes total sense to "pick favorites" IMO, and here's why: The proc and mod multi-edits are already mostly working now, and are absolute (with the "different proc types" warnings).
Zone boundary/fade/root multi-edits OTOH don't work at all yet. We can make them work in a relative manner reasonably easily. But on these controls uniquely, absolute is both a way bigger refactor with large potential for logic errors etc, not critically useful (it seems to me), and adds more of the danger that requires the discipline you mentioned. Which makes me think it's counter to the overall strategy we agreed on last week.

If there's some case I'm missing where the absolute multi-edit type-in is really that critically important I may change my mind! But my intuition is if we get to beta with zone boundary edits being relative only that's totally fine.