Boot/Startup improvements

  • In an attempt to make the remote connect faster the power to the network port has been delayed in the KPA boot process. The result is that we are still waiting, sometimes up to half a minute, for the remote to establish a connection to the profiler after the profiler's boot-process is complete. This should be implemented so that the connection is established immediately as soon as both units are ready. With no delay of power to the remote it will always be ready before the profiler is up and running. This can for example be done using connectionless unicast/broadcast-signalling with a listener on either unit waiting for a "ready-signal" from the other before the final connection is made. I.e. the remote could broadcast a "any profiler here?" request before trying to make a regular connection and sit waiting for a response, while the profiler could broadcast a message saying "I'm here, any takers?" as soon as it is ready. All this signalling would be done with very limited timers (<100ms). Messages would be retransmitted at some interval when there is no active connection to catch abnormal situations such as a broken cable, but for normal operation there would no longer be any waiting for the connection to be established.


    The KPA and/or remote should be able to sense and act on the position of pots (expression-pedals) immediately after startup. While there may be an issue with changing configurations most users would use the same set of switches and pedals from one session to the next. The KPA should thus remain silent after startup if there is a off/down volume-pedal connected and assigned, and the connected set of pedals and switches are the same as stored from the previous session. Combined with proper handshake with the remote as described above it would only delay boot-up by a fraction of a second if the state of volume-expression-pedals is evaluated before turning the volume up. The current situation where the position of volume expression-pedals remain undetected until the pedal is moving is a cause of a lot of grief. I'm using an external switch to cut all outputs for "standby", but this should frankly be unnecessary.

  • I for one would also like the volume pedal position to be sensed at startup and any switches such as tuner active to be retained from shut down to start up. I believe the KPA is currently supposed to identify if the volume pedal is at 0 on startup but I have never found that to be the case. i always get full volume everytime I reboot even with the volume pedal in the heel position.

  • Well, that‘s what they do.

    Really?


    1. This has varied with different firmware versions, but currently my KPA (8.0.2 22186) delays power to the remote so it doesn't power up until just before the profiler is ready. As a result the profiler is waiting for 10-15 seconds before the remote is ready to connect. Firmware around the time the remote was introduced enabled power to the ethernet much earlier in the boot process leaving the remote waiting for the KPA, but with connection retries only happening once every 30-sec or the chance of hitting the KPA with a connect() at the exact time it is ready to accept it is minimal.


    2. My profiler is not reading anything in terms of expression-pedal-position until the pedal starts moving. If for example the power goes out, or someone trips a cable on stage where there's a KPA with a guitar attached on a stand (especially with acoustics) there's a high risk of noise or feedback once the power comes back on because the KPA comes back up at full stage volume. It may be different with a directly attached pedal, but why should we have to bother with that when there are exp-pedal-connections on the remote.

    Edited once, last by heldal ().

  • Kemper Support #1 thanks. Tht is certainly the way it does operate but I was under the impression from previous discussions with Burkhard that the shut down routine should remember the position at the point of closing down and reboot with the KPA in the same state. Therefore, if the VP was in the heel position when closing down the KPA would reboot with volume at 0 (or whatever value corresponds to the heel position of the VP). Even in this state you would still need to move the VP to have the KPA recognise the current physical position of the pedal but the default start up would match the position at close down. This has never been the case for me so I assume I have misunderstood what Burkhard was saying. To be honest it isn’t a major problem so I just accept it but it would be nice if it worked the way I described.

  • It was probably a misunderstanding. I talked to our tech gurus and they confirmed that the current behaviour is intended and cannot be changed for technical reasons.

    That doesn't seem logical to me. An expression-pedal is a variable resistor. There is AFAICS nothing that prevents the remote from sensing and reporting its value before the resistance start changing. There may be an issue with calibration, but measured max and minimum resistance could easily be preserved across sessions. Even the remote is a small computer with upgradeable firmware and should thus have plenty space to store some local data.


    I understand that the desired mode for the remote is to only send signals/events when something changes, and that most of the state of the remote is set by the profiler. Unless we build motorised expression-pedals the initial state of those should be reported in the opposite direction. To be more specific; you could say that a part of my initial request is to have the remote reporting the state of attached expression-pedals as part of its initial handshake when the connection to the profiler is established.

  • There are several situations where such a behavior is undesired, like

    • after a reboot, the pedal is not connected and the user can't raise the volume again
    • after a reboot, the pedal(s) still are full throttle and the audience is going to be blasted after the powercut
    • after a reboot, the device is at a different location and probably a different pedal is connected

    That's just out of my head before the first coffee, there are more situations. To cover all of this, the "value" of the pedals are updated on the first change with a pedal. To detect "change", the values at bootup are indeed scanned, but they won't result in an immediate change in sound.


    HTH

  • There are several situations where such a behavior is undesired, like

    • after a reboot, the pedal is not connected and the user can't raise the volume again
    • after a reboot, the pedal(s) still are full throttle and the audience is going to be blasted after the powercut
    • after a reboot, the device is at a different location and probably a different pedal is connected

    That's just out of my head before the first coffee, there are more situations. To cover all of this, the "value" of the pedals are updated on the first change with a pedal. To detect "change", the values at bootup are indeed scanned, but they won't result in an immediate change in sound.


    HTH

    If a pedal is not connected then the remote would not sense one, and thus either send "undefined" or nothing which would leave it up to the profiler to do as it does today.


    If the user forget to turn down volume during powerout that is a user error which may or may not happen. Currently, with volume being turned up regardless, the audience is guaranteed a blast ... or at least some noise depending on what instrument is connected. If the player, as many do, pull the plug from the guitar before putting it on its stand leaving the KPA volume off and cable not connected the current implementation will 100% certain result in noise after a power-outage.


    If the attached pedal-configuration has changed from the previous session it would be up to the profiler to decide what to do. The foundation for any code related to interaction of multiple devices is a state-diagram that cover every possibility. For my own use of the KPA, and I would argue almost any live performances with the unit, the only anomalies happen when the user either forget to plug in the remote before powering up or if the cable is broken. To me it seems weird that the most common scenario is not handled properly.


    ---


    However regardless of the above my point about instant connection on boot remains. Given that the remote is able to boot faster than the profiler when both are fired up at the same time there should be no noticeable delay for the connection to be established after the KPA is ready. With proper signalling/handshaking the network-connection should be established within less than 100ms. If both units implement a broadcast-receiver and announce their presence with a broadcast datagram when ready (as well as regularly when not connected), then connection can be established almost immediately (within a few milliseconds after both units are ready). Nobody is going to notice if the KPA uses another 100ms or so on top of its already lengthy boot-process to decide what to do with volume before turning the outputs on. I can't be more specific than this as I don't know the internals of the KPA-platform or Kempers development toolchain, but the lack of efficient state-signalling seem odd to someone with decades of experience with realtime and networking code.

    Edited 4 times, last by heldal ().

  • This is no different to a valve amp if you leave the volume up. I never move my volume pedal, I just turn down my master and then bring up the master and/or guitar volume to avoid an audience blast.


    Just an observation....many people on here have various levels of technical skill. I myself have been in software development for 20 years. However, I think its pointless trying to guess how the technical team have set up and coded the KPA and remote or to challenge them on how the KPA is set up. I assume your request is to speed up the boot up/start up times as per you thread title? I think you are crossing over from requirement and understanding into solution. Its not incumbent upon the tech guys to explain how it works to, just the art of the possible and the constraints to your request.


    As an aside, I'd like a slightly quicker boot up time but its no worse than a Valve warming up. I'm not really interested int he boot up sequence either as I want to use both remote and head in conjunction, so its only end to end timings that bother me.

  • This is no different to a valve amp if you leave the volume up. I never move my volume pedal, I just turn down my master and then bring up the master and/or guitar volume to avoid an audience blast.


    Just an observation....many people on here have various levels of technical skill. I myself have been in software development for 20 years. However, I think its pointless trying to guess how the technical team have set up and coded the KPA and remote or to challenge them on how the KPA is set up. I assume your request is to speed up the boot up/start up times as per you thread title? I think you are crossing over from requirement and understanding into solution. Its not incumbent upon the tech guys to explain how it works to, just the art of the possible and the constraints to your request.


    As an aside, I'd like a slightly quicker boot up time but its no worse than a Valve warming up. I'm not really interested int he boot up sequence either as I want to use both remote and head in conjunction, so its only end to end timings that bother me.

    Oh, there are differences:


    With all analog and a valve-amp you have the volume-pedal in series. The pedal doesn't move on its own. The KPA flatly ignores the position of the pedal on power-up.


    My goal is to eliminate any waiting for the remote to connect when the KPA is ready, which in turn is required to control the power-on volume and thus eliminate the need for an external wiring-harness+switch that currently is required to deliver the standby that valve-amps have had for decades.

  • The KPA flatly ignores the position of the pedal on power-up.

    My understanding of the expression pedal is that the Kemper does NOT 'ignore' the pedal position. An expression pedal is passive. The pedal itself imparts no information as to where it is in it's throw. Only when it moves does the KPA 'see' it. Which is why they should be calibrated.


    The fact that it hasn't moved on startup means the KPA has no idea of its position (and can't). It cannot ignore something that isn't present.

    “Without music, life would be a mistake.” - Friedrich Nietzsche

  • My understanding of the expression pedal is that the Kemper does NOT 'ignore' the pedal position. An expression pedal is passive. The pedal itself imparts no information as to where it is in it's throw. Only when it moves does the KPA 'see' it. Which is why they should be calibrated.


    The fact that it hasn't moved on startup means the KPA has no idea of its position (and can't). It cannot ignore something that isn't present.

    I would agree if the pedal had been a complex digital device that send values/numbers when moving, but that is not how it is done. I wrote above that it is a simple resistor, but it is fair to say that there is a bit more to it. What the pedal does is to take a constant control-voltage (typically 5V) and feed back a signal somewhere between 0 and the control-voltage. However, the designs I am aware of will all produce an output voltage depending on the pedal-position as soon as they receive an input voltage. The Kemper remote should thus know the position from the get-go provided that calibration-info is stored from the previous session. Here is a typical expression-pedal design:

    [Blocked Image: https://www.strymon.net/wp-content/uploads/2010/07/expression_pedal_sch-1.gif]


    I understand that it is not desired to have the remote suddenly changing the sound of the KPA if it gets connected while playing, but this case is eliminated at boot-up when the connection between the KPA and remote is established instantly at boot-time. Again an example of how initialisation depend on the current state, as is normal for gear that permit peripherals to connect and/or disconnect during operation.

  • I would agree if the pedal had been a complex digital device that send values/numbers when moving, but that is not how it is done. I wrote above that it is a simple resistor, but it is fair to say that there is a bit more to it. What the pedal does is to take a constant control-voltage (typically 5V) and feed back a signal somewhere between 0 and the control-voltage. However, the designs I am aware of will all produce an output voltage depending on the pedal-position as soon as they receive an input voltage. The Kemper remote should thus know the position from the get-go provided that calibration-info is stored from the previous session. Here is a typical expression-pedal design:

    [Blocked Image: https://www.strymon.net/wp-content/uploads/2010/07/expression_pedal_sch-1.gif]


    I understand that it is not desired to have the remote suddenly changing the sound of the KPA if it gets connected while playing, but this case is eliminated at boot-up when the connection between the KPA and remote is established instantly at boot-time. Again an example of how initialisation depend on the current state, as is normal for gear that permit peripherals to connect and/or disconnect during operation.

    I'm familiar with the design. I'm in the midst of converting an Ernie Ball from volume to expression.

    Without engaging in a drawn-out discussion, it is technically possible. Sure. Practically speaking? Doing it right will take more effort than it's worth. There are several scenarios where simply measuring voltage invites potential problems. It's never that simple.

    I mean no disrespect, but I see this as potential work and development time for a rather fringe use-case.

    “Without music, life would be a mistake.” - Friedrich Nietzsche

    Edited once, last by Ruefus ().

  • Consider these realistic scenarios-

    Ideally after a gig you shut down “properly” so everything is as expected on next power up.


    You have a power outage, for whatever reason, mid song (or in the break) where you require the kpa to be in the state you left it.


    You walk off stage at the end of the set, go to dressing room in which time the tecs have cleared the stage (unplugging everything without a proper shutdown) and the next time you use the unit is at the following nights gig where you want a clean/reset start (you *dont* want it how it was left without the proper shutdown.)


    Whatever state you shutdown, properly or not, the next use is in the studio where the remote is not required (or left at home) so cant rely on having the remote to restore your setting, there needs to be a fresh/default start-up.


    I guess like a pc or mac, shutdown is there for a reason but a power outage usually requires to pickup where you left off but still you may require to pickup where you left off after a proper shutdown (sleep mode?) or sometimes not return to the same state on a power outage. Occasionally a power kill is needed when it all goes tits-up and its the only way to make a”fresh start” is a hard-reset.

    You cant please all the crowd all the time.

  • I guess for me, if I switch off or accidental power down, I accept that I start "fresh". I have control over my monitor sound so I'm not bothered, my boot up sequence is the same. Boot into tuner ( silent), ensure guitar volume is zero and master volume zero. Bring guitar volume to full, bring up master volume to taste.


    I'd do the same with a valve amp.

  • I can agree that not having exp-position registered right away is a minimal issue, but being unable to control the KPA from the remote for up to 15 seconds after it has booted due to minor inefficiencies in the code is irritating. I believe developers would solve this in less time than we've spent writing this thread. Being focused on network-centric solutions this is something I would have considered a no-brainer from the initial design. Any separation/disconnect between a user-interface and the equipment/software it is controlling is inherently a bad thing, even if it is only for a few seconds.

  • heldal: the intentional behaviour regarding remote connect during boot is of course to have it connected ASAP. And of course this is designed so that it should connect quickly.... unfortunately there seems to be a problem with that mechanism, and this is a bug / software issue.