Stability issues

    Hi!


    I've been attempting to set up a performance over the last few hours and the experience has left me more than a little frustrated. Changes I make keep getting lost, the Rig Manager crashed a few times. The Kemper itself even HW-crashed once.


    After viewing the tutorial on YouTube my workflow is as follows:


    1. Make sure the Kemper is in "perform" mode or the "save performance" button won't show up.

    2. Use the GUI to find the rig I want.

    3. Edit -> Copy

    4. Select the performance slot.

    5. Edit -> Paste.

    5. Save performance in #8.

    6. Make adjustments to the newly added rig until I'm happy.

    7. Save performance in #8.


    My thoughts along the way goes something like this:


    1. Why is this even a thing? Why does the mode of the Kemper affect how the Rig Manager acts?

    2. Browsing works for the most time, but I am slightly worried what will happen to my last performance-slot. Does previewing a new one replace it?

    3. This is known to me. Familiar ground.

    4. Works as expected.

    5. What happens if the rig isn't already stored in the Kemper, but in the local library instead?

    6. Where exactly is my adjustments stored? Is it in the rig itself, or can I have multiple performance-settings per rig? Do I need to have multiple copies of a rig if I want to use it for multiple performances? Will me screwing up the settings also ruin the rig? Really wish the GUI would give me some pointers here.

    7. After saving I usually select the previous performance slot and navigate back to see that my changes were actually saved. More often than not, they aren't. It's even worse if I use the midi-controller to switch between slots. Using the midi-controller to move to a previous slot and back again often seems to "time travel" a few steps back and multiple adjustments are lost. Sometimes using the Kemper directly to navigate back and forth will fix the issue, sometimes not.


    The whole experience has caused the Rig Manager to lose my trust, and there is nothing more frustrating working with software you can't trust.


    Now I expect a lot you will say: well... bring that screen-recorder, report them issues and live happily ever after. Well I would, except that this software has been out at almost seven years now. Stability issues this serious really shouldn't be a thing at this point. I also suspect that a lot of the problems stems from timing issues and keeping state between two devices in sync. A difficult task at the best of times.


    I don't want to spend hours upon hours going back and forth with support.


    That does mean however that I'm not ready to make an effort.

    I want this software to be open-source!

    Give the community an opportunity to give back.

    Quote

    Stability issues this serious really shouldn't be a thing at this point. I also suspect that a lot of the problems stems from timing issues and keeping state between two devices in sync. A difficult task at the best of times.

    i suspect that is the real reason that CK fought the idea of an editor for so long. If you have a hardware system you only need to make sure IT works. Whenever you add software on a separate device you open a whole other world of potential problems.


    I feel your pain as I have experienced all of those issues myself and have reported them (including screen capture videos) but I also sympathise with the developers who have to deal with so many variables beyond their control.

    Having access to source code of RM would not change much, in my opinion. You could fix small thing in the UI, but majority of serious issues is somewhere between RM and the hardware itself, and to fix them you'd need access to the code running of units itself which for obvious reasons won't ever be published.


    Bugs, which are purely in RM are fixed rather quickly, once reported. Performance management is currently a disaster but I really doubt the issue is in RM itself. That would be easy to track down and fix.


    I would go even one step further and remove performance managment from RM (or move it only to beta channel) until it is ready for prime time. RM is great to tweak / load / edit profiles / IRs and it vastly improved my workflow. Once sounds are prepared putting a performance together on the unit is not that hard and works reliably. Not ideal solution but better than chasing bug after bug and falling into frustration.

    I must admit I would've been a lot more understanding had the performance-management been marked as beta-software.


    You really think this is a communication issue? My first instinct is that usb-communication is a solved problem. Perhaps not for the Kemper since it was added later, but the gig-part is working fine, so they definitely have the basics down.


    Do you remember when the performance-management was added? It being sort of new actually makes me a little hopeful :)

    I would take the total opposite view. Editing on the KPA is a breeze but performance management is the major reason to have RM in the first place. Without performance management I can't see any reasonable purpose for RM to exist.Getting performance management stable should be the number one priority (which I believe it is).

    Quote from piotrmaj

    majority of serious issues is somewhere between RM and the hardware itself

    I don't think so. The hardware of the profiler seems including it's software model seems to me very stable. I did not find any problems running the profiler alone; and this is also true for performance mode. In former days, before the editor came into it's beta versions, I did the whole editing thing with the profiler UI itself. As far as I remember, no problems besides the somewhat uncomfortable UI on the profiler.


    So, whenever I had real problems with RM editing and the profiler, I always had the impression that both memory models on both sides of this constellation are not very good in sync. There are some minor bugs, i.e. when you edited a name with RM that was not reflected on the Profiler. Then harder bugs, when you moved a performance profile to another slot, which also was not reflected on the profiler. Finally the hard bugs, when some editing on RM lead to a crash with the Profiler.

    So, my conclusion is: the software which tries to keep both sides (Profiler, RM) in sync might have bad structures, bad actings on UI events leading to false changes of memory models.


    Maybe opening the sources to the public could make this better. At least the code would get some controls by the guys here who often are software developers too. Kemper would not have to open source their hardware and drivers controlling this, but only the interfaces to the real kernel.

    By "somewhere between" i didn't mean literally USB connection, but rather I was referring to interplay between RM and hardware - something CarloLf better described as state management (which I have no idea where it is implemented). In the past there was only one source or changes - the Profiler itself. Now we have two sources of changes: RM and Profiler. Things can only be kept in sync if both sides observe same events in the same order. This is clearly not happening, RM and profiler are losing sync - and neither is detecting that the synchronization was lost (this is probably the first thing that should be addressed).

    Quote from piotrmaj

    By "somewhere between" i didn't mean literally USB connection, but rather I was referring to interplay between RM and hardware - something CarloLf better described as state management (which I have no idea where it is implemented). In the past there was only one source or changes - the Profiler itself. Now we have two sources of changes: RM and Profiler. Things can only be kept in sync if both sides observe same events in the same order. This is clearly not happening, RM and profiler are losing sync - and neither is detecting that the synchronization was lost (this is probably the first thing that should be addressed).

    Now this makes total sense. Exactly what I was imagining. The hell on earth that is keeping two sources of truth in perfect sync.

    Just for the record: read my post with a grain of salt. I have no clue how RM / Kemper work internally. I only draw this conclusions by observing the symptoms and also by excluding possibility of a trivial bugs, as generally I highly regard what CK and his team are doing (and I'm Virus TI user as well) and if the diagnosis / fix was simple they would just release the fix already. Maybe the ultimate solution requires a major architecture changes to the codebase which definitely is not a trivial effort.

    I totally. Agree. If this was simple they would have fixed it buy now. They are top notch people who know what they are doing and are dedicated to their product and customers. I suspect (like you I have no inside knowledge) that the issue stems from the fact the KPA was always designed as a stand alone unit. It is probably much more difficult to retrofit an external editor/database around a system that was never designed to need one than to start with a clean slate and build from there. If it can be made to work properly I have the utmost faith the the team at Kemper will find a way to do it.

    Quote from Wheresthedug

    the KPA was always designed as a stand alone unit

    Is this true? I am just a new user who came on board with Profiler Stage last october. But I thought, you always had the RigManager connected by USB with the Profiler. Sure, there was no editor for setting up the profiles. Anyway, there was a UI with the Kemper where you could do all so things with setting up a profile, managing it's effects etc. And as the profiler is a computer, there always was a kind of data model which was manipulated by user interactions, and the memory model had to have invoked the hardware layer. So what is really new, the RigManager needed to have, as I would suspect, the same memory model (data) as that on profiler which is representet as the UI interface shown as editor. Now, with the editor the obvioulsy hard task is to keep both models on sync. Just thinking about this, I do not see why this can be so complicated. This is a kind of a transactional replication task you find on my distributed systems.


    Maybe I miss something in this picture because I have no insights. But if I am right, I get the suspicion that the code is not very clearly broken up into small, good separated, manageable pieces which only are responsible for one dedicated task. At least, within the last months when each new release brought new bugs, did resolve some bugs on one edge but brought some know bugs back at another edge, leads me to this impression. Sorry.

    Quote from Wheresthedug

    it appears that V1.0 public Beta of RM was launched around Feb 2014 so I do believe it was originally intended as a stand alone piece of hardware.

    Sorry Wheresthedug, this is a contradiction. "A stand alone piece of" - not hardware! - but software, which was built to feed the "remote" device Profiler by USB-based communication? I understand, maybe they had a one way communication. Not sure about this.


    Maybe ckemper can clarify this (if it is not too hot to handle)?