Posts by vtgearhead

I used a Kone in one of the Mojotone open-back cabs a year back. Sounded great, but my drummer was getting blasted with sound from the rear of the system. Moved to a powered Kabinet and all's well.

Even after watching all available videos and endless tinkering I was never able to configure "clean sense" to actually get softer when I back off volume on the guitar. However, the Beta 11 code actually does support this when "clean compensation" is dialed to minimum. I no longer feel like I'm fighting with the volume leveling.

Unfortunately, my setup became plagued with random disconnects and I had to drop back to a lightning/ethernet adapter on the iPad and cabled connection. Recently I picked up a Stage and have had no disconnect issues.

I've had one open since the day I started this thread. As I mention above, they told me it's expected. But it doesn't match your experience nor can I believe they would have shipped software that took many seconds to bypass the effect. I pinged them again on the issue but I have not heard back.

Thanks very much for confirming what I suspect. The delay I'm seeing is unlikely to be intentional or expected. I can tolerate a short glitch before and after soloing, but having to wait many seconds before the fuzz bypasses is a non-starter.

Does it clean up that quickly when you tap the button again for bypass? I'm only seeing it in that direction. It turns on with minimal interruption and off painfully slow.

I reported the problem to Kemper support who tell me this is normal behavior. From the manual section on the Kemper Fuzz:

You will notice an audio drop-out when switching, too. This drop-out will also occur whenever you switch from or to a Rig with a fuzz with active “True Impedance”. This drop-out cannot be avoided as the hardware impedance dramatically changes the incoming level of your guitar in an instance. Consider carefully whether you will make use of the volume pot advantages or benefit from an artifact-free switching.

What threw me is that it's not really a "drop-out". The impedance changes instantly, brightening up the sound, but the fuzz effect does not bypass for almost four seconds. This all seems a bit odd, but not being privy to the system architecture there may well be good reasons for it.

Subject says it. The original Vox / Dunlap wah pedals have a rather low input impedance and it's part of the characteristic sound. Can we get a checkbox in the wah blocks, please?

I just switched over from a rack profiler to a new stage unit. The True Impedance option sounds quite nice on the Kemper fuzz, but it's behaving very strangely when I turn that block off using a footswitch. The impedance setting changes immediately (I can hear the sound get brighter), but the fuzz does not get bypassed for another four or five seconds! If I disable the impedance check-box the effect bypasses immediately on press of the footswitch. Anyone else seeing the problem? I already tried a factory reset and restore, but no change in the behavior.

Some of those little molded inline switches use extremely thin wire and might cause enough voltage drop to be a problem. I just went through this while setting up a RaspberryPi based computer. With the power supply (USB) plugged directly in it worked fine. With the switch (looks very similar to the one in the photo) in line it crashes repeatedly. Digital devices can be intolerant of marginal power.

In one of my bands I found the rear wash from an open back cabinet caused problems on stage. After a lot of complaints from the drummer I switched to a real powered Kabinet. No more issues.

Quote from amosmax

You're referring to an APIPA address, right? That makes sense.

That also tells me my setup is not going to work. I got a TPLink PoE switch so I wouldn't have to use a PoE injector. Also got the PoE powered MicroTik maP, which has a super small footprint. Unfortunately, the maP only works in router or Bridge mode. In Bridge mode the DHCP server is disabled and in router mode the communication between the wireless and wired networks is NATed.

On my Android tablet it looks like the app is using broadcasts to discover the Kemper, so that's not going to work across a router/NAT, and in bridge mode my tablet won't get an IP address, which means I'd have to enter an APIPA address manually every time. Also, the power brick for the TPLink is at least as big (if not bigger) as the switch.

(listing all this info in case someone else is researching/trying the same thing).

I saw your setup on the thread Syntek mentioned. What PoE injector is that? Looks like it has a pretty small footprint. And are the power supplies for the GL.iNet and the PoE injector the black and yellow bricks right above above the PoE?

