Debugging the analog data bus of a Roland JX3P

I've been having problems with my JX3P (modified with a Kiwi 3P kit) recently. Had been working very well for months and months, but everything went extremely quiet one day. Kiwitechnics have been super helpful and suggested that it didn't sound like an MCU problem, and gave me a couple of debugging tips. They are awesome.

Last weekend I finally had a few hours to investigate, so I opened her up!

Everything sounded extremely quiet with the occasional very loud noise. The moment it went loud was not completely random... It seemed to coincide with more than 3 key presses, although not consistently (sometimes I could press 6 keys and nothing would happen... At other times, it causes the loud noise).

First off, I checked the volume levels of the patches. Strangely, they had all become extremely low. I'm not sure why, but my guess would be a knock. In the course of this analysis, I realised there was a weak connection inside one of my MIDI cables - this could be related :)

So I increased the level of the active patch, and sure enough I could hear the notes again. However, a problem remains (otherwise I wouldn't have bothered with this post). The same reproduction steps I described above now make everything *even louder* despite the VCA levels for the active patch being set to maximum!!

A few knowns at this stage:

1. The problem is related to multiple (more than 3) keys being pressed at once (although the pattern isn't obvious)
2. It seems to be unrelated to specific voices (as each voice chip works fine in isolation)
3. The resultant level goes beyond what it should be capable of (max VCA level on any given patch)

So I started looking a the multiplexers used in the JX3P... the "4051" chip:

 

The 4051 is a clever little chip. It can be used to multiplex (bring together) or de-multiplex (split apart) 8 individual signals. The signal active on pin 3 (the input or output signal pin... depending on whether we are demultiplexing or multiplexing, respectively) is determined by the bit pattern on pins 9, 10 and 11. Whether it is multiplexing or demultiplexing is controlled by the signal on pin 6.

This chip is used to set the different analog outputs that control the various blocks in the analog signal path of the JX3P. Including the VCAs for each voice chip (which control the amplitute of the notes...)

Achieving change

We've been discussing several radical policy changes recently at Bluefruit. One of these is the possibility of getting rid of Annual Leave altogether and encouraging people to take more responsibility for finding the right time to take a holiday. This idea in itself is worthy of a blog post (or a book...)

On a highly related note, a regular discussion theme we have with people who come to us with product ideas they would like help with, is about the conflict between the value of having a system which people are familiar with (due to previous incarnations of it) and a system which is more innovative (and therefore less familiar).

I spent some time articulating this for a few of our customers this week, and realised that it's something worth sharing.

There are several stages to achieving change. To move from one stage to the next requires investment to overcome a unique "energy barrier", the nature of which depends very much on what you are trying to change and how quickly and radically you are trying to change it.

1. Existing doctrine
The concept to overcome here is that "it is the way it is because that's the way we do it...". That doesn't mean ignoring the positive aspects of the way it is in our attempts to innovate, simply that the fact of it being a certain way is not good rationale for it remaining that way.
 
2. Theoretical acceptance of change
Once it's been agreed that change is worthwhile, a new proposal has to be made which is theoretically accepted (not only by customers, but also management and engineers, in the case of Bluefruit Software).
 
3. Practical acceptance of change
Ah, the move from the theoretical to the practical! Not to be undestimated... I wouldn't say it is easier to accept theoretical change than practical. In some ways, and again depending on the exact context, it's much easier to accept something practically because you get to experience the change and decide on whether it's positive or not.

4. New doctrine
Once everyone has accepted that the change works on a theoretical and practical level, it is still necessary for that change to become the new "doctrine". A really great idea can be borne out practically and then completely ignored by everyone who should be adopting it.

(and repeat... if you're lucky!)

Sometimes the energy barriers involved in achieving new doctrine are simply not worth overcoming due to the energy investment required, but more often it's a matter of approach.


Some of the energy barriers involved :

- Familiarity
- Time
- Cost
- Information "battle"
- Regulation

If change can be experimented with in bite-size chunks, it helps a lot, because you're moving less change through the process. If we imagine for a moment that "change" is something physical and the energy barriers involved are related to mass and physics, it is very easy to visualise what's happening when we "push through" innovative changes.

This is one of the huge advantages of Agile, as it reduces the cost of change by placing more emphasis on practical experiment, and also relies on stakeholders being integrated with the process.

Always interested in discussing this if anyone is keen!

Thanks