FW 4.0 beta experiences thread.

    Quote from domsch1988


    Not really. The point of Beta's is "We have something ready we think is great. Test it and tell us what you think". Sometimes bugs like the ui latency aren't easily fixed and it hasn't been out that long. I personally think they should add some kind of "kown problems" part to the download page. Apart from that the lag is annoying but not funtionally breaking the KPA. Maybe they aren't sure what the problem is, so 4.0.4 and 4.0.5 where attempts to fix the behavior, which didn't work out. Such a complex Software isn't allways easy to troubleshoot or fix.
    Apart from that (coming from a android developer background) if some ui hiccup is bothering you, you are maybe not the target audience for Beta Software. I'm not trying to offend anyone, but if you expect everything to work as good as the last stable, the beta version is not for you :whistling:


    I don't expect everything to work as good as the last stable; what didn't work for me in the beta was the reason I went back. It's just my opinion that they'd get more productive feedback from users if there weren't so many versions floating around. I had an entire performance ruined because of no sound coming out because of a glitch in 3.something. A glitch that was intermittent, yet part of a release version, not even a beta! Each time one thing is changed, there's no telling if there will be new unintended consequences. 4.03 was stable as far as working without any sound glitches that would ruin a performance, at least in my trials. But who knows if that will be the case if I try 4.04, 4.05, 4.06 and so on? Each time something is changed, there's always the chance that a new problem will emerge. Therefore, it's to everyone's advantage to have as few versions to put through the paces as possible. Thus my point, why release a beta that has known issues, at least without a disclaimer of what the known issues not addressed are? Such as "this beta addresses these problems, but still has these known issues." Plus with so many imperfect versions and various feedback on these forums of issues, it's hard to sort out which version people are complaining about. This then results in fewer people (such as myself) willing and able to try out betas and therefore fewer users to discover any new bugs, in particular ones that are more intermittent and easily missed like the one I experienced in 3.whatever it was.

    For me it's always been quite easy: If you rely on the thing to work (KPA or Phone or PC) don't install any Updates without having proper feedback if they work perfectly. At work we Update Firewalls regularly. After a new release of Software (even stable) we wait a week, read some forums and test on a test system. Although the manufacturer says everything is fine and it's non beta. Thats because the firewall is the most critical part of our networks. Any small bug/failure might have huge implications.
    TLDR: If you need it to work, don't install updates that where just released.


    The rest is how the kemper guys want to work with it. I agree with you, that many versions (especially in beta phase) are counterproductive. But I'd much rather have it like that then them going the samsung way of releasing updates 1 year late und doing nothing to keep users up to date on the status...

    Are we talking about the same Samsung who, after two years pass, abandons all effort to update their TV OS and instead push a counterfoil of an Android-App update on you that nixes given paid for functionality (EULA yayddayadda), functionality the buyer's decision was based upon, while introducing total and utter incompatibility with any industry standarts the home LAN was based on?


    Then, yeah, heard of them, bought from them, ignored gut feeling, learnt my lesson.


    BTW, the 4 update seems only slower on floorboard processors faster than 16MHz, from my personal viewpoint.


    Peace,
    Shred



    --------------------------------------------------------
    [bigfoot|project]
    Only now, while supplies last!
    Nuke plant not included!


    Just kidding. There is no spoon.

    Quote from domsch1988

    I personally think they should add some kind of "kown problems" part to the download page.


    +1 To this. The way LIne6 are managing their Helix adventure seems an excellent example to me (I have been following the mega thread on TGP and their attitude is simply astonishing. Definitely every competitor should learn from them. Really a study case for the industry segment).


    Also, I believe they should extend their tests on Windows7 systems. I might have got this wrong, but I got the impression that they only use 8 and 10 ATM?

    Quote from domsch1988

    The point of Beta's is "We have something ready we think is great. Test it and tell us what you think".


    Wrong. You are describing the intention of an alpha release. A beta isn't "something" it is the final product. The beta-stage should not be about anything other than squashing bugs. Substantial problems with functionality and/or performance at this stage are red flags that should lead to the termination of the current sub-release and return to alpha-stage in a new branch.


    A developer would expect a beta to be full-featured and have no issues with functionality or performance. Most developers in a software workshop will move on to other projects once a product reaches the beta-stage as only minor bug-fixes are to be expected at this stage. The only difference between the last beta and the final release should be the version number, as has often been the case with KPA firmware.

    Edited once, last by heldal ().

    Like 1
    Quote from domsch1988

    I agree with you, that many versions (especially in beta phase) are counterproductive.


    I agree that the optic could looks not so good due this approach.
    At the other side the updates was coming very quick after knowledge of a problem and it was very useful for people with the wish to use the morph function now.
    In my case no really problem arised during a live gig. There was minor disturbances when testing/tweaking rigs or making new performances.
    For me this way had advantages and I never had the feeling to have a big risk.
    It was published that the general database will be modified and this is alway a huge risk.
    At the other hand it seemed to be necessary so Kemper can continue to develope more functionality with the given hardware for benefit of us all.
    I have no problem staying patience for this topic and I wish the crew good success.


    As a professional in important productions I would use Vers 3.3 - but I think that thousands of users can help now to finish this Version.

    My guess is the Kemper team is following an Agile development methodology which allows for multiple beta releases as part of the individual development cycle releases.


    There's nothing wrong with that and trying to define some sort of standard for what 'beta' mean is as ludicrous as it is pointless. There is never going to be a pure standard that everyone follows and adheres to (even within a single company often) and every development team is going to come up with its own SDLC and what each stage and term means. It apparently works for them and you can either accept it or not, but I my bet is that they are going to continue to do things the way they do them regardless.

    Quote from viabcroce

    Also, I believe they should extend their tests on Windows7 systems. I might have got this wrong, but I got the impression that they only use 8 and 10 ATM?


    you are taking about rig manager, are you? look at the download page. it says compatible with windows 7-10 and that's what we test against.

    Get in touch with Profiler online support team here

    Like 2

    Once I had a Problem with connection the VOX tonelabST via USB to a Win7 PC. (Not always)
    I had contact with VOXAMP support.
    Not the first but I found a specialist there who told me that he know that in Win 7 there is a bug in the adress management MIDI port via UBS-connection.
    He sent me a programm to uninstall not used MIDI driver. (The name was "KORG MIDI Driver Uninstall Utility" and worked with all Midi devices)
    As far I remembered it was something like that driver are assigned more than one time to the list and in a certain area of this list it makes confusion in the application programms.
    Win 10 seems to have another adress management, because this programm is not valid anymore.
    I do not know how KPA is communicating with the PC - but perhabs also via a MIDI port. Than there could be this problem.
    I am not so familiar with Win in details but maybe another has now an assosiation.

    Quote from domsch1988

    Did that yesterday. It's non conclusive. There seems to be a difference. V4 sounds a bit tighter and clearer. But it's impossibly close. might be nothing... I just found that the JP-2C patch started sounding "bad/weird" to me on both firmwares... Maybe my ears are fatigued as i have the same with other patches... If your focusing to much things start to get weird ;)


    Exactly.


    In a perfect world, one would be able to put one's state (mental and physical) on pause, do the FW update and then resume testing from where one left off. Not going to happen!


    This is why I suggested the recording for A/B comparison.

    Quote from G String


    you are taking about rig manager, are you? look at the download page. it says compatible with windows 7-10 and that's what we test against.


    I stand corrected, this is what I though I grabbed from a conversation with Support.



    Quote from Sharry

    I do not know how KPA is communicating with the PC - but perhabs also via a MIDI port. Than there could be this problem.


    It might be indeed useful if Kemper confirmed (or excluded) this.

    Quote from viabcroce

    you are taking about rig manager, are you? look at the download page. it says compatible with windows 7-10 and that's what we test against.


    I was talking general 'bout communication of some devices with the PC via USB.
    The RM is a application programm and can not run if the commuinication between PC and KPA is not working correct.
    It is a qualificated guess that it has something to do with the Midi Port list, because I spend almost a month till my Tonelab could be managed by PC.
    For me it was new (but not surprising) that communication via USB for some gear is done via MIDI port. (Like my Midi keyboard, like toneLab, like Roland Canvas SD 50, Guitar Rig and some other gear I do not use at the moment)
    I agree that Kemper could clarify easy - but maybe the contact via support with a clear question is quicker.
    Till know I do not understand when they react here and when not ;)

    Edited once, last by Sharry ().

    I may have encountered a new... 'issue' with 4.05. I bought the M.Britt Tweedy pack and never got around to loading it until now. I put them in the Rigs folder in the Shared folder on my flash drive and its been loading slowly for over 15 minutes. The bar IS moving so I am going to let it go but that seems awfully long. Not sure its worth opening a ticket yet but if I encounter an error I will.

    And more crashes in 4.0.5. I've just had 4 crashes in a single 2 hour session here at home.


    When the crash happens, in all cases I was:

    • In Performance mode.
    • Using the Kemper Remote.
    • Using the Morph feature.
    • Playing a beautiful Gretsch.


    In all cases the crash looked like this:

    • Remote becomes unresponsive, does not respond to buttons, screen goes dark and enters sleep mode.
    • Profiler becomes unresponsive, does not respond to buttons.
    • Last selected rig continues to play just fine, so the core engine is still running.
    • Power down using the chicken head knob works, but takes seconds to respond. This suggest that the Profiler *is* listening, but very slowly.


    It must be the guitar. ;)


    Hope this helps,
    Robert.

    Quote from Sharry


    Did you try to use another Cable to remote?


    No I didn't, only have one atm. But since the Profiler is acting up as well I think the Remote and cable are OK. Looks like the Profiler's DSP or FPGA or whatever that does the audio is fine too, but the CPU responsible for screen, responses to button presses and communication with Remote is acting up. And as a result the Remote goes to sleep, because it senses the connection is lost. That's my idea at least.