[sdiy] Communications with voices in a polyphonic synth

[Tom Wiltshire]

On 11 Mar 2010, at 11:38, Neil Johnson wrote:
>
> Ok, so on that chip you have a choice of SPI, I2C, UART and CAN:
>
> * I2C is limited to 400kHz if going off-board, but has HW support  
> for in-band addressing.
>
> * SPI as discussed looks like a no-no (too many pins).
>
> * CAN goes up to 1Mbit, lots of HW support for addressing so  
> minimising SW overhead.
>
> * UART goes up to 10Mbaud, in 9-bit mode can do in-band addressing  
> to minimise SW overheads.
>
> I'd choose either CAN or UART and with differential signalling.   
> But - as has been asked already - what speed do you *NEED*..?

Well, "as fast as possible", obviously! Isn't that always the answer?!

Practically, though, I have been thinking about this, as John Speth  
suggested - quantify the problem and you might solve it.

I want the time taken from pressing a key to the note starting in the  
voice processor to be <2mS. There, that's the specification.
There's obviously a lot of software in that path, so it depends on  
(for example) how fast the keyboard is scanned. In many ways the  
voice comms is one of the smallest sources of delay, but there's no  
reason why it should be a larger delay than it needs to be.
Let's assume that we have <0.25mS to get the message from the main uP  
to the voice. The other 7/8ths of the time will be eaten up by  
parsing at both ends and such like. If I was trying to get an address  
byte and a double-byte of data into that time, that'd imply a data  
rate of 100Kbit/S or better. Not very demanding.

I'd like to thank everyone for their help and ideas on this topic.  
All really good stuff.

Having read through the relevant datasheet sections for the various  
interfaces I have available (the 4 Neil mentions above) I think I'm  
leaning towards CAN. This is because (1) it seems to be designed for  
this sort of thing (2) it is plenty fast enough (3) it has lots of  
hardware options for addressing and filtering. Any software I can  
eliminate is a good thing, because my poor voice processors have  
enough to do already, what with audio and modulation sources.

As far as the protocol goes, one or two people suggested using MIDI  
internally. This seems like a sensible idea to me. Like Veronica  
said, why reinvent the wheel? It has all the messages I'm going to  
need, there's a specification already done that I can work to, and  
I'll have data coming in from the outside world in that format  
already. I can always tweak it a bit if I really need to.

I think the next step is probably a multi-voice test setup, with one  
main uP talking to a group of voice uPs. For the test, I can use just  
the raw voice uPs and mix their audio outputs together. This is/will  
be a basic dsPIC digital synth. After that, I take the tested comms  
code back to the voice board hardware I have and see if I can't get  
the whole lot running at once. I'll keep you posted if I come up with  
anything good.

Thanks everyone.

Tom