Posts by vtgearhead

    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.

    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.

    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.

    I apologize if I misinterpreted your post.


    I did re-read it. Just now and more than once before my original post. You may not have intended to sound accusatory, but that's what it (still) reads like to me. Regardless, no worries. Thanks for replying to clarify.

    I went back and updated the post to make it clear I wasn't upset with Michael in the slightest.

    For 13 years, keeping a record of profile amp settings served absolutely no purpose. Suddenly liquid profiles exist and after a few weeks the makers are now becoming suspect? With Michael Britt, one of, if not the the most respected profile makers the one called out first?

    Please re-read my original post. I'm not "calling out" anyone and was simply wondering why I never received any response. The comment about proprietary was a WAG that in general there may be concerns about working artists detailing their control settings. It's because I have so much respect for Michael Britt that the lack of response puzzled me.

    I put in a question to this effect on Michael Britt's website but never received a response. I'm growing concerned that knob settings might be considered proprietary by working players. I have to believe he has a record of control settings. BTW, I am indeed a paying customer.


    UPDATE: In NO way am I complaining about Michael, for who's work I have great respect. Was more musing in general whether there might be vendors who consider the exact settings proprietary.

    I predict we'll see tone stack profiling in a future software release. It's not rocket science. If you assume the tone stack to be linear in response (a safe bet for 99.9% of cases) then it's a matter of prompting the user through setting changes as frequency response is measured repeatedly. Kemper has already solved the tough problem by being able to capture non-linear behavior.