Posts by heldal


    Software Engineer here - I objdumped the macos binary and it does look like it's written in Cocao -

    Yes, but the kernel isn't really in play here, is it? They might need to write new USB drivers, but that's only part of it. The rest is UI specific- so if you're talking about Android... well the Android UI (which is done in Java) - is very different from the OSX or Win32/64 ui. It's very difficult to go from desktop to mobile OS. It's a clean, ground up rewrite.


    Linux, in general, is ALSO not a RTOS. Yes, there are kernel versions that are more realtime than the master branch, but it's in exactly the same boat as MacOS and Windows. Further, the optimizations required for both of those platforms are well known (on a mac it's even easier now). So Linux doesn't really have a leg up on Apple of Microsoft here at all. If it did, I'd be running ProTools on Linux.


    Honestly, I don't think there's the support for the platform needed to warrant a port of RM to Linux. It would be cool, yeah, but given that most users of the Kemper are NOT CompSci majors, it doesn't make sense to target a 0.1% platform.

    I'd rather see more improvements to RM for all users.

    Looking at binaries you wold find traces of UI-libraries from the local OS everywhere. That doesn't rule out the use of higher level abstraction layers.


    There are UI-abstraction-tools that even include the most common mobile platforms, although their efficiency may be questionable.


    Real-time is not an issue for RM itself, but the reality is that a lot of people use it in a home/studio-environment as an element in a more complex media-creation platform.


    The standard linux-kernel is not real-time-compliant, but with the RT-patches it is 100% compliant with acknowledged RT-standards. Even a standard kernel compiled with low-latency-options is a lot better than most of the competition. There are of course more than decent alternatives to linux, but those do not include Apple or Microsoft. Systems that makes it very hard for users to even prevent things like automated maintenance-procedures from interfering with their workflow are far from optimal as a media-platform.


    I completely agree that usability must be first priority, which of course makes the most common operating systems first priority too. My point is only that systems could be improved. In the current environment where media is mostly paid by advertising nobody really represent the consumer anymore. If people knew more about alternatives they may choose differently, which in turn could push the major players to produce better solutions. Given the resources at their disposal, I find it almost ridiculous that Apple and MS have not yet come up with better solutions.

    I suppose this will not happen. First, way too few people using Linux. And then: RigManager is not built with a GUI framework like QT which would have made it very easy to run RigManager under Windows and Linux and... This was a design decision and I think Kemper will not revert it.

    I don't think the application has been completely rewritten for macos vs windows so there is probably some form of abstraction layer used. Do you know which, and also positively that it isn't available for linux?


    Not too many linux desktop-users yet, but the number is slowly rising. The number of people using devices running a linux-kernel OTOH is huge. Everything from being embedded in gadgets of all sorts to full-blown terminal units with Android (smartphones, tablets, smart-tv etc) . Neither windows nor macos are proper realtime-operating systems which is a huge advantage for manipulating audio and video information so I would not be surprised to see more applications moving in that direction. With macos or windows you really have to work hard to strip the systems down to an absolute minimum to turn it into a reasonably stable and responsive multimedia workstation. Meanwhile there are versions of linux with full realtime capabilities. Linux have come a long way since its conception in the early 90s. In the early years commercial entities wouldn't touch it with a stick. Today there's wide speculation among tech journalists that even MS may drop their proprietary OS-kernel for linux at some point.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    My impression is, there is only a problem with one of your Performances: #2.

    I would overwrite that Performance and rebuild it from scratch.

    I see the same with random performances. For some reason the KPA seems to handle things better after scrolling past the same performances once or twice, but it still tends to randomly skip performance when using the front-panel buttons. Reporting it as a bug yields a response saying it is a known problem.


    I have no problem scrolling between performances with the remote.


    If there is a problem with a performance or individual slot I would prefer that the KPA produces an error-message so that I can take action. To silently skip due to incorrect or malformed data is not a good solution.

    My point is just that the Kemper has an option of running monitor-out in stereo by using direct-out as the second monitor-out. When using that you may keep the main-out-level detached from the master-volume and thus be able to adjust your monitor level with the master-knob on the KPA without affecting what goes to FOH or recording. You may do the same with the level on your poweramp. I use an active stereo-cab with controls on the back which makes it a lot more convenient to adjust the volume on the KPA.

    So next thing I will try is main outs L/R into the power amp in stereo..And I still have 2 DXR10s..thanks for all suggestions sofar.

    You may be better off switching to stereo-monitoring and feed monitor-out + direct-out to your monitor-amp. That gives you the option of adjusting monitor-level separate from main/recording output-level.

    Thanks, would it actually make sense to run a single 2x12 speaker in stereo? would stereo effects be better seperated on the 2 speakers in a single 2x 12 or not?

    I'm using a 2x10 active stereo cabinet from Blueamps and the stereo separation definitely has an effect, although not the same as with separate L/R speakers. At home, practising with the speaker next to me on a shelf (<1m away) , it sounds great with stereo effects. On stage the effect is more about creating a "fuller" sound than a single speaker. The sound gets much "thinner" if I run the KPA's monitor-out in mono into the same cabinet in mono-mode.

    it works for now, but it's very very slow loading pages etc.

    Do you mean that you KPA is slow when scrolling through performances (bank up/down for those used to MIDI terms)? This may have to do with default settings. By default the KPA starts loading and processing all 5 slots in a performance as soon as you hit up/down, making it appear very slow for scrolling across multiple performances. Try setting "Pending" to "Perf.Load" in system-settings (bottom right on page 3) . This force you to choose a particular slot after scrolling to the correct performance (bank) which has the side effect of delaying any processing of the content of the performance till the selection has been made, thus make scrolling performances much faster.

    RigManager terminated unexpectedly is what I get when terminating the application. This prevents an upgrade to the current 3.0.111. There is no 3.0.111 on the website (yet?) so I am also unable to perform the upgrade outside of RM. Any pointers?

    While I appreciate the approach with the Kabinet and Kone these will still be unable to defeat bad/unusual acoustic properties on location. When placed in a corner on a cramped stage any amp/speaker-combination will sound way off from what the same gear sound like under ideal conditions. I believe this problem largely could be defeated by analysing the room through a microphone placed near the position of the guitar-players ears and from the analysis apply filters to an enhanced monitor-output-EQ (multiband) on the KPA. When used with monitors other than the Kabinet or Kone this solution would also compensate for the characteristics of the actual monitor/speaker(s) used. The key to this solution is to have analysis-software specifically tailored for the microphone used. There could be models for a set of specific 3rd-party microphones, but the most realistic solution may be to deliver the solution in the form of an optional measurement microphone and corresponding KPA software-update. Finally, it should be possible to adjust the enhanced monitor-output-eq to taste after the automatic room-compensation has been executed and applied.


    I know there is more to a rooms acoustic properties than what can be adjusted with EQ, but EQ goes a long way for the short-range between player and speaker on a stage or in a rehearsal-room. I invested in a high-end stereo monitoring-solution for my KPA some time ago. It works very well under decent conditions at home and at rehearsal, but due to "boxy" sound on many stages I have since complemented it with a stereo multiband EQ sitting between the KPA and monitor. The approach outlined above would both eliminate the need for additional equipment and significantly reduce the time spent adjusting the EQ. For gigs covering many different genres the manual process include playing, listening and adjusting (at gig volume) for at least 4 or 5 different rigs/profiles on the KPA. The adjustments made to a flat EQ for a clean tone may need further refinement for distorted sounds and vice versa, but I am always able to find a setting that works reasonably well for the entire gig.

    I have observed the same as reported above.


    Conclusion: firmware 7.2.1 changed the assigned function for the tap-button on the remote. Later releases can not know whether the change was intentional or accidental so everyone who have loaded 7.2.1 need to check button-assignments for the remote in system settings.

    Hardware: Non-powered head from 2015

    OS: 7.2.2.16146

    Rigs: 808

    Boot-time: 1:08

    Time till remote-ready: 1:19 (9 sec after the main unit)


    I don't know how much integrity-checking is done at startup, but it it either a lot or the unit must have very slow NVRAM.


    The extra time waiting for the remote is frankly unnecessary. The current implementation reies fully on periodic retries to connect. Recent firmware delay power-on to the remote in an attempt to align the boot processes for each unit, but it is hit or miss whether they both are ready at the exact same time. The better approach would be to make both units work as broadcast transmitters and receivers and make the first unit that get a swift response (<100ms) to a "hi anybody there" message responsible for establishing the connection. That would eliminate any unnecessary waiting for the other unit to become active.

    Can someone rename this thread "Kone logistics" and start a new Q&A-thread instead. I don't mind threads discussing just about anything, but please have some respect for the topic! A good Q&A-thread should have an initial post that gets maintained with new Q&A-pairs added as new important/common questions appear.

    Works great but it requires 4U of space.

    If there is a bit of room at the bottom and the rack will let you mount the KPA straight to the bottom you may squeeze it into 4U, but on a shelf it needs 5U. I've got my toaster in a shallow SKB 6U rack with a Line6 G90 1U wireless-receiver on top and a Furman power-conditioner mounted vertically next to the KPA.