Preset switching slow

  • I've noticed that my powered head (current software) has become somewhat sluggish with changing presets via the remote. What's the best way to troubleshoot and is there a fix? Same with two different cables, no USB cable or SPDF attached. I may have a few too many profiles in it by now and I'm not even using that many. So I'm sure I could clean that up but even there I'm not sure what's the best way of doing it. I know there is a way to clear what's not a "favorite" but I don't have favorites set.

  • I'm having a similar issue.


    EDIT:


    There is an audible delay of about 200 ms when switching in Browser mode with both Remote and MIDI (airstep). Performance mode is great with the Remote, but no different with MIDI. The only way for me to get reliable/fast switching with MIDI is to program the footswitches as Program Changes (0-4) instead of Control Changes (50-54). Xsonic (makers of Airstep) say it is not on their end and that switching is instantaneous for them with their KPA preset. I've had to build my own preset.


    I am not currently connected to my computer via usb. I am on the most recent OS (8.0.6.xxxxx) I do not have rig crossfade turned up. It is not that. I have read every. single. thread. on this topic dating back to 2014. I'm still looking for the answer. I have also reached out to support who have not yet identified the issue. I was just told to make sure my KPA isn't connected to the computer or Rig Manager (it's not) and that if I'm sending multiple midi messages it could cause a lag. I'm pretty sure I'm not as I've looked at the MIDI messages being sent in Pro Tools for example and there is only one.


    I also programmed a MIDI rig change in Pro Tools independent of my floor controllers and set it to the downbeat. The KPA switches rigs ~204 ms after the MIDI command.

  • I don't know if this helps or not:

    System settings:

     Rig Change Crossfade Time (Rig X-Fade Time)

    Most digital audio devices create an unpleasant gap in the audio signal when a preset is changed. The PROFILER instead performs a crossfade between the previous and current Rigs, producing a seamless and smooth transition. This crossfade time can be adjusted in a wide range. It affects both Browse and Performance Mode.

  • @DeeperStudios When using the MIDI controller and PCs for changing the slots can a subsequent PC for the same slot # trigger Morphing?

    Edited once, last by m3talf0r3ver: I can confirm the PC for changing slots within a performance is much faster compared to CC. Personally I feel no delay, Unfortunately repeating the PC will not trigger morphing so I use PC for "standard" slot change and CC for morphing. It is not big deal just a small complication in the program. The delay of CC when triggering the morphing is not that crucial. ().

  • Is it the display that’s sluggish or the actual audio changing from preset to preset?

    Both. Audio is delayed, visual cues even more (both screen and LED). All this is in performance mode. I have no use for browser mode. All with the Kemper Remote. I'm not using other midi signals with the Kemper at this point

  • MIDI program changes just load Rigs in Browser Mode or Slots in Performance Mode. To trigger effects - and that includes Morphing - you need to use MIDI control changes instead. There are two ways to trigger Morphing via MIDI:


    1. MIDI control change #80


    Morph Button (value 1-127 triggers ramp from Base Sound to Morph Sound according to selected Rise Time; value 0 closes transaction; next value 1-127 triggers ramp from Morph Sound to Base Sound according to selected Fall Time; if option “Momentary” is selected, value 0 triggers immediate return to Base Sound).


    2. MIDI control change #50-54


    If Rig Button Morph is activated in System Settings, and the PROFILER receives subsequent control changes #50-#54 following the initial Slot load, these will trigger Morphing. So, the same button could be used to first load a Rig, and then act as a Morph Button for that Rig. To support all functions, values 1-127 should be sent when the button is hit, and value 0 should follow when the button is released. The setting of the “Momentary” option in Rig Settings determines whether the Morphing latches the morph sound and base sound, or if it immediately returns to the base sound as soon you release the button.

  • Actually I answered myself in edit:


    I can confirm the PC for changing slots within a performance is much faster compared to CC. Personally I feel no delay, Unfortunately repeating the PC will not trigger morphing so I use PC for "standard" slot change and CC for morphing. It is not big deal just a small complication in the program. The delay of CC when triggering the morphing is not that crucial.

  • I cannot reproduce any delay triggering Morphing via MIDI CC# 80 other than the intended ramp times, which you could set to 0. As soon as I send MIDI CC #80 with value 1 (Fall Time = 0) the sound immedediately switches from Base Sound to Morph Sound or the other way around. You just need to send a 0 in between.


    Are you sending the CC together with the PC?

    And is the PC loading a Slot within the same Performance or loading a Slot in another Performance?

  • This problem just came up for me now we have returned to live shows after 2 years. Of course I have updated firmware several times since then and don't recall what version I was using before.


    We program change rigs with Pro Tools in browser mode and there seems to be a longer delay than in the past. This results in chopping off the front of songs that used to come in on time. Has there been a change in the latency for selecting a preset?

    Karl


    Kemper Rack OS 9.0.5 - Mac OS X 12.6.7

  • Sorry, I know this isn't helpful, but this is exactly why when I bought a KPA I insisted I had the stock controller with it. I know how to implement MIDI real well (since early cakewalk) and could hook it up to the latest ultrasonic bipolar air switcher for my Ipad or whatever if I wanted to, but the stock controller makes it EASY and I could still connect to a switching network for a big synced live show.

  • Thanks for the replies. There has been no update on my Pro Tools 11 application since 3 years, so I moved all program changes 1/16th for now and all is fine.


    I don't have time to experiment yet, but I might wind the firmware back a few versions after this run of shows to see what happens.

    Karl


    Kemper Rack OS 9.0.5 - Mac OS X 12.6.7

  • Similar problems, I play live with backing tracks on pc , I have a separate track that sends patch changes in performance mode so I have no need to switch with feet. It worked fine before but since latest firmware update it is very slow in changing the patches.

  • Similar problems, I play live with backing tracks on pc , I have a separate track that sends patch changes in performance mode so I have no need to switch with feet. It worked fine before but since latest firmware update it is very slow in changing the patches.

    I've occasionally found inconsistency in patch change speed from one firmware to the next. So I decided to put all my program changes exactly on the beat instead of placing them a 32nd early. Then I can drag the midi track forward as a whole to match the current latency I need to compensate for.


    This is also useful for transferring the program changes to a backup unit with different patch change speed.

    Karl


    Kemper Rack OS 9.0.5 - Mac OS X 12.6.7