[sdiy] FW: FW: Communications with voices in a polyphonic synth

[Paul Cunningham]

the big problem with string based protocols -- and i do like them for debugging -- is that they need dedicated buffers or they will consume too much stack space. that is, unless they are handled one byte at a time in a stateful manner (midi-style). dedicated buffers tend to work against thread-safe code, and that can be a bitch to debug no matter how pretty your protocol is.

i've used simple protocols loosely based on CSS, and while there was some string processing and parameter label optimization to compress the size, the overhead was not particularly noticeable in my application. however, if you got the RAM and MHz i do recommend it. it was really nice to spit that stuff out to a terminal in realtime and be able to read what's going on. my own situation was a 16MHz 8-bit freescale chip with 32K running wireless protocols and could just barely afford it.

everyone wants a better MIDI, but it really does work quite well for its age and size. it's so tiny and concise and tends not to waste a single bit anywhere! getting the bytes from one component to another intact, especially if there's any multiplexing going on, can be aggravating without something like parity to keep it all straight. -pc

On Mar 12, 2010, at 11:58 AM, Tom Wiltshire wrote:

> 
> On 12 Mar 2010, at 14:56, Jerry Gray-Eskue wrote:
> 
>> OSC, using text strings is going to be processor intensive, no big deal with
>> a desktop or high end DSP, but when using a small micro and very limited
>> ram/code space/processor speed it gets hard to get good performance and may
>> not fit in the code space.
> 
> Jerry's right - this is the killer.
> 
> OSC looks fine, but even storing the strings would be a big deal on a PIC. You haven't got *any* string slicing/dicing functions unless you write them, so it turns into a lot of code, which is then going to be slow. Byte-size MIDI messages are better from that point of view.
> 
> T.