Prophet '08 Main OS 2.2.7 Final

This is the final candidate for the Prophet '08 Main 2.2.7 and Voice 1.5 OS update

Change Log:

1. Additional Arpeggiator modes added - additional octaves and random modes
2. Sequencer Slew added -  You can now use a sequence to control the slew rate of the previous sequencer. Eg., if you set Sequencer 1 up then you can set the destination of sequencer 2 to the very last selection, 'Seq Slew' and vary the amount for the slew individually for each step of sequence 1
3. Encoder response updated - This greatly improves the response of the encoders both for the new and old versions of the hardware. There is a new global value 'Enc Mode' where you can select between 'Detent' and 'No Detent' options for the responsiveness of the encoders. If you have one of the Pot Edition front panel sets with non-detented encoders for all encoders except Param 1/2, select the 'No Detent' option and it will correctly set the Param 1/2 encoders to detented response
4. Several minor bug fixes

For those who are updating from a 1.X OS, this includes the other 2.0 Updates including 2 channel Multi Mode

Prophet '08 Keyboard OS 2.2.7: P8Key_Main_2.2.7.syx
Prophet '08 Rack OS 2.2.7: P8Rack_Main_2.2.7.syx
Prophet '08 Voice OS 1.5: P8_Voice_1.5.syx

Prophet '08 Beta Encoder update

Edit: Updated to Main OS version 2.2.5 and Voice OS 1.5

Now that the code is working I've run through this beta a few times over just to make sure it's functioning as is expected; so far so good! It has been improved across the board; slow, medium and fast response, acceleration and error correction. If you start using the beta I'd really appreciate any feedback on the responsiveness and how it feels in each of those modes. I won't be able to get it perfect for everybody and I'm pretty happy with how it feels here but I'd like a consensus that it's at least a pretty substantial improvement. If it's a bit off somewhere I'll definitely poke around a bit to see if I can tighten it up further.

I cannot guarantee that this will solve problems with encoders that have a mechanical problem. Please contact support@davesmithinstruments.com if you have encoders that continue to jump around or are unresponsive.

DO NOT USE THIS CODE IF YOU ABSOLUTELY NEED YOUR P08 WORKING!!! It's a Beta. If for some reason this causes your P08 to hang, it will be at least a few days before I can swap a board so you can get going again. So for now, don't update unless you can handle a few days without it.

I can't make an exhausted list of Sysex problems because, quite frankly, there are just too darned many issues I've seen. I'll probably put together a more full post on this and exactly how sysex is used (sort of like the NRPN posts below) with some examples and tips on editing and automating sysex changes for the Evolver line. For now, here's a few little Sysex and update related things to be aware of when doing your Prophet '08 OS update:

