I knew someone would call me out on this.
OK, the initialisation "operating variables" of EG1, EG2 and EG3 look like this
EG1_ATTACK_EXTOP: .block 5 ; start of extended EG1_ATTACK operating variables
EG1_DECAY_EXTOP: .block 4 ; start of extended EG1_DECAY operating variables
EG1_SLOPE_EXTOP: .block 8 ; start of extended EG1_SLOPE operating variables
EG1_RELEASE_EXTOP:.block 5 ; start of extended EG1_RELEASE operating variables
That's five bytes for Attack, four for decay, eight for slope and five for release.
Then, each voice envelope generator (and EG3) has its own array of 6 bytes.
At this point in time, I know that the Poly has to make various precalculations to create these 22 values based upon the EG user parameters. Some of those calculations include linear to log conversion, timer table lookups and finite state machine initializations. But that is the extent of my knowledge of the operation of the EG mathematics. And at this point in time, I have absolutely no idea whatsoever as to how those 22 bytes are translated into the 8 bytes that each EG actually uses in real time to generate the envelope for each voice.
I've been really busy trying to put lots of other features into the Poly. So, I've been able to decode many parts of the EG operation but not the actual EG's envelopes setup and operations themselves.
As a result, I am reasonably certain that you are right that it would be possible to modify these bytes to modify the envelop in real time.
However, I am also very certain that the Poly-800 6Mhz 80C85 CPU is NOT going to have enough speed to do it fast enough to be workable in the Poly.
And unless someone else wants to start helping to reverse engineer the incredible complexity of these EG's, I will take the EG array method any day since I know it works having already kludged the sustain pedal to change the decay and release of notes.
Of course, I am committed to eventually work out exactly how the EG's work. Mostly for my own amusement (perhaps I should be committed to an asylum). But also because I want a fourth EG to be available. Either way, getting to the bottom of the operation of those EG's is no simple task and it is definitely going to take a LONG time to get to the bottom of it all. Meanwhile, the array method looks promising.
Mike
From: ASSI <Stromeko@...>
To: korgpolyex@yahoogroups.com
Sent: Friday, January 16, 2009 11:48:29 AM
Subject: Re: [korgpolyex] Accent envelope
Hi Michael,
On Friday 16 January 2009, Michael Hawkins wrote:
> I've done an analysis of the code that sets up the envelopes. The
> Poly-800 CPU is not fast enough to recalculate the envelope in real
> time according to velocity value and adjust any envelope parameter
> in a proportional way. If we were to try to do such a thing there
> would be a noticeable delay between hitting a key and hearing the
> note sound (and this is an ongoing challenge that I've faced
> through this entire project).
>
> So the only option is to use the same sort of set up as I used with
> the sustain pedal operation. If the sustain pedal is down then the
> decay and release values are increased by an offset value that is
> set by extended parameter 74. When you set the extended parameter,
> the Poly does all of the envelope recalculations right there and
> then and creates a second set of real time operating variables for
> the envelope generator to copy and use in real time at note on
> onset. At the moment, the only variables in the envelope data set
> that are being adjusted are decay and release. The rest are being
> copied from the original envelope data set to the secondary data
> set. But we can indeed adjust the other envelope parameters
> according to our whims.
[...]
I believe you can do significantly better for the velocity stuff than
just switching between parameter sets. Start the envelope right away
with the standard parameter set (which if I read you correctly
entails copying the pre-computed parameters to some place in RAM that
is exclusive for that voice). Then iterate a correction on that
parameter set each time you update that voice. The first portion of
the attack may not be overly accurate, but you should be able to end
up with a correctly scaled envelope overall.
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth. Stromeko. net/Downloads. html#WaldorfSDad a