Anybody else finds editing snapshots a PITA?

[grdGo33]

Just curious if people think that editing snapshots on PGO edit is far more trouble than it should be? 

 

IMHO, the way snapshot editing should work is that by default, you should be editing a 'base' patch, like 'global' patch settings.  When editing this base patch, changes would be applied to ALL snapshots.  Alternatively, you could edit a particular snapshot.   So, if you switched to patch 1-4, any/all changes should be applied only to the snapshot.  None of that assigning 'snapshot' to every single parameter so that it changes the param value only for this particular snapshot...  It would be automatic.  To edit a value for all snapshots, simply go back to global/base patch, and overwrite all snapshot param value.

 

Would seriously this not be way more practical?  I can't count the number of times I forgot to assign a parameter to 'snapshot' and ended up messing up the settings for ALL the other snapshots...  The only logic I can see behind this design is that PGO Edit has to be somewhat compatible with editing directly on the Pod, but yeah, this simple change would make editing snapshots so much better...!

[silverhead]

Interesting suggestion, and I can see how the concept could seem to simplify snapshot editing. But the devil is in the details as far as implementation is concerned. The changes would have to make sense within the current device architecture so let’s talk about this in the context of the architecture. Each preset holds sufficient memory space for 4 versions of the preset with up to 64 variable parameters. Anything that would require a change to that simply ain’t gonna fly.

 

So first off, your base/global preset would have to (presumably) be Snapshot 1, leaving 3 editable snapshots. No problem so far. Anytime you want to make a change to the base preset you simply need to make sure you are in Snapshot 1. But that requires the user to be aware of how things work, and be intentional about it. Right there, you have to deal with the other side of the ‘practical’ coin you mentioned where you mistakenly made a change to all snapshots when you only wanted to change one but forgot to do something first (assign the parameter to the Snapshot controller). Now you could mistakenly make a change to a parameter in only one snapshot when you intended to change it for all presets but forgot to do something first (activate Snapshot 1). So what’s the gain in practicality? Problematic to justify when people are already used to how things work now. Would cause a lot of confusion for dubious gain.

 

Secondly, how would you deal with the 64 parameter limitation? Currently the Snapshot Controller assignment provides an indicator of the parameters assigned. I think you’re suggesting to do away with that. Conceivably, your parameter edits in Snapshots 2-4 could exceed the limit - and you would have no indicator to show you which 64 are being used. What to do?
 

Personally I’m not sure it would be any more practical or intuitive. Either way you need to understand how things work and act accordingly.

 

Edit: re:64 parameters. I guess Line 6 could leave the indicator in place and just make the indication automatically each time a parameter in Snapshot 2-4 is changed.

Edited September 4, 2022 by silverhead
Followup thought

[grdGo33]

On 9/4/2022 at 4:55 PM, silverhead said:

So first off, your base/global preset would have to (presumably) be Snapshot 1, leaving 3 editable snapshots.

 

PGO edit is external software though, so it doesn't need to be matched 100% with the Go's Architecture, as long as the end result is.  So, you could have global/base 'snapshot' that does not exist in the Go device; simply exists in memory space of the PC.  This base settings would then be used to change the base values and reset the 64 variable parameters of each snapshot.  Ex;  SS1 -> Gain 2.0, SS2 -> Gain 5.0, SS3 -> Gain 1.0, if you set the Gain of the base to 4.0, it would effectively change the 'base' Gain to 4.0, and remove the Gain param of all the snapshots.

 

And yeah, looking at a .pgp file, looks like that seems to be exactly how it works internally; 'base' settings for all blocks, and 4 lists of parameter values for each snapshot.

 

In the GUI, in the base settings, the params which are modified by snapshots could be in red or orange, just to highlight the fact that modifying this value would reset snapshot values to this value.

 

Quote

But that requires the user to be aware of how things work, and be intentional about it. Right there, you have to deal with the other side of the ‘practical’ coin you mentioned where you mistakenly made a change to all snapshots when you only wanted to change one but forgot to do something first (assign the parameter to the Snapshot controller).

 

Yeah, using background colours, large titles "BASE SETTINGS" vs "SNAPSHOT 1", it could be very obvious where you were. 

 

Quote

So what’s the gain in practicality? Problematic to justify when people are already used to how things work now. Would cause a lot of confusion for dubious gain.

 

It's much more practical IMHO to open Snapshot1 and then edit Snapshot1, rather than always being in snapshot X, and changing settings changes settings for all snapshots, unless you manually set the controller to 'Snapshots' for each param you change...!  Just explaining the existing logic is painful...

 

Quote

Secondly, how would you deal with the 64 parameter limitation? Currently the Snapshot Controller assignment provides an indicator of the parameters assigned. I think you’re suggesting to do away with that. Conceivably, your parameter edits in Snapshots 2-4 could exceed the limit - and you would have no indicator to show you which 64 are being used. What to do?

 

There would be no change for the 64 params.  You could still display in white under each snapshot the snapshot values.  If you run out, you could easily go back to Base and change a value currently set by snapshots.  Ex; 64 used, you go to base, change Gain to 4.0, it resets the snapshots, and if I understand correctly you're now using 63 and can choose a different param to control with snapshots.  (Could also have a right click, 'reset to base' under each snapshot)

 

Again, under the hood; it would work the exact same way as now.  This would really be a PGO Edit only modification, nothing to change on the Go.  It's just an intermediary step difference, but end result to the Go is the same.

 

Quote

Personally I’m not sure it would be any more practical or intuitive.

 

Yeah IMHO, far more intuitive to be in Snapshot #1 and edit Snapshot #1, rather than being in Snapshot #1 and having to set a controller for every param you're changing for Snapshot 1...   Maybe it's legacy from earlier L6 products and long time L6 users are used to it, but from a software design point of view, it's really just quirky / dubious design...

 

Just the "explain it to me" makes it pretty obvious!  Existing logic is really kinda twisted, and you really have to wrap your brain around the;  even if you're editing SS1, you're not really editing SS1 unless you set a 'snapshot controller' because otherwise even if you're in SS1 you're editing the base settings.  VS, base you're editing common base values, and under SS1/2/3/4, you're editing value for that particular snapshot.  Just so much simpler!

 

There's just so many improvements that could be made to PGO Edit...  It really would be great if L6 would release some sort of open source PGO API where users could improve software themselves!

[silverhead]

I’m not persuaded but don’t want to debate it. There may be others who share your opinion on this. Why not post the suggestion on Ideascale? 

[grdGo33]

On 9/4/2022 at 9:07 PM, silverhead said:

I’m not persuaded but don’t want to debate it. There may be others who share your opinion on this. Why not post the suggestion on Ideascale? 

 

I'm cynical, so doubtful it would change anything.  I was mostly curious if other users thought it was as much as a PITA to use as I do. 

 

Maybe I'll re-check it out, last time I tried posting I couldn't due to account validation.  But honestly... I have zero faith, so the only motivation I would would be rather embarrassing and puerile; à la "See?  I knew it wouldn't work..."   :/