Android behavior in the lack of a DHCP server is not very helpful. One would hope that its network stack would soft-fail back to APIPA but that's not the case. iOS devices behave properly in this regard. I was able to work around it by manually configuring my Android tablet to use an arbitrary address in the APIPA range. The Android is a backup for my regular iPad so I'm not 100% confident it will remember those settings in the real world - all I know for sure is that it did in my practice room.

The POE injector in my photo is a TP-LINK TL-POE150S. The black "brick" is the injector's power supply. The GL.iNet was powered from a USB port built into the power strip. I use past tense for a reason. That port couldn't supply enough current to reliably run the router and I was plagued with random drops and disconnects. Since then I've switched to a POE enabled router as replacement for the injector and access point. This new setup connects to my iPad through a Lightning-to-ethernet adapter. With no DHCP server in the picture I quickly discovered the Android issue. Again, the iPad works just fine.

I may take another shot at using the access point with its own power supply (in addition to the inject), but that will require a new power strip with at least (3) outlets. But, in fairness, I'm more likely to pickup a gently used Kemper Stage and retire the current rack to my cellar.

From my experience, the Kemper does not act as a DCHP server. It sends discovery packets at startup and will use an external server if found (e.g. your AP). If no server responds it falls back to the so-called "link-local" network range.

Sweetwater cheerfully accepted my pre-order today. Sales person says it will be a "couple of weeks" before they see stock.

Quote from G String

vtgearhead could you please contact support with your suggestion and also your DHCP-related findings?

Done. FWIW, you need to add Android to the ticket screen OS pulldown. And, to be clear, the DHCP issue is an Android rather than a Kemper problem. The only way you can mitigate against it would be to have the Profiler itself become a DHCP server in the case where it gets no answer from DHCP discovery.

I have a useability related suggestion for both iOS and Android implementations. It's very difficult to know whether 'Save Performance' button has been properly pressed! After losing edits a few times I've learned to wait and watch the Profiler screen to be sure I hit it cleanly. Please consider providing a pop-up on the RM UI to confirm the save?

So far so good. Running RM on a Samsung Galaxy Tab A connected over OTG Ethernet to POE switch that serves a rack profiler and remote.

If anyone else with a Tab A tries this there's a 'gotcha': The ethernet device defaults to DHCP on my version of Android (8.1.0), but since there is no DHCP server the profiler assigns itself an APIPA (aka link-local) IP address in the 169.254.x.x range. That would be fine if the Android network stack behaved correctly by dropping back to link-local - but unfortunately it does not and you get no connectivity. The workaround is to use static addressing. Give the tablet something in the correct range (e.g. 169.254.50.1 / 255.255.0.0), make up a DNS server address (I used 0.0.0.0 / 255.255.0.0) and repeat the IP address as the default gateway. Save the configuration and all should be well. Since I have only the one Android device I do not know if this is common to all Android implementations.

There are no such problems with iOS devices since Apple apparently knows how to read specifications.

I use a small Wifi access point and POE injector to provide connectivity between my iPad and rack profiler. For venues where problems occur I keep a Lightning-to-ethernet adapter on hand. After updating to the current release version of 10.x the iOS Rig Manager can no longer connect to the profiler when running either wired or wireless. It appears to see the unit and pops up a box with its correct name and a "Connect" button. BUT, the connect button is grayed out and does nothing. This was working just fine before the update so it seems something has broken.

Apple App store does not show any updates available, so I have to assume I'm running the latest manager software.

UPDATE: Just after posting this I tried removing and reinstalling Rig Manager. That brought it right back to life. Hopefully someone else can benefit from my experience.

Quote from Kemper Support #1

The filters in the cab module will affect the sound of the monitor output signal even if Kone mode is activated and "monitor cab off" is active.

Thanks! Since the preexisting hi/low pass filters on the output tab already did exactly that is it safe to assume that the rig-specific filters on the cab page and the legacy filters are cumulative in their effect?

I run with monitor cab off and use imprints on the Kone. My take-away is that the new filters are then specific to my main outputs and will have no affect on the Kone. This leaves the question of what is affected by the pre-existing filters on the output tab. I believe they affected both the monitor and main. Is that still the case?