1.6.0 Aftermath - A "Standardised Toolkit" for reporting issues?

  • Enlightened Forum Men,
    Some questions/thoughts for those in the know...Sifting through the debris of the great 1.6.0 debate can we think of a better way of reporting issues? Now, assuming of course that CK hasn't had a nervous breakdown over all this and intends to release future updates, there are bound to be further teething problems with subsequent beta versions - unavoidable really.What might help with this testing if we had a "standardised toolkit" for reporting issues. Some suggestions under three headings:


    1. A set of very simple dry clips that could be re-amped - then we could compare different betas/FWs in a more meaningful way. E.g
    (a) Simple strummed chord
    (b) Arpeggiated chord
    (c) Single line notes below 12th fret
    (d) Single line notes above 12th fret
    Volume might be an issue here - with even slight Db differences affecting perception - but I'm sure we could find an agreed way of doing this.
    There's a lot of talented players here - be a nice advert for them. But I stress - simple clips are probably just as good. Although a library of different clips to cover different styles would be no bad thing. E.g I only hear this problem when I mute a death power chord... :)


    2. Wave form / Spectrum analysis - a problem here as not everyone has things like Ozone, but most wave editors feature some sort of spectrum analysis. I like the Ozone features with the red line showing the differences... those in the know can suggest which tool is most useful - perhaps someone from the Development team could chip in. You have an army of beta testers here - let's get them organised!


    3. Latency tests: Yes I know... run screaming. But as CK pointed out, how else can you quantify 'feel'? Can anyone suggest a tool we could use to report on this?

    Appendix:
    (a) Quick word on jokes... every musician I've ever been around has been a bit of a p*ss taker - banter lightens the mood, lets not get too sensitive about this stuff.
    (b) Open letters to CK... not singling anyone out here but I really don't think some of the language used recently helps anyone. Sure, complain if you're not happy (Afterall, we're not cult members in purple robes...) but let's keep the right side of the line in terms of decency. Otherwise... why would he post here? We are a stronger community for having his direct involvement.
    (c) One for the developers this really - what about an export function that contains a snapshot of users settings? (Credit to djdyer for the most recent member to suggest this :thumbup: )


    With the collective talent we have here the recent thread was a little too chaotic in terms of how people were going about things. I think we can do better...Yep there are problems with attempting this but after all.... we are a rather special community aren't we... much better than others we could mention 8)
    We could thrash out the details in this thread and perhaps 'sticky' the final results. Could help all involved...
    Thoughts?


    Fellow forum man, Brett

    Suhr Classic Pro, Fender deluxe Strat & Baja Tele, Gibson ES335, Ibanez S Prestige 2170FW, Eastman AR371CE, Variax JTV > KPA > Patch bay inc. Strymons (Mobius, Timeline, Blue Sky), H9 Max, TC Triple Delay, & POD HD500 > Adam A7Xs

  • All good observations and proposals.
    I'm all for it, standardized procedure when difficulties arise.
    Which leads to a premise: the willingness of the affected user to specify/quantify something, even if it's a perception.
    And we as users should try to get better at this.

  • Good thread! :thumbup: The Kemper engineers will know best what they need to know to analyse a problem, so best for them to develop a complete reporting tool that saves all the user settings, system settings,all the hidden software parameters that we have no knowledge of and also allows the user to record a short wave file to the USB. The Kemper engineers will then surely have everything they need. So this would work something like:
    1) press system button
    2) select reporting tool
    3) prompt to put USB stick in the back (or front)
    4) prompt to play for 5 seconds
    5) prompt to stop playing
    6) KPA saves snapshot file and WAV file to the USB stick
    7) send snap shot file and WAV file to suppport with a description of the problem.


    If Armin (or the beta testers) had been able to do this for both 1.54 and 1.6 I feel sure the Kemper engineers would have quickly understood the problem.

  • Excellent Idea - I think djdyers idea to have some sort of a snapshot from the KPAs perspective would work well too. It would be nice to disable this in release versions or sort of minimize it's function/memory footprint in some way.

  • Excellent Idea - I think djdyers idea to have some sort of a snapshot from the KPAs perspective would work well too. It would be nice to disable this in release versions or sort of minimize it's function/memory footprint in some way.

    Of course... this might be done via any forthcoming hypothetical external editor, which would remove any sort any memory footprint on the Kemper...
    Still - sometimes we need our ears as well as empirical evidence, plus many men seem very attached to their 'feelings' 8) (A good thing btw)
    If we combine both approaches we have converging evidence - Plus maybe a library of dry clips to reamp - could even use them to power a built in .kipr player for the exchange. Granted, it seems a bit of work but so was that last 80 page thread... :whistling:

    Suhr Classic Pro, Fender deluxe Strat & Baja Tele, Gibson ES335, Ibanez S Prestige 2170FW, Eastman AR371CE, Variax JTV > KPA > Patch bay inc. Strymons (Mobius, Timeline, Blue Sky), H9 Max, TC Triple Delay, & POD HD500 > Adam A7Xs

  • Sounds like a good idea to me. The Kemper already has some self tests in it's debug mode, perhaps they could add some of these tests your'e suggesting internally, e.g running the same test pattern that's used to profile through a rig and recording the result to the USB stick as an output (that should give you the complete picture of the dynamics and response), and I'm sure it's possible to work out the overall latency of a unit minus the ADC/DAC (which should be static anyway unless the chips changed) internally and see how things are doing.


    That way even if you don't have access to the tools to re-amp you could at least generate meaningful data that could be sent to Kemper support.