1. Make sure you can update the OS successfully with a Sysex file first. I don't have the time to troubleshoot all the possibilities and there are a lot of them. The biggest problem I've run into is running a class compliant USB MIDI device with Windows XP (it has OS related sysex issues with larger sysex files which I won't detail here) so don't even bother if you have one. You'll need drivers from the manufacturer that have the sysex bug worked out.
2. I have successfully loaded this OS using MIDI OX with Windows XP and Sysex Librarian on OSX. Those are the two Sysex utilities I'd recommend.
3. I do NOT recommend the Soundtower editors to do the sysex updates at this time. We've had some small errors with them in the past and I'm not confident the code has been worked out yet.
4. If on Mac OSX and it doesn't work the first time around with Sysex Librarian, try setting the transmit speed to 80%. That fixed most of the problems I was having with it
5. Certain interfaces have issues that are hard to pinpoint; here are a few we are aware of:
MOTU Ultralite Mk. 3 needs a driver update, the older ones have a very annoying intermittent bug with sysex transmissions
For some reason we can't get any Digidesign interfaces to correctly transmit the sysex files in Windows XP 


I created a google group for DSI Beta information which I may start using for comments and such, for now it's just an easy way to upload files and link them here. You can join there if you'd like to post direct comments about the OS but please keep other topics out for now.

Here's the Main OS 2.2.3 Beta: P8Key_Main_2.2.5.syx
And the Voice OS 1.5 Beta: P8Key_Voice_1.5.syx
And the thread in the Prophet 5/08 forum for discussion: Prophet '08 Beta Discussion

Prophet '08 Encoder Issues

Figure we'll start this blog off with the big issue, I'll see if I can explain the problem a little more clearly so people know what's going on and what the solutions are right now and what's coming up:

Physically the encoders work by several small metal "brushes" attached to the rotating shaft. Each one of these brushes slides over several spaced out metal plates as you turn the encoder. When a brush hits one of the plates it connects one of two signal pins coming out of the encoder to a high voltage, then when it slides off the plate, the voltage drops back to zero. The plates that the brushes slide over are spaced in such a way that when you turn the encoder it sends out pulses on the two pins that are phased either +90 degrees or -90 degrees depending on the direction you are spinning. This is known as a quadrature or incremental rotary encoder (http://en.wikipedia.org/wiki/Rotary_encoder#Incremental_rotary_encoder)

Anything interfering with the connection from the brush to the metal plate is going to cause the electrical connection to drop to zero very quickly. Instead of a nice clean pulse wave, we get a pulse with a lot of holes. Depending on the timing, this will look to the processor like a very quick direction change, a slightly longer direction change (about one full pulse length) or just totally invalid data. On the Prophet '08, as many of you well know, usually when this happens you seem to get stuck between two values and can't go up or down further until you slow down the turn. We'll call the interference between the brush and the metal plates 'noise' for now.

So we know that a noisy encoder will cause those jumpy values; the more noise, the more jumpy. To solve this problem let's start by having a look at what can cause that noise:

1. Oxidation of the metal causes a jumpy electrical connection when the brush passes over due to patches of low connectivity on the metal surface.
2. Turning the encoder faster causes the brushes to bounce up and down slightly as they hit the turn, if they bounce too high they lose connection with the plate and breaks the electrical connection.
   
3. Pulling up on the encoder shaft can cause the brushes to hit less solidly as well because of the slight give in the housing.
   
4. There is a lubricant/grease inside each encoder that helps the brushes connect. If this is removed or washed off it can have severe effects on the output. It also slowly wears off due to oxidation and just drying up as the encoder ages.

So what can we do to solve this? We want to do anything we can to improve the electrical connection of the spinning brushes. Going backwards from what causes the noise we have two main hardware solutions: bend or push the brushes down harder against the plates as they turn (but not too hard to cause more bouncing) or add connectivity in the form of a lubricant that will prevent the brushes from bouncing and improve the electrical conductivity when they do pass over the plates.

This is why we started sending out Deoxit tubes to anyone who had the encoder issues. We found that applying a couple drops of deoxit to all the encoders fixes close to 95% of the boards we've seen. It does a good job of removing the oxidation and keeps the brushes sliding over the surface smoothly. It's likely that a batch of encoders had the lubricant washed off and putting a little additional on will get it running smoothly again.

However there are the more extreme cases where deoxit does not fix the problem. Since we test the encoders before sending the instruments out it's likely they looked OK during testing but after a little oxidation in the real world and some mild usage and the problem reared it's ugly head. Maybe the metal of the brushes is a bit weaker in that batch, maybe the deoxit isn't strong enough to take all the oxidation off, we don't know. At this point we have only a couple options... replace all the encoders or look a bit deeper and figure out how to compensate in software.

I've been working on a software fix for the encoder issues, both preventing a low to mid grade of noise from causing the encoders to get stuck on values or change direction and a more general revamp of the encoder processing to improve the responsiveness. I'm a knob tweaker at heart and not being able to do a filter sweep with a flick of the fingers on a Prophet '08 breaks my heart. Sadly, It has turned out to be a much more complicated issue than hoped so it's taken a while to iron out. But do not lose hope! The Mopho Keyboard will have greatly improved responsiveness on the encoders which will be ported back as best I can. The response needs to be calibrated for the non-detented encoders and I'll run it against bad boards I've received to see if I can get them responding at least in a stable way.

I'll post an update here as soon as I have a beta Prophet '08 and Tetra OS ready with some encoder improvements to get a little feedback on the responsiveness.