Archive of the former Yahoo!Groups mailing list: Korg Poly800/EX800 Users

previous by date index next by date
previous in topic topic list next in topic

Subject: Re: [korgpolyex] Velocity sensitive

From: Atom Smasher <atom@...>
Date: 2009-01-09

On Fri, 9 Jan 2009, Michael Hawkins wrote:

> The only part of this list that is not doable given the CPU cycle
> constraints is probably the one most ppl might want the most which is...
>
> Velocity to Amplitude. I can't do this because it would require a
> massive rewrite of the code and a massive increase in CPU cycles (of
> which there none to be had).
=======================

there seems two ways to approach that: adjusting the overall level, or
scaling EG1/2. either would effectively control the volume.

i would've thought it would be a simple matter of:
velocity ∗ scaling ∗ levels
or even
velocity ∗ scaling
but my electronics and programming expertise is far removed from the
8085.

of course, given the unusual signal path of the poly800, either method
would create some... uhhh... weird sounds when notes of different
velocities overlap. i'm in no position to predict whether that would sound
like crap, or be the next "big thing", but it would be
difficult/impossible to duplicate with other synth architectures.


> I don't think it's worth doing break point, sustain level etc and the
> math is so complex, I don't think I want to take it on anyway.
===========================

agree. there's a line where you have to say it's enough, and those are on
the far side of the line. of course i wouldn't complain if the features
were included... but i would also not complain in their absence.


> So here I post the list again (with my suggested priority) but now can
> people reorder them and see if we can come up with a consensus on what
> should be done first.
>
> Vel > filter cutoff Vel > resonance Vel > FM-800 Vel > EG1/2 attack Vel
> Vel > filter cutoff
> Vel > resonance
> Vel > FM-800
> Vel > EG1/2 attack
> Vel > EG1/2 decay
>
> Vel > harmonics mapping
>
> Vel > oscillator interval
> Vel > oscillator detuneVel > LFO speedVel > LFO wave change
> Vel > EG1/2 release
================

that seems to me like a reasonable order or priority, the only exception
being that my wish-list would have vel->volume in the top three or top
four.

i'm also not sure if there's a need to have "LFO wave change" controlled
by velocity, but i won't complain if it's there.

if/when you figure out a way to implement vel->volume, maybe we'll see
velocity scaling for all of the EGs??


--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"Security systems fail in one of two ways. They can fail to stop
the bad guy, and they can mistakenly stop the good guy. The TSA
likes to measure its success by looking at the forbidden items
they have prevented from being carried onto aircraft, but
that's wrong. Every time the TSA takes a pocketknife from an
innocent person, that's a security failure. It's a false alarm.
The system has prevented access where no prevention was
required. This, coupled with the widespread belief that the bad
guys will find a way around the system, demonstrates what a
colossal waste of money it is."
-- Bruce Schneier, 15 March 2005