I guess it gets complicated when you tweak from there. But maybe a * next to the name when it happens. Or?
I also get a bit frustrated by this and having to go into edit mode just to see what I've got.
Totally, 'Hookster.
Seems we have the same preset beefs, you and I. Mainly this, the scrolling thing and the character-number limit. That said, the "smart presets" we discussed recently would be super-useful, where we're given the option to load updated presets with Rigs or simply the ones already contained therein. It'd have to be a soft-button implementation I reckon 'cause it'd be something we'd likely change frequently on-the-fly whilst browsing.
For now 'though, a huge +1 for being able to see preset names after they've been selected and used.
We try to keep Rigs compatible and interchangeable (Rig Exchange, Rig Packs,...). A reference to an Effect Preset is only relevant as long as
- no related paramater gets changed in that Rig (tweaking Delay Mix via knob or remotely or changing on/off-state could already break the logical connection to the Preset),
- nor the Preset gets deleted or another Preset gets created with the same name,
- and what if you import a Rig and the related Preset doesn't exist in your Browse Pool or includes different settings.
We try to keep Rigs compatible and interchangeable (Rig Exchange, Rig Packs,...). A reference to an Effect Preset is only relevant as long as
- no related paramater gets changed in that Rig (tweaking Delay Mix via knob or remotely or changing on/off-state could already break the logical connection to the Preset),
- nor the Preset gets deleted or another Preset gets created with the same name,
- and what if you import a Rig and the related Preset doesn't exist in your Browse Pool or includes different settings.
I am not following your reasoning, but I will try to respond.
1) In a website such as this, my avatar is represented by only one file. The website does not create a copy of my avatar every time a page or post is created that my avatar is displayed on. (well, yes, I know that is not exactly right - but the display copy is not a persistent copy that resides on the website hard drive - the copy/copies are on the system that displays the webpage). So, if I went in and made my hair black (tweaking a parameter), and saved it to my avatar file, that still would not create a new file, and it would not break the link to my avatar and my black-haired avatar would show up how ever many times necessary without having to create a new copy every time. On a page where I have made multiple posts, there are not multiple copies of my avatar on the file system.
2) In any other file system, I cannot create multiple files with the same name in the same directory. If I try, the system will tell me and ask me to use a different name, or to overwrite the first file with the name. If the preset is deleted, an error would show where it was expected. If it were overwritten, the new preset would show where it was expected.
3) If the related preset didn't exist, I would expect the same or similar behavior if someone accidentally deleted my avatar from the website - some sort of message/icon/placeholder that indicates that there was a file reference there, but the reference file is unavailable. an X. something like that.
This is not new stuff - its been standard user experience on personal computers and other file systems for a long, long time. Honestly, as far as I can understand it, this way of handling files and file relationships should not preclude Rigs from being compatible and interchangeable, or cause any problems. At the very least, it prevents unnecessary duplication and replication of files that causes confusion with users such as me, and creates file management nightmares (multiple files with the same name and trying to figure out what is what) for users such as me.
Does that make sense @Burkhard?
Enabling editing of Presets is one thing, establishing fixed relationships between Performance, Rigs, and Presets is a different matter as well as unique names.
Enabling editing of Presets is one thing, establishing fixed relationships between Performance, Rigs, and Presets is a different matter as well as unique names.
If we think of effects and stomps as literal physical stomp boxes, the Kemper method of managing them means I have about 30-40 of each stomp box I use laying around my studio. Maybe more. If you start with the preset, saved versions of the preset, saved stomp & effects bank presets, rigs that use either individual or bank presets, etc., I literally have over 50 different copies of the Green Scream alone. Multiply that by the various different effects/stomps I use and we might well reach 1k. Basically every time I tweak or incorporate a preset, it has to be saved as a new file. Is that logical, efficient file management? Is that conducive to logical organization?
At least in the physical scenario, if I have (insert whatever number above one here) Green Scream pedals that are loose (not on a pedal board), I can label them with tape so that I know what each one is set up for without having to figure it out from how the parameters are set up. When using presets on the Kemper, I don't even have that option - once that preset is incorporated into a rig, I don't have access to what it was named - no label can be attached. I have thought about keeping a note book or spreadsheet to keep track of this sort of thing but that really defeats the purpose.
I'm just as, if not more, tired of this subject as you probably are. I've done everything I can think of to creatively solve the issue the current way of doing things creates for me. If you really do understand what I am saying but you are telling me its impossible to fix, just say its impossible. If you are telling me you may or may not see the merit of fixing it, but for whatever reasons, you are unwilling to change things, just say so.
My impression is, you don't want to see the limits of your suggested approach. Let's assume you load a Delay Preset X into Rig Y. At that time the Rig Y could include a reference to Delay Preset X. So far , so good. But as soon as you touch any parameter within the Delay of that Rig Y - and one parameter is the on/off state which is included in a Preset, another parameter is Delay Mix, another parameter is Effect Type or any other of the many parameters of that Delay - the Delay in Rig Y doesn't equal the Preset X anymore. From now on a reference in Rig Y to Preset X would be meaningless and misleading. I think, practically, such references might have a very short live time.
Let's imagine a completely different philosophy and approach: All data is referencing. Performances are referencing to Rigs included in their Slots and Rigs are referencing to Preset used to build those. Now, when you change Delay Mix in Slot 4 of Performance 3, the Rig in the Browse Pool originally loaded into Slot 4 adapts to this new Delay Mix as well. All other Slots in other Performances this Rig has been loaded into adapt to this new Delay Mix. Other Rigs in the Browse Pool the same Delay Preset has been used for adapt to the new Delay Mix. Effects and Stomps Section Presets this Delay Preset has been used for adapt as well the new Delay Mix. All other Rigs, Slots, Performances any of these Presets have been used for would follow and change their Delay Mix. So, with the change of one parameter you might modify a huge number of Presets, Rigs, Slots and Performances. Keeping oversight over the implications of such a minor change might be impossible. And if you delete one of the elements (Rig, Preset,...) it could break relationships. I don't think, this is a practical approach either.
Personally I see benefit as well as potential harm in both approaches.
Why not make it user selectable if a tweak to a parameter in a performance will be reflected in its core profile or not?
To be honest I'm afraid that such a mixed environment of
some Performances/Slots are referencing to Rigs, others are not,
some Rigs are referencing to Presets, others are not,
some Section Presets are referencing to Module Presets, others are not,
some Module Presets are referencing to Section Presets, others are not,
some Presets are referencing to Rigs, others are not,
some Rigs are referencing to Performances/Slots, others are not,
and if any of these data elements gets deleted the relationship breaks,
is a complexity nightmare and potential cause of total confusion.
I'm probably describing the most complex approach here, but a mixed approach of only Performance referencing Rigs or only Rigs referencing Presets doesn't make it more consistent nor intuitive.
Sometimes less is more ….
Display MoreMy impression is, you don't want to see the limits of your suggested approach...
(snip)
I don't think, this is a practical approach either.
Honestly, I believe I have seen the limits of my approach in other media and am happy to provide further examples if you need them?
But... the point is that this is the current, standard approach for almost all other computer/digital file systems that exist, isn't it? The reference points back to the original file. The reference should not need to create a copy since it is a reference. If I choose to tweak the reference, it should ask me if I want to save the changes to the original or create a new version. If I want to change it at any location, THAT is when I create a new version - I don't need to create a new version each time I reference the original. I don't need a copy/new version until I need it to be different.
If I delete a file, an error should show up anywhere that it is referenced. Its simple, elegant and it works. How is that not practical? It works in printing/page layout applications. It works in web development applications. Why is the Kemper so different?
@Burkhard Sometime last year I believe I chimed in on this very subject. I never received any explanations why this could not be done. I now do see why this could get complicated, though I see the merits it could yield.
But I also suggested a simpler method of at least scrolling through the hundreds (or thousands as in the case of @flyingheelhook) of effects available (including user effects we create). In the latest OS update you wisely have added the ability to browse using 'Pages' in Performance mode (a wonderful addition by the way! Thank you, thank you). I would propose adding the exact same capability to the Browse knob in 'Effects' so we can much more easily find what we're looking for. I would also propose putting effects listed using the "Type" knob in alphabetical order for similar reasons.
I'd love to hear your feedback on these practical suggestions. Thanks for all that you do!
