Major problems with CC messages and OS 5.0.3.12660

Quote from mortl

Just for that part, that SysEx-Messages to change parameters are ignored, when the Parameter is locked: I reported that as a bug about 1 1/2 years ago... And i did it once more a few days ago.
I noticed that for fx-parameters aswell as for setting tempo.

This is not a bug. The type 2 messages are intended to be preset changes. They can be part of a full rig, so when "loading" a rig, the locked part is being ignored. The is implied by the locking feature itself.
Also: you can only use type 2 messages when controller number starts with that unit and if it is not complete (like send the first 10 controllers), the missing rest of that unit is initialized with default values, which is a mechanism to ensure backward compatibility with older presets.

If you want to change something with MIDI, don't lock it. Since you are sending it anyway with all PCs, it doesn't really matter.

Quote from timo

If you want to change something with MIDI, don't lock it. Since you are sending it anyway with all PCs, it doesn't really matter.

I don´t send it with all PCs.

All I want to achieve is:
1. Having 4 Buttons on my Controller, which ONLY choose 4 Rigs, no change to the delay, not even the on/off state. (I send PCs to get this)
2. Having 4 Buttons on my Controller, which ONLY change the delay-Settings to 4 different "Delay-Presets".

for 1 i have to lock the delay, don´t i? and now: how can i change the delay-settings when message type 2 is ignored (beause of the lock)?
I now do it with MANY nrpn-Commands for each parameter. that works... and i found out, to delay the "midi-stream" by 10ms after each nrpn works without errors. Without that delay, there is some strange behaviour in the profiler - wrote that in another ticket.

if there were just two or three delay-types, i could put them in different slots and just switch them on and off - but i haven´t enough free slots... and with the new (GREAT!!) delays, I even think about having 5 or 6 delays to choose from.
If the differences between the Delay-Presets would just be some parameters, i could think of morphing. But that would manage just 2 different settings.

A very cool thing would be to load saved delay-presets from the profiler ... maby by sending PCs on another Midi-channel - or with CCs - or a NRPN-message... but I think thats rather a big deal to implement (i.e. a second mapping-table would be necessary - gets complicated).

Martin

Quote from mortl

I now do it with MANY nrpn-Commands for each parameter. that works... and i found out, to delay the "midi-stream" by 10ms after each nrpn works without errors. Without that delay, there is some strange behaviour in the profiler - wrote that in another ticket.

You need to see that transmitting one profilter SYSEX message alone takes roughly 4.5ms, so my guess is, that the output queue of your foot controller is not able to handle all the data it must transmit with 31250 baud in its queue.

With my possibilities all I can check is, that every Sysex and every NRPN (single and multiple) are transmitted correctly to a midi-monitor-tool on my mac. I also tried to send the type 2 message with all values (over 200 bytes) to the profiler to set the delay-parameters - i sent all the values which the profiler gives me when asking it with function code $42. clearly talking about the right start-sequence plus the values. it works perfectly as long as the delay isn´t locked.
So i think i can assume, that my profiler sends the midi-bytes the right way.

31250 baud also is, what is set.

Martin

Quote from mortl

With my possibilities all I can check is, that every Sysex and every NRPN (single and multiple) are transmitted correctly to a midi-monitor-tool on my mac. I also tried to send the type 2 message with all values (over 200 bytes) to the profiler to set the delay-parameters - i sent all the values which the profiler gives me when asking it with function code $42. clearly talking about the right start-sequence plus the values. it works perfectly as long as the delay isn´t locked.

As said above, it is more of a feature than a bug

Ok,
that is an answer (which i didn´t get 1 1/2 years ago) - and i have to live with it (no choice! )

But just because i want to know: in which situation do you need a type 2 message then?
When sending it as "part of a full rig" (as you say) .. you don't need to send them, because the delay-parameters are loaded anyway with loading a full rig (when not locked).
it would be easier to save the needed parameters with the rig as sending an extra message with the rig-change.

if they would be accepted even when locked, you could send it with a rig-change when you want to load a specific fx-preset... and you could not send them, when you don´t want to change the fx-preset when loading a rig. - thats my understanding.

Or is there some kind of internal type 2 message, when changing rigs? and the FX-Modules don´t make any difference if this messages comes from inside the KPA or from outside via midi?
And locking is the only way to not send that message to a fx-slot when changing rig?
If so, i would understand that behavior and consider it as a feature

Martin

I have the same problem @Soloist74 is mentioning !!

When working in the browse mode (which is the best and easiest way to work for me) my floorboard isn't in control of the KPA anymore.
I wrote a ticket and I've got an answer from Kemper that the problem is known.

I got this message "This is a known problem and our developers are already working on a fix.
Unfortunately i cannot give you any estimated timeframe for a release."

Hopefully that's gonna be soon.

Yep, I think it's fixed !!!