it can be solved in several ways, but as said already: it has low priority right now atm, and we have to use our available software development capacity wise
this is not a hardware problem at all, it is 100% software: but it is relatively low on the priority list to solve.
hi: we've found the cause, and fixed the issue: it will be in the upcoming firmware
Yep.....i have had this issue with the remote even getting it on in the first place.... sometimes have to restart the Kemper 6 or 7 times, unplug and re-plug the remote back in to get it on.
this indicates that something is wrong with your hardware: most probably the cable, but maybe the connector inside the KPA or the RemoteQuote
I have tried so many bloody ethernet cables and still the same crap.
You only would need to try the official supported cable that came with the remote. Most other cables are not adequate: the wire-gauge is not thick enough !Quote
Every gig is a crapshoot and a headache with this remote issue. One would think that Kemper, being such an amazing company could have sorted this issue out ages ago..... I guess the small things are not that important to them, but at least it sounds good.
By the way: using a proper PoE injector will enable you to use any off-the-shelf cable (up to 100m).
OK... I'll check with support tomorrow and see if we can find-back your ticket
please check your spam folder.
just as a note again: the Stage works fine as SPDIF slave with the current release (7.1.12)
there are a lot of variables which can mess up correct digital audio I/O on a computer.
for example: to rule out for driver and buffer issues on your DAW, you could try to record with a simple loop-back cable (directly between the SPDIF-out and the SPDIF-in of your interface, with the same settings you're trying to record the KPA)
of course: maybe there is a defect on your unit, that can be ruled out by exchanging it.
Support should always contact / answer you.. maybe something landed in a spam folder?
yes this is definitely a software bug, (and the bug most probably has been around some time already, but was not triggered so prominently yet)
What we've found out until now:
sometimes the initial communication with the front panel is not successfull, but the system boots nevertheless (after a time-out.. so this is the 'extra boot time' some people experience in that case) which results in the brightness of some led groups not being set correctly at boot.
Trying to reproduce here, but not really succeeding so it seems there is no real relation to neither the USB connection or how it is powered up.
ok.. this definitely looks like a software issue. we're trying to reproduce and solve it. If you have any additional findings or other observations we would be glad to hear it.
for those with brightness issues:
1) do you have the unit connected to Rigmanager (or to USB at all) ?
2) how do you switch-on the unit? by power button (from standby), or by applying the mains voltage?
which firmware version? could you provide us a backup of your unit? please open a support ticket to get into contact.
the Stage acts as a SPDIF slave just fine.
- using latest firmware?
- good quality RCA cables? (i.e. labelled 'for digital use')
- use 2 cables (kind of trivial)
- Stage has to be set to SPDIF 'auto'
- DAW has to be master
- supported samplerates: 44.1 / 48 / 88.1 / 96
just FYI: "ein und ausschalten" (= Stage switches on directly when applying AC mains power) is not a bug! this is the intended behaviour. (However it will be changed in the future)
just grabbed the manual for the FC7: it's a 50k potmeter on tip.. this should work fine with the KPA. I'm not sure wether it should be set to type1 or type2 right at this moment (have to check) but definitely one of those type settings should be OK.
please set type to type1, press 'calibrate' and move the pedal several times up and down
if this doesn't yield the required behaviour, select type2, press 'calibrate' and move up & down
it's not needed to 'save' or anything after this
did you set the 'type' of the pedal correctly, and did you do a 'calibrate' ?
I think this is fixed in the current (still private) beta (7.0.9)
just sent you a private message
hmm.. still not convinced that it isn't a mechanical issue. would really like to know what 7.0.9 does on your device.
Hi, i'm programming some performance patches and using a MOTU Ultralite 3 for MIDI OUT to Kemper Profiler (Head Unpowered) MIDI IN.
The midi messages all work to changing the performances but i'm sending Tempo because my show has all kinds of tempo changes and i'm using a large session with all the sequence from all the show songs so everything has already been automated for the click track in Logic Pro X.
I'm sending MTC but the Tempo display in Rig>Tempo goes all over the place. Ex a song is in 126 bpm then the kemper oscillated between 126.9 to 125.4 .... aaaand
I'm also using MIDI OUT from kemper to hookup a BOSS Slicer to recieve the tempo from the session but it is never synced, the Boss also fluctuate with the kemper and is never in the beats that the session is playing.
Am i doing something wrong?
- MTC is not MIDI clock; these are 2 different things: the KPA supports MIDI clock only.
- the indication of the clock on the display is not necessarily what you would be hearing: can you actually hear mis-artefacts in the (timed) effects of the KPA ? (i.e.: out-of-sync delay or something like that?)
- the indicated clock BPM on the display can take a while to adapt, and is an averaging indication of the measured received clock-speed.
- you should connect the BOSS Slicer to the MIDI-THRU of the KPA in stead of the MIDI-OUT ! however be sure not to have anything assigned to the MIDI-THRU port of the KPA, assuring that it's operating as a real MIDI-THRU port. Furthermore be sure to disable 'Send MIDI clock' on the KPA, because you really want the all of the clocking to come out of your DAW (Logic Pro X)