Response from KPA support regarding switching times- BAD news

  • i was just thinking about this. i wonder if there is a way the software could reduce switching time by locking everything but the stack section or something like that, so that changing rigs is quicker. maybe like a quick switching mode where all the stomp/effects are the same, but you can set their initial on/off state per rig. this way 8 effects don't have to load in and out of RAM or whatever. That's gotta save a few ms, right?


    i call it virtual pedalboard

  • i was just thinking about this. i wonder if there is a way the software could reduce switching time by locking everything but the stack section or something like that, so that changing rigs is quicker. maybe like a quick switching mode where all the stomp/effects are the same, but you can set their initial on/off state per rig. this way 8 effects don't have to load in and out of RAM or whatever. That's gotta save a few ms, right?


    i call it virtual pedalboard

    Locking the stack will reduce switching time, also you should take a look at the functionality of cc16 (see MIDI parameter documentation), which gives you an immediate switch given slots are being properly configured.


  • In other words, "user error". :D


    No, i certainly don't consider it user error. The only way I've come to satisfactory arrangement is by automating patch changes with a laptop, i still consider it unsatisfactory when changing with a footswitch. I can accept that other people just aren't as bothered about stuff like this though.

  • Since the foot switch and the laptop are basically two midi controllers, I'd say that the issue is related to the FCB1010 (which is anything but a cheap footcontroller).
    If the problem was because of the Kpa you couldn't have had any improvement just by changing the controller.

  • Since the foot switch and the laptop are basically two midi controllers, I'd say that the issue is related to the FCB1010 (which is anything but a cheap footcontroller).
    If the problem was because of the Kpa you couldn't have had any improvement just by changing the controller.


    The problem IS with the KPA, the improvement by changing the controller is because i can precisely time, test and adjust the exact time at which the changeover happens with the laptop.

  • Don's measurements were really nice, but they only take the internal audio switching into account. What you experience is much more than these 16ms. You experience 120-150ms delay and this can be VERY disturbing. 16ms would have been something you could easily deal with. So why is the delay 8 - 10x longer than what Don measured? Because you tap on a foot controller, this command has to be translated to MIDI, sent to the Profiler, translated back from MIDI to a DSP command, wait to get executed, and finally the execution time plus audio latency.


    So there's a big difference between Don's measurement of the audible switching and the real life delay. Can have many causes.


    1. Maybe Don's measurement doesn't take rig loading into account, just the actual audio switch at the end of the rig loading process?
    2. MIDI commands take to long to get translated and executed on the Profiler.
    3. The MIDI foot controller doesn't send the MIDI commands with near zero latency.


    I really don't know the cause, I just know it takes WAY to much time from foot tap to actual rig change. The rest would be subject to some more research.

  • 3. The MIDI foot controller doesn't send the MIDI commands with near zero latency.


    [...] The rest would be subject to some more research.

    I happen to have done that part of the "research" a few years ago - when I designed the Gordius controllers and worked on bringing the latency down to the level of the FCB1010 latency. Test setup: mike an FCB1010 connected through MIDI to a PC, click a footswitch which triggers a Note on a virtual synth, record the button click on the left channel, virtual synth output on the right channel, use Audacity to measure the delay between foot click and synth sound. If I remember correctly total delay was around 5ms, average delay between foot click and MIDI OUT was 1 to 2 ms, transmission of 1 CC message takes 0.8 ms.

  • No, i certainly don't consider it user error. The only way I've come to satisfactory arrangement is by automating patch changes with a laptop, i still consider it unsatisfactory when changing with a footswitch. I can accept that other people just aren't as bothered about stuff like this though.


    I said "user error" because you said, "The problem is just in a live situation where you have to try and judge
    that when you're playing complicated parts and singing at the same time"


    How did you do the 'perfect' zero latency switching when you were using a tube amp and pedalboard?

  • I happen to have done that part of the "research" a few years ago ...


    Thanks for sharing. :)
    So, if the FCB1010 isn't the culprit, maybe there's something wrong with MIDI input and its processing inside the Profiler? Or something wrong with rig data loading? I don't think I made a big mistake when I measured the time between footswitch sound and audible rig change from the OP's demo video.

  • maybe there's something wrong with MIDI input and its processing inside the Profiler?

    Of course I'm not the right person to answer that. I just had 1 report recently from an FCB+KPA user, who said :
    "The only thing I've noticed, that the first switch action after powering up to another sound with the FCB takes somewhat 1 second. All following switch actions I can do during songs without noticeable delay."
    To me that sounds like the Profiler might need quite some time to load and initialize certain profiles, and during that time incoming MIDI is just buffered and gets processed once the initialization workload is over.
    Very similar to reports I had in the past about for instance the Vetta II amp: UnO firmware introduced the possibility to send effect CCs along with the patch select message. The Vetta II required a delay of something like 100ms between patch select and effect activation messages - else the effects were not correctly initialized (apparently the Vetta didn't buffer incoming MIDI during patch initialization, just ignored it).

  • timo, what I was saying is the exact opposite - change the stack section, not input, stomp, effects, and output. only toggle the initial on/off state of all 8 effects. but it's good to know it's optimized with stack locked. i will check out the cc16 stuff now.


  • I said "user error" because you said, "The problem is just in a live situation where you have to try and judge
    that when you're playing complicated parts and singing at the same time"


    How did you do the 'perfect' zero latency switching when you were using a tube amp and pedalboard?


    Switching is instant with my tube amp.

  • "The Kemper has a few millisecond delay when switching profiles and is definitely noticeable when playing live."


    Re Really? a few milliseconds? I can't believe that would be a problem...... that's almost instant.


    e



  • I just had 1 report recently from an FCB+KPA user, who said :
    "The only thing I've noticed, that the first switch action after powering up to another sound with the FCB takes somewhat 1 second. All following switch actions I can do during songs without noticeable delay."


    all my kempers do exactly that, also when using the frontpanel switches to change rigs... only the first change after booting up takes a while, then it's quite responsive - also via midi.

  • Might I suggest we pool resources and gift Metallica a Kemper/FCB1010 so that the silence during switches, so painful to some owners,
    might instead bring much relief to their audience from such current banal tone and poor sense of tuning. ;)