[sdiy] Communications with voices in a polyphonic synth

[cheater cheater]

On Thu, Mar 11, 2010 at 23:07, Neil Johnson <neil.johnson97 at ntlworld.com> wrote:
> Hi,
>
> cheater cheater wrote:
>>>
>>> 2) Why should 'matrix destination' packets get priority over key ons?
>>> Parameter changes are a lower priority.
>>
>> Because you want the note to be started with the parameters that
>> depend on the note event (velocity, pitch, etc), instead of it
>> starting at some default value and then changing quickly to a new
>> value. That would be a glitch.
>
> MIDI does this already (passing velocity and note information in a single
> message).
>

You misunderstood the premise, Neil.
It was that the voice was, I thought, trivially controlled, and had no
modulation matrix of its own, in which case you would have a central
modulation matrix and would need to set up the voice before the note
starts. Obviously there's no reason or even way to transmit voice
parameters to the voice if the mod matrix is completely internalized
to the voice.

>> OSC is really easy. It's probably going to be easier for you to do OSC
>> than midi. For one thing, you can skip the state machine crappiness.
>> And it's much easier to debug though, since it's all just plaintext.
>
> Parsing a text-based protocol vs. a compact bit-encoded protocol "easier" on
> a resource-constrained time-critical embedded processor?  No.

No, but parsing OSC is easier than parsing MIDI, because a proper MIDI
parser is more difficult. MIDI is not only a 'compact bit-encoded
protocol'. Either way, MIDI is a shitty protocol that kills musical
expression. It would be nice if people let it die finally, but
somehow, everyone still seems to cling to it obsessively, either
because they don't realize they can do better, or they don't know how,
or they have no imagination of what they could use a better solution
for because they're not musicians.

> Debugging ... well, if MIDI is used as the messaging protocol then a little
> hardware adaptor and a PC can be used to record, decode, parse, slice, dice,
> analyse to death the message stream.  Or write one to handle 9-bit messages
> if going for multiprocessor-mode RS485.

A midi state machine is much more difficult to write than an OSC
parser. How many opensource midi parsing implementations do you know
of? I could write an OSC parser in half an hour, and that's so long
only because I haven't written one before. You just keep parsing
characters, jumping to the next string comparison if you do or
skipping the rest of the packet if you don't find a string what you
support. Then you finally push some values on the stack and run the
right function.

OSC is a verbose protocol, and I don't necessarily recommend doing it
on a dsPIC, but then again I don't know what's actually possible on
it; you're just doing string comparisons most of the time, that's a
simple operation, especially when you're comparing against constants,
so it shouldn't be so bad. Either way we're in the 21st century, not
the 18th century, we don't have to measure our bandwidth in single
bauds per second anymore. Throughput of connections has improved just
about a million times since the 80s, no reason why message size
couldn't grow by only 100 times at *some* point still in our lives.

But either way, an rs or can version could be great as well. Just
please, don't lock yourself into midi again. Try to think greater than
that.

D.