Korg Poly800/EX800 Users

On Fri, 2009-01-16 at 14:54 +0000, Alex Drinkwater wrote:
> Cool!
> 
> 
> Switching, rather than 'proportionally morphing' the envelopes was
> what I had in mind, actually.
> Good to hear it's possible :)

Incidentally that's how the 303 accent envelope works - the decay time
for the filter is set to minimum when accent is triggered, and the
accent pulse is shaped to slow the attack down at high resonance
settings.

I suspect it's impossible to accurately emulate this on any other
synthesizer, without cheating and using velocity layers.

Gordon

On Fri, 16 Jan 2009, Michael Hawkins wrote:

> For example, we might decide that we want the envelope to change 
> behavior when the velocity was above 63. Below 63 the envelope would 
> behave in one manner and above 63 it would behave in some other way (for 
> example, reducing the attack time by some offset).
==============

that'd be cool, especially if the level could be part of what's different. 
it's kind of a 303-ish approach.

another way that might work... *if* i understand it correctly and *if* 
there's enough RAM and if we can accept a decrease in velocity resolution 
from 127 to (let's say) 16 or 32... can we precompute 16 (or 20, 24, 32, 
64?) envelopes, and based on velocity pull the appropriate precomputed 
envelope from a table in RAM? the precomputation would have to take place 
when a patch is loaded or an envelope is edited (and would take time), but 
it seems like it could be a workable time/space tradeoff if the conditions 
can be met...


-- 
         ...atom

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

 	"Politics would be a helluva good business
 	 if it weren't for the goddamned people."
 		-- Richard M. Nixon

As long as  the velocity resolution remains at 127 steps for  
modulating other things, like Cuttof, Res. etc.

a|x

On 16 Jan 2009, at 15:07, Atom Smasher wrote:

> On Fri, 16 Jan 2009, Michael Hawkins wrote:
>
>> For example, we might decide that we want the envelope to change
>> behavior when the velocity was above 63. Below 63 the envelope would
>> behave in one manner and above 63 it would behave in some other  
>> way (for
>> example, reducing the attack time by some offset).
> ==============
>
> that'd be cool, especially if the level could be part of what's  
> different.
> it's kind of a 303-ish approach.
>
> another way that might work... *if* i understand it correctly and *if*
> there's enough RAM and if we can accept a decrease in velocity  
> resolution
> from 127 to (let's say) 16 or 32... can we precompute 16 (or 20,  
> 24, 32,
> 64?) envelopes, and based on velocity pull the appropriate precomputed
> envelope from a table in RAM? the precomputation would have to take  
> place
> when a patch is loaded or an envelope is edited (and would take  
> time), but
> it seems like it could be a workable time/space tradeoff if the  
> conditions
> can be met...
>
>
> -- 
>          ...atom
>
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
>
>  	"Politics would be a helluva good business
>  	 if it weren't for the goddamned people."
>  		-- Richard M. Nixon
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On Fri, 16 Jan 2009, Michael Hawkins wrote:

> Yes, I just *knew* that you would be both smart enough and sharp enough 
> to work that out.
>
> The answer yes, it could be done. At the moment, I have just two 
> envelope "sets" but this could be expanded.
>
> Now what was it you were saying about not modding the HAWK-800 for more 
> flash?
>
> Because the limitation here is going to be the size of the code which is 
> bloating the more you keep talking! LOL
====================

is the limiting factor here the size of the code? or the size of the RAM? 
with the HAWK v1.3 how many envelopes could be precomputed and held in RAM 
(assuming the functionality is available to all EGs, but even then can we 
dynamically trade resolution for how many EGs respond to velocity)?

how thoroughly has the EG code been optimized? what if there's only one EG 
in the firmware, and ALL of the envelopes are precomputed? that might be a 
feasible RAM/ROM tradeoff...? it might even lighten the load if velocity 
isn't even used in a patch...?

damn... it's sure easy to come up with ideas when someone else is writing 
the code ;)


-- 
         ...atom

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

 	"I see in the near future a crisis approaching that unnerves
 	 me and causes me to tremble for the safety of my country...
 	 corporations have been enthroned and an era of corruption in
 	 high places will follow, and the money power of the country
 	 will endeavor to prolong its reign by working upon the
 	 prejudices of the people until all wealth is aggregated in a
 	 few hands and the Republic is destroyed."
 		-- U.S. President Abraham Lincoln, 21 Nov 1864

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#WaldorfSDada

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