Questions about the 625 Performance Mode rigs

    I'm thinking about switching to Performance mode, since it is an easier way to assign rigs to MIDI program change numbers, and a much easier way to reorganize sets of five patches.


    Has anyone looked for the Performance rigs in a backup file yet?


    Are the 625 Performance Mode rigs saved in a backup directory as individual rigs?


    If not, can a Performance "version" of a rig be saved to the Browse pool, or as a snapshot? There is always a chance of wanting to keep a particularly good sounding set of tweaks:)

    The performance rigs are not stored as individual rigs but as Performance files including up to 5 rigs each.
    The Performance files have the suffix *.kipf and don't have "human readable" filenames. Instead the Performances 1 - 125 are stored as 0.kipf - 124.kipf (just to add a bit to the overall confusion, hehe).

    Does changing the filename reassign the assigned slot when imported back to the KPA?


    A .kipf file could be renamed to the songname after backup and then archived. It could then be renamed back to the new slot# and restored during set arrangement. It would be really easy to create a "setlist manager" software to automate this task.


    bd

    Quote from lightbox


    I'd like to make all users and Kemper staff aware of the above anomaly.
    Seems like even Kemper staff (Burkhard) aren't aware of this nasty mismatch of Performance number and filename.


    Yes, and I'd like to convince Kemper staff to add:
    1) exporting Performance Rigs in the USB
    2) a way to easily extract from the BACKUP file the Rigs stored in the Performance
    3) a way to import/export single/more Performances as we do with the Browse Rigs


    What do you think about this?

    Quote from lightbox


    I'd like to make all users and Kemper staff aware of the above anomaly.
    Seems like even Kemper staff (Burkhard) aren't aware of this nasty mismatch of Performance number and filename.

    Not really an anomaly. Pretty standard MIDI patch numbering scheme. If there's a beef it's really with the people who wrote the MIDI standard 35 years ago or whenever....

    Quote from examiner

    Not really an anomaly. Pretty standard MIDI patch numbering scheme. If there's a beef it's really with the people who wrote the MIDI standard 35 years ago or whenever....


    I disagree with your statement. If it was something to do with MIDI (or let's just call it binary) numbering, then it wouldn't have been a problem to start the Performance Index with 0 as well. It's a fact that the difference between Performance Index and filename is confusing. Even Burkhard (a Kemper employee) got it wrong in the german language thread.

    Quote from lightbox

    I disagree with your statement. If it was something to do with MIDI (or let's just call it binary) numbering, then it wouldn't have been a problem to start the Performance Index with 0 as well. It's a fact that the difference between Performance Index and filename is confusing. Even Burkhard (a Kemper employee) got it wrong in the german language thread.


    Indeed this comes from the MIDI legacy. For example take MIDI Channel. The standard defines that MIDI Channels are numbered 1 to 16. The nibble/byte value for channel always starts with 0 (0-15).


    Same thing is with program numbers. The value starts with 0, which is "Program 1". During the design phase it was considered that the naming scheme could be switchable, so someone with a foot controller that starts to count with 0 could also be matched as one that starts with 1 (no foot pedal has a 0-4 numbering scheme, usually only 1-5).


    Finally, it wasn't switchable, the display naming is correct.


    The "filename" of a performance derives from the internal value. So Performance 1 has byte value 0 (which brings us to "0.kipf")


    Timo


    (This kind of mismatch is something that all keyboarders handle naturally, btw.)

    Quote from timo

    The "filename" of a performance derives from the internal value. So Performance 1 has byte value 0 (which brings us to "0.kipf")
    Timo
    (This kind of mismatch is something that all keyboarders handle naturally, btw.)


    We have to admit that, at the end, this isn't a real problem for the Kemper users.
    Also, by now with the performance files "kipf" we can do nothing ... not copy, not import, not export ... I believe this is a pity. Do you plan in the near future something more to handle the performance and their rig files? Thanks

    Timo, with all due respect. :)
    I totally understand your technical explanations. But my opinion is still the same. The whole performance file naming concept is a usability problem. It's a fact that we don't have a librarian software yet and we still don't know anything about the planned capabilities of such a software. So we have to deal with what we have. And Performance management is a pain in the *** the way it is right now. I've been developing software for many years, so I pretty well know that there's not even a single technical excuse to go with this overly simplified file naming convention for performances. It could have been handled in a different, more user friendly way.


    In my opinion, it's not to late yet to change this. My suggestion would look like this:
    My-Gilmour-Set-24.kipf
    StatusQuo-Rossi-3.kipf
    and so on.


    It shouldn't be a big problem to extend the file names like shown above because the performance index would be found after the last occurance of a dash (or just right in front of the file suffix delimiter), basically the file name just extended at the beginning, leaving the "24.kipf" or "3.kipf" sequence as is. Of course I would also request to change the 0 vs. 1 mismatch as well to make things managable for human beings without the risk of accidential confusion.


    Just my 2 cents to get around this "design flaw" (sorry, I really have to call it this way),
    Martin