Posts by pippopluto

    Hey waraba, this is not what this FR is about :)
    I use the octave down function(s), but those easily mess up with clarity with cleaner sounds, chords or fast arpeggios.


    With a little research, I found I am not alone in this request. Not only the function has already been requested (here), but methods aimed at getting the same results have been discussed (here).


    This is true not in the Kemper realm only: one of the first entries I've found in google was this.



    What I find a bit weird is that on both Kemper request threads there seem to be lots of suggestions about buying/using different hardware in order to get what the OP is requesting :p
    In my mind, people start threads in the Feature Requests section because they are requesting some functions to be made available within the Kemper ecosystem. Granted, sometimes what the OP requests can be already made, and suggestions are more than welcome in those cases. OTOH, when the suggested solutions imply drawbacks (such as slots wasting (we don't have plenty, do we?), third-part hardware purchase, sonic compromises...), the request does make sense.


    Naturally, we all have to come to grips with the fact that most requests just can't be satisfied for the most diverse reasons. But, as I wrote, I believe that the function discussed here would certainly be used more - say - than effects such as Vinyl Stop
    :)

    Meh! Give it six months and they will release the new FM3 plus. Its newer and shiny and not backward compatible with older units.

    This doesn't seem to be the case, actually: CC stated that FM3 complies with Fractal's new modular architecture. I don't know much on the matter, but I grabbed that this environment is populated with compatible, modular, same-fw devices.

    I've tried to fight this battle also pippopluto . I hate to say it, but I think its pretty pointless even though our expectations that the kemper should manage files like almost every other known file management system under the sun are sound, and our logic on how and why we expect things to behave a certain way is pretty much flawless. You have my support, fwiw.


    Yep, I guess any user has to take into account the perspective of their needs\points of view not being accounted for. There are various reasons for this of course.


    Anyway, to me, there are 3-4 things in the KAOS-related user experience I'd have had different from scratch, and find illogic or not practical, outside the subject of this very thread.

    At least, it seems we are going to have a (hopefully) complete and coherent presets management facility in a few months :)

    the Profiler in its current incarnation has reached a level of complexity that I start to hope for a Profiler MkII. The beauty of the beast was it's simplicity. Many additions were very welcome (and continue to be welcome). But I'm afraid the first iteration of the Profiler has reached a point where it becomes increasingly difficult for newbies (or less than power users) to fully understand this beast.

    I hear you re: complexity!
    OTOH, IME the (by far) reason why people don't understand the KPA is just that they dont read the manuals.

    How can you go on asking "is there a way to exclude the cab simulation for monitor but send it to FOH at the same time?" again and again for 8 years?! LOL


    I've chosen this specific question among the more repetitive ones to pick a function that has been there basically since forever :p

    I of course agree that the soon-to-come presets management will be a huge improvement over the current one. It will be the way it should have been since day one, if I want to be honest :p


    Among other things, the new RM will also finally allow a decent management of the Cabinets, which has always been a royal PITA! (I have over 600 presets waiting for a reasonable management facility).

    I surely hope the new functions overall will allow to easily manage and store as physical files the presets (cabs included) in a much more practical way.


    Martin, I know what you mean when you talk about "Aqualong*" Vs. "EndlessAmbiance" :D

    But there's a flaw in the vision this hints at, which I see in Burkhard's line of reasoning as well: the idea that the user is a bit dumb :p

    For me it's obvious that, when at the point that Aqualong* becomes EndlessAmbiance, I am going to save it as a new preset. Also, chance are that Aqualong doesn't get tweaked t all.


    In deeper detail: even dismissing my tentative "object-based" metaphor (see my last long post), I nevertheless find useful to know where a certain preset came from. In most cases a preset is tweaked but not revolutionised (otherwise I'd choose another one, or create another one (for example, by saving my tweaks)), so I find interesting (and I would have liked in real use) to know where the hell I had found a given setting, maybe a week or a year late.


    Again, the need comes from the fact that there may be 6 pages of parameters in a given effect type; if it was a matter of turning a couple of knobs I'd be the first going by ear.

    Use case: I'm working an a set of very ambient, Gaelic-like songs (like The Gladiator theme). I found a delay type that is perfect for my musical idea, but edited it for each song. OTOH, I like to use sounds that refer back to a same archetype, in order to give the songs a nice inner coherence (I do, as a matter of fact, use the same settings in all other effects)

    Each rig's delay offsets a bit the original preset. Granted, when creating the rig for the next song I could just copy any instance of the delay and re-tweak from there, but as said I prefer to start from the original preset so that any song doesn't diverge much from a given feeling (the feeling I loved and liked when first auditioning the original preset I chose).

    What I currently do is just writing the name of the original preset on my music sheets, but I really believe there should be a more consistent, technological solution.


    Another way to manage this would be as follows: when the effect edit screen has the focus and I turn the Browse know, what's currently shown (KAOS 5.7.7) is the last loaded preset, no matter whether I am in the same effect module or in a different one.

    Would it be possible that what gets shown, instead, is the last preset loaded onto that specific module Burkhard ?

    This would basically solve the issue and make everyone happy? :)


    Happy as Easter, of course :D

    The key word was “alleviate”

    :D


    you get confused by the sheer numbers in its current form

    This is certainly at least partially true.
    Nevertheless, Aqualong* still looks a very practical and useful idea to me.


    Stimulated by Burkhard's questions, in my previous (long) post I was trying to "design" a coherent approach in which saving the (morphed) identity of a preset made sense. It was an hypothetical scenario that just tried to "go beyond" so to speak, and show how a coherent implementation of the "preset object" would possibly be conceived. But that is no way what my feature request is about :)


    Anyway, from the scarce participation to this thread, it looks like I am among the few who feel uncomfortable with the current KAOS philosophy.
    This is weird, because this limitation gets raised quite often here and there, and I have certainly read it several times.


    Happy Easter everyone :)

    this makes me think about all of the posts asking for specific FX to be provided in the Stomp Types. There are lots of cases of users asking for models of specific OD and Distortion pedals such as Klon or TS808, TS9 TS8 etc. In reality the Kemper model seems to be to create a TYPE which can be tuned to be many things as the range on variables is far greater than the analog world would allow. Therefore, the same OD TYPE can be any variable of Tube Screamer or TS derivative the user wants by setting the controls appropriately. In the Kemper mindset this is a TYPE. However, in the mind of users it isn’t the effect they want and they keep asking for more “improvements“. If you provide presets labelled TS8, TS9, etc people think they have the effects they want. That’s just the way most peole think even thought the it might not be logical.


    Hey Alan, this is basically what I perceive happens, too.
    In the case you mentioned, tho, there might be some technical issues: not necessarily a Kemper Type is able to be shaped so to sound like a given pedal.

    But I agree, in general, that on the average the guitar player is not really skilled in shaping a complex system (a Type I mean) and make it sound the way they want.


    In fact, I agree that Kemper would spend quite a rewarding time by providing a. very versatile Types (including distortions etc) and b. very realistic "the-real-thing" presets.

    If you find an FX setting you like in a Rig, create a new Preset. You can use a name that references the Rig that contains the FX setting, if you like. That would enable you to build a library of FX presets that are useful to you.

    Thanks Paults for chiming in :)

    What you suggest has nothing to do with this feature request tho, which relates most with traceability.



    Thanks for your detailed response!


    Thank you Burkhard for getting the time to discuss this :)


    I guess by "module" you refer to an effect slot, right?

    These questions are taking us more into the coding of the KPA's behaviour, so I run the risk of talking about things I don't know. But I'll get them, for the sake of discussion! Please forgive me if I assume something wrong.

    I also realise that, with the new features announced at NAMM there will be the need to establish a closer (strict?) relationship between Types and Presets, because IIRTC the latter will be listed under each preset. So I'll have this a a reference.


    I see a preset as a sort of not-inheriting object, which should not be related to the slot where it gets loaded, but only to its Type (from what you wrote in a previous comment this seems to not be the case, but I don't know enough to elaborate on this).


    So to analyse the cases you're suggesting, and keeping the Aqualong metaphor:


    I don't know code-wise whether all the presets must exist in the Preset Set, or a preset can exist in a Rig only. I believe that, if we give presets the status of entity, we couldn't have a preset in a rig which doesn't appear in the Set as well. Of course this implies decisions to be taken at coding level, which is not my competence, even tho I do have a vision.
    Coherence and consistency would suggest that, if presets were to be entities:

    • the user can't delete a preset if they have rigs that use it (a warning message appears that specifies at least the number of rigs that use it);
    • importing/loading a rig that uses a preset implies the automatic addition of the preset to the Presets Set;
    • if no rig uses Aqualong, when deleting it the System would ask a confirmation whether to delete its children Aqualong* as well;
    • if the user edits Aqualong by changing the effect Type, a new Aqualong* preset is created under the other Type cathegory (of the same Family: Delays, Distortion ecc.);
    • if the user changes the Type of effect in a preset outside the Family of the Type (i.e., it was a Delay but now they load a Flanger?), consistency would suggest that a new preset is saved nevertheless under the correct Family and Type, but it doesn't gets deleted if the original Aqualong is deleted, because the Family has changed as well;
    • so we can have several Aqualong* instances (Aqualong001, Aqualong002 etc)under several Types and Families. This seems coherent and should not introduce any ambiguity; on the contrary, the newly-implemented hierarchical visualisation would show that there are (if ever) several instances of Aqualong, under several Types and in several Families. There would be differences and affinities among them, but the System recalls and shows that they have an ancestor in common
    • For consistency, editing Aqualong001 would generate Aqualong001001 (this nomenclature is of course just an example).

    Hope to non have forgotten anything, and to not have written some resounding idiocy.

    I did not take the time for a serious and consistent study, and there are too many coding aspects I have no information about, so I may well have overlooked something obvious or written something impossible to implement without re-writing the KAOS from scratch (LOL).

    Nevertheless, whether this request is received or not, hope I made my vision clear.


    Thanks for listening, it's bee interesting anyway :)

    What would be the real value of the information "Module A with a Wah Wah is based on the preset "Wah Cry" but has been modified"?


    I am realising that your approach to the matter starts from the idea that guitar players choose (or better, set) an effect looking at its numbers, with a great awareness of what each parameter does. Like "mhhh... Grit at 5.6 gives a bit too much mid-highs... and doesn't cope well with Feedback at 34.8... I'll lower it to 5.1". This is how an engineer thinks, but the average digital user thinks in terms of sound, specially in a 6-page kind of effect (try and set a complex Delay with totally different parameters: there's no way - generally speaking - that the average user can tell it's the same Type (Vs a different Delay). For this reason, Aqualong becomes (in fact, it is) in the user's mind a label that refers to a specific tone, just as if it was a kind of effect.

    Again, this would most probably be less critical if the various instances of the same effect coudn't sound so differently from each other. A device must follow the way the user thinks IMO.


    To answer your question, IMO it's a matter of order, rationality, and practicality.

    As I was trying to convey, the value lays in the fact that, since presets may sound really different from each other (and from the default settings the bare "type" comes with), I will know where to find a similar sound in the future. I have maybe modified Aqualong because there was something that needed to be adjusted for a specific rig, but I may (as we - requesters - in fact do) want to have the original preset available for other uses.

    Sure, I could just refer to Aqualong* and start from there, but I'd like to have a stable reference to start from, so that all the possible variations the original. Also, if I see several instances of Aqualong* in different rigs, I know at a glance that they were just different version of a same general setting.


    The preset "Wah Cry" could have been deleted in the meantime. Or in that new software revision you could have modified and replaced that preset. Or the Rig could have been exported/imported to another PROFILER, where that preset doesn't even exist.

    Yep, you already wrote this. But, again, these are cases of no consequence: I see no drawbacks, since Aqualong* would be nothing but a further label, like any other preset. OTOH, if the guideline was based on this, we would sacrifice the practicalities as I discussed in the previous paragraph.


    Please don't insist to use presets as pseudo types.

    Well... with all due respect, a user does what they want with their device :)

    The KPA's interface and functions have been modified a lot since KAOS 1.0, and many of these modifications have been driven by users, as you guys usually point out.

    This means that there are people out there that don't think the way devs did when they conceived the unit and its functions. I don't see this as positive or negative, it's just a matter of fact.

    So, it happens at times that users "insist" in trying and use a device in a way that it was not originally designed for.

    I am of course not stating that the functionality I am requesting should be implemented just because I'd like to see it: I've been several times hearing it is missing from others as well.

    Of course we can disagree on its utility.


    Thanks for your time!

    Thanks Burkhard for responding and for your observations.


    It seems that the main need of those who are asking for the possibility of identifying the (original) preset (not only on this forum but elsewhere as well) would be: For goodness' sake, what preset do I use on this rig?!


    Of course any feature implementation would require some change to the code.

    For instance, the status of the preset could be excluded by the elements which characterise its identity; this would allow to still see its name while not edited. But there's more.


    You will agree that presets (may) sound very different from each other, even when coming from the same Type of effect. The majority of the users, IME, approaches presets as if they were different effects. Apart from my personal (and of those who have been asking for this feature) feelings on the matter, there are proofs of this mind approach: for example, when reverbs were last released, and you had to loaf factory contents in order to get all the presets, loads of people kept asking (from all over the world, literally!) "I can't see the new reverbs, did my installation go wrong?!" again and again ;)


    Granted, if you change- say - Grit from 3.5 to 3.6 it's not the same preset any longer; but it sounds the same nevertheless :) It's the same effect, in my mind.

    So, I can confidently state that it would make sense (in the mind of the average user) to just change the (still-to-be-implemented) displayed name of such preset from - say - Aqualong to Aqualong*.


    What if Aqualong gets deleted? Nothing: it doesn't exist anywhere (in the KPA, but I can retrieve it again if I need) any longer, but I have a living instance of Aqualong* in the unit, stored in a rig, and I can save it as a preset (hopefully with a name of my choice).


    Should all this be referencing? Well, this is a completely different issue, that responds to totally different needs which are not part of this feature request. I am aware it has been long discussed not only here but on every forum I follow. I would note tho that the asterisk'ed name would become a different preset, which would/could be independently inherited and treated as any preset should the referencing feature be implemented.


    I believe the feature I am suggesting does keeps thing very simple, and adds a lot of information: you have used the Aqualong preset here, and this is a modified version of it. You can save this version, if you want, or reverse back to the original version by just loading it.


    I have been thinking over about this feature request, and I was not able to see any drawback.


    On a funnier side of things, I believe Kemper is not the more credible firm when it comes to any sentence which starts by "I'm not aware that any other comparable device offers..." :D

    This things comes pre-loaded with FW for the Profiler. USB-powered or rechargeable (USB) batteries...
    Had never heard of it!


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Yep, I am aware of the issue. They might allow the preset name to show as long as it's not been edited.


    As a side note, when edited, they might just for example append a special character to the name, such as an *, and maybe offer the option to automatically add this name* to the presets list the same way it works for rigs with the "Automatically add to favourites" switch.