Random loss of sound output last night at bar.

[burningbusch]

Be aware the the vector joystick is often programmed to control volume of the two parts to a program. So inadvertently moving the vector joystick can result in a loss of output volume. If this happen on one particular program, you might look at going into the vector control area and turning off volume control. It's possible your vector joystick is dirty or faulty and that's causing a large jump in values even when it's apparently not being moved.

Also, the Master volume slider obviously controls the overall volume of the program.

Did you try switching to other programs when this happened? That should reset all controls. Also, are you using a volume or expression pedal?

Busch.

[Dniss]

Had the same problem last week at home.

Went to get a coffee and on my return I had no sound. Eveything appeared to work, except I had no sound.

I rebooted the K and I had sound again.

Well then, time for a trip to the authorized service center.

I will wait till this becomes a recurring problem.

[Dniss]

Had the same problem last week at home.

Went to get a coffee and on my return I had no sound. Eveything appeared to work, except I had no sound.

I rebooted the K and I had sound again.

Is this a new behavior (with all factors/equipment/cables the same) after upgrading to 3.0.2? Just curious.

I'd have to yes, because I never had this problem before.

[Dniss]

Had the same problem last week at home.

Went to get a coffee and on my return I had no sound. Eveything appeared to work, except I had no sound.

I rebooted the K and I had sound again.

Is this a new behavior (with all factors/equipment/cables the same) after upgrading to 3.0.2? Just curious.

Do you remember when you tried to play if the VU meters were showing any "internal" output?

I didn't think of looking at these. Eventhought I turned off the K, I thought the problem was somewhere else.

I'll remember for next time, if there is a next time.

[Dniss]

Did you try switching to other programs when this happened? That should reset all controls.

Yes, I did. That's the first (and ony thing) I tried before rebooting.

[Derek Cook]

Deleted post dulicate

[Derek Cook]

Well, does your Kronos work fine at home? If it does, then yes you have
faulty cables or bad mixer channels or a bad D.I.

Yes, works fine at home, but the thing that gets me is, no sound (all cables in place), reboot (without touching any cables) and sound is back. Maybe the internal jacks are sketchy? (Another possibility)? Or these particular cables aren't engaging the internal contacts as well as the ones at home? Will bring cables from home next time. if happens again, will swap out to see if any change.

A faulty cable connection would not have been cured by a reboot.

As a question, do you use a UPS/Line Conditioner on stage? That is one recommendation I picked up via this forum when researching the purchase of a Kronos.

I'll go a little OT and tell you about a problem I had a few weeks back, but it's a relevant discussion for all the people who will tell you it was not a bug and must have been your cables.

I had a problem with hanging notes on the Kronos at band practice the other week, and it was only on certain combis, not all. It was cured by a reboot.

It happened at home the following day (different MIDI cables in my studio) and was cured by a reboot. The very nice man at Korg UK I have been discussing the issue with assures me that it cannot possibly be a bug in such a fine and professional product and it must be my MIDI cable or some external influence - on stage it was Kronos sounds triggered from my EX5.

But in the studio I progressed to having NOTHING connected to MIDI (and I literally mean no cables in any Kronos MIDI port) and narrowed it down to timbres in a combi on Channel 1 and I could recreate the problem from the Korg keyboard. It was cured by a reboot and has not been seen since. So I have politely agreed to differ with the very nice Korg man, in as much that until we know the cause it could be a bug and I have promised to create a detailed report if it happens again. Unfortunately I didn't note anything down on first investigation, and I rebooted expecting the problem to still be there to get a clean baseline to do the documenting of the problem, but when I rebooted it wasn't there and I haven't seen it since!

So there is a possibility that your problem might be a bug and don't let people tell you otherwise unless you have proof one way or the other.

I have developed and project managed safety critical software projects, so I know that you cannot guarantee software is bug free unless the developers perform 100% branch and decision coverage of the code, and that is VERY expensive to do, so companies would not do that as a matter of course. An industry standard metric is that "standard" software will go into testing with a bug every 1000 lines of code and you then have to find them all.

Another thing to consider about bugs is that they appear random but they are not random; they are 100% deterministic.

Hardware will have a failure rate based on mean time between failure of all of its components. But software has "no wear out mechanism". Its reliability does not getter or worse over time other than it (hopefully) matures as bugs are fixed in product releases (with hopefully no new ones being introduced ) Software failures are caused by a specific combination of input conditions that leads to the bug, and every time you hit those input conditions that lead to the bug then the probability of failure of the software is 100%! It will happen every time.

That's all worth knowing (so I hope you find the digression interesting) and it means it is important to narrow down the trigger conditions of the problem; something I failed to do with my Kronos hanging notes problem.

As an example of this sort of issue, we had a problem on a safety related system we delivered, which had actually been through a very formal test process, where a subsystem was occasionally failing. It took us a few months (on and off) to find the failure condition, but once we knew what it was we could reproduce it every time - 100% failure rate with the trigger conditions, but we could then fix it, and the solution was adding one line of code to stop a "MUTEX" (a means of synchronising software processes) from blocking.

Another example is we used to run a 30 year old mainframe in one application until it was replaced. It was considered bug free and had had no updates for 10 years. In its final year of use a bug was discovered because it was used in a slightly different way for a new requirement that it was being used for. That bug had laid dormant for 30 years until the trigger combination occurred.

That is all relevant as that is the challenge for a manufacturer like Korg. I am not criticising the Kronos or Korg's engineering processes in any way, and the Kronos is a brilliant product. The observation is that software is very complex and unless you have an systems engineering process that gives 100% code coverage then you cannot say that there are no bugs in the software. The challenge then is when users report issues is to try and get a reproducible case for them to investigate. For seemingly random bugs (but they are not!) the challenge is to find a reproducible failure condition. I've been there and I know how difficult it is to do so!

Hope that is useful and adds some understanding to the debate about "is it a bug" and "it cannot be a bug" observations, and the conclusion is unless a developer can show you test evidence of 100% code coverage, then there is a probability that a released product contains bugs waiting to be found.

Is my problem or your problem due to a bug? You can't say, but equally you can't say that it isn't until you know the cause.