[sdiy] Fwd: Voice assignment algorithms

[cheater cheater]

Hi Paul,
you've only sent this to me, I assume you wanted to send this to the
list, so forwarding.

I find it useful to click 'reply to all' which includes the sdiy address.

Cheers
D.


---------- Forwarded message ----------
From: Paul Cunningham <paul at cometway.com>
Date: Thu, Mar 25, 2010 at 22:08
Subject: Re: [sdiy] Voice assignment algorithms
To: cheater cheater <cheater00 at gmail.com>


My own sentiment on this probably echoes cheeter's, which I
interpreted as "don't waste too much time optimizing your algorithms
unless you are using an extremely weaksauce cpu" because saving a
nanosecond here or there is not as paramount as getting your algorithm
working in a way that is useful and maintainable. If you come up with
something really good that would benefit from ASM-level coding, you
got your blueprint already worked out. But C-generated code is pretty
fast for embedded programming.

When you are talking about voice stealing architectures in an 8-voice
(or even paraphonic) synthesizer, you are talking about arrays and/or
queue sizes that are very small and traversable in a miniscule amount
of time using even the worst-case iteration algorithms.

I'm glad Tom started this thread though because I've been thinking a
lot about this topic lately and it's nice to hear other people's ideas
about how they go about doing this stuff. I agree with cheater that
it's not really all that complicated and I wouldn't expect that there
are "papers" on the topic. But if you look at each synth design out
there, each one of them probably has it's own unique story about how
they did voice assignment. -pc

On Mar 25, 2010, at 4:24 PM, cheater cheater wrote:

> Hi Tom,
>
> I think the most important thing to say here is: make technology work
> for what you want, not the other way around. Voice assignment
> algorithms are so simple that there's reeeeally no reason to optimize
> them, or to only do the simplest ever voice assignment mode, when you
> could be happy with something less simple (to not say complicated).

> ...

> C is quick enough, pretty much as quick as tape-based programming can
> be, unless the implementation sucks or the hardware is way
> underpowered. If you really wanted to press for performance, then you
> can implement highest- or lowest-note-priority with just AND gates and
> a lot of wire, or a tiny FPGA. In fact, I think you could implement
> any classical note logic this way!
>
> D.