Korg Poly800/EX800 Users group photo

Yahoo Groups archive

Korg Poly800/EX800 Users

Index last updated: 2026-04-05 20:10 UTC

Thread

Velocity sensitive

Velocity sensitive

2009-01-09 by Michael Hawkins

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). 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.

The rest I will parse through and think about, although most of them look doable on immediate examination.

What's more important though, is that everyone that has a HAWK kit now should try to put all of these into some sort of priority.

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 > EG1/2 decay

Vel > harmonics mapping

Vel > oscillator interval
Vel > oscillator detuneVel > LFO speedVel > LFO wave change
Vel > EG1/2 release

Mike.




________________________________
Show quoted textHide quoted text
From: David Mochen <davidmochen@...>
To: korgpolyex@yahoogroups.com
Sent: Friday, January 9, 2009 1:06:51 PM
Subject: Re: [korgpolyex] best hardware arpeggiator


Hi,
 
*Vel > Eg 1, 2, 3, and 4 Amplitude (not 
sure if this is the best techie way to describe it but, basically, the harder 
you hit, the louder it sounds/the more the VCF opens up/the more EG4 affects 
global pitch/noise)
 
*Vel > all EG steps (att, dec, brk p, slope, 
sus, rel) or at least some of them
 
*Vel > filter cutoff and reso
 
*Vel > FM-800
 
*Vel > oscillator interval
 
*Vel > oscillator detune
 *Vel > LFO speed
 
*Vel > LFO wave change
 
*Vel > "muting/unmuting" the different 
harmonics? Say, play lightly, only first harmonic is heard... play harder, a 
more sawtooth-like sound 
is heard as the remaninig 3 harmonics are engaged. 
Dunno if it is feasible, though.
 
(if any other ideas come to me, i'll let you 
know)
 
BTW, all the above should be possible to be 
assigned both positive and negative modulation on the targets. Also, some sort 
of keyboard tracking would be cool.
 
Who knows? maybe the Atomahawk 800 will end up as a 
poor-man Oberheim Matrix 12? Ha, it feels so nice just asking The Man for 
more... like a kid in a candy store...
 
dave
 
----- Original Message ----- 
From: Michael  Hawkins 
To: korgpolyex@yahoogro ups.com 
Sent: Friday, January 09, 2009 10:45  AM
Subject: Re: [korgpolyex] best hardware  arpeggiator

OK, this is great feedback.

I've been making good progress going  back over my code and collapsing certain parts of it into reusable functions  so that the memory use is actually dropping right now.

I also have been  thinking about the ARP too. It is not on the top of my list that is for sure.  I think a simple ARP is a good idea for those of us who don't use computers or  a hardware sequencer. But how many of us are in that position?

Since I  was able to get the sustain pedal working and actually change the EG1/2  sustain in real time according to the pedal, it is now quite possible to  change any part of the EG parameters according to velocity.

I believe I  can do the same for EG3.

So I can see that altering attack on EG1/2 or  EG3 might be things we'd like to change according to velocity.

What  other parameters might we want changed according to  velocity?

Mike





________________________________
 From: David Mochen  <davidmochen@ hotmail.com>
To: korgpolyex@yahoogro ups.com
Sent: Friday, January 9, 2009 9:09:53  AM
Subject: Re: [korgpolyex]  best hardware arpeggiator


i'd say the HAWK-800 is well on the way to "killer" without a sequencer  or 
arpeggiator. somewhat disregarding my own personal wish-list (LCD &  sysex 
for panel events), i think velocity sensitivity is the *only* thing  the 
kit is "missing".

-- 
...atom

 
100% agree.
 
Dave

Re: [korgpolyex] Velocity sensitive

2009-01-09 by electrohead2000@yahoo.com

Your priority list looks good. Has anyone mentioned Velocity > MG depth?
Also, I might have missed something earlier, does the Hawk kit disable the sequencer?


On Jan 9, 2009, at 1:37 PM, Michael Hawkins <korgpolyex800@yahoo.com> 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). 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.

The rest I will parse through and think about, although most of them look doable on immediate examination.

What's more important though, is that everyone that has a HAWK kit now should try to put all of these into some sort of priority.

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 > EG1/2 decay
Vel > harmonics mapping
Vel > oscillator interval
Vel > oscillator detune
Vel > LFO speed
Vel > LFO wave change
Vel > EG1/2 release

Mike.

Show quoted textHide quoted text
From: David Mochen hotmail.com>
To: korgpolyex@yahoogroups.com
Sent: Friday, January 9, 2009 1:06:51 PM
Subject: Re: [korgpolyex] best hardware arpeggiator

Hi,
*Vel > Eg 1, 2, 3, and 4 Amplitude (not sure if this is the best techie way to describe it but, basically, the harder you hit, the louder it sounds/the more the VCF opens up/the more EG4 affects global pitch/noise)
*Vel > all EG steps (att, dec, brk p, slope, sus, rel) or at least some of them
*Vel > filter cutoff and reso
*Vel > FM-800
*Vel > oscillator interval
*Vel > oscillator detune
*Vel > LFO speed
*Vel > LFO wave change
*Vel > "muting/unmuting" the different harmonics? Say, play lightly, only first harmonic is heard... play harder, a more sawtooth-like sound
is heard as the remaninig 3 harmonics are engaged. Dunno if it is feasible, though.
(if any other ideas come to me, i'll let you know)
BTW, all the above should be possible to be assigned both positive and negative modulation on the targets. Also, some sort of keyboard tracking would be cool.
Who knows? maybe the Atomahawk 800 will end up as a poor-man Oberheim Matrix 12? Ha, it feels so nice just asking The Man for more... like a kid in a candy store...
dave
----- Original Message -----
Sent: Friday, January 09, 2009 10:45 AM
Subject: Re: [korgpolyex] best hardware arpeggiator

OK, this is great feedback.

I've been making good progress going back over my code and collapsing certain parts of it into reusable functions so that the memory use is actually dropping right now.

I also have been thinking about the ARP too. It is not on the top of my list that is for sure. I think a simple ARP is a good idea for those of us who don't use computers or a hardware sequencer. But how many of us are in that position?

Since I was able to get the sustain pedal working and actually change the EG1/2 sustain in real time according to the pedal, it is now quite possible to change any part of the EG parameters according to velocity.

I believe I can do the same for EG3.

So I can see that altering attack on EG1/2 or EG3 might be things we'd like to change according to velocity.

What other parameters might we want changed according to velocity?

Mike



From: David Mochen hotmail.com>
To: korgpolyex@yahoogro ups.com
Sent: Friday, January 9, 2009 9:09:53 AM
Subject: Re: [korgpolyex] best hardware arpeggiator

i'd say the HAWK-800 is well on the way to "killer" without a sequencer or
arpeggiator. somewhat disregarding my own personal wish-list (LCD & sysex
for panel events), i think velocity sensitivity is the *only* thing the
kit is "missing".

--
...atom
100% agree.
Dave


Yahoo! News

Get it all here

Breaking news to

entertainment news

Group Charity


Re: [korgpolyex] Velocity sensitive

2009-01-09 by Michael Hawkins

Which MG depth? DCO or VCF, resonance MG or FM-800 MG?

The list could get so long that there's no way the Poly has the cycles to handle it.

In fact, I really think the Poly is probably only capable of handling one at a time. Otherwise, Poly notes will sound half an hour after they were hit.

So I have split the velocity features into two groups.

Group 1 - technically simple and not CPU intensive
Vel > filter cutoff
Vel > resonance
Vel > FM-800
Vel > EG3 depth
Vel > VCF MG depth
Vel > DCO MG depth
Vel > harmonics mapping
Vel > oscillator detune - *** I doubt I would ever use this  - vote to remove from list

Group2  - technically complex and CPU intensive
Vel > EG1/2 attack
Vel > EG1/2 decay

Vel > EG1/2 release
Vel > LFO speed - *** I doubt I would ever use this - vote to remove from list
Vel > LFO waveform change - *** I doubt I would ever use this - vote to remove from list

Vel > oscillator interval - *** I doubt I would ever use this - vote to remove from list


I am working on other features at the moment so there is no rush to get this all agreed upon in a day or two but I would like to see everyone put their two cents in and work on this list.

Another thing that is out floating right now is getting EG4 created and working. I am beginning to think that there simply won't be enough CPU cycles to do it at all. One way to get CPU cycles back would be to change the EG's into ADSR instead of the ADBSSR Korg type. Who would be disappointed if we just made them into ADSR?

Mike.



________________________________
Show quoted textHide quoted text
From: "electrohead2000@..." <electrohead2000@...>
To: "korgpolyex@yahoogroups.com" <korgpolyex@yahoogroups.com>
Sent: Friday, January 9, 2009 1:52:54 PM
Subject: Re: [korgpolyex] Velocity sensitive


Your priority list looks good. Has anyone mentioned Velocity > MG depth?
Also, I might have missed something earlier, does the Hawk kit disable the sequencer?



On Jan 9, 2009, at 1:37 PM, Michael Hawkins <korgpolyex800@ yahoo.com> 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). 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.

The rest I will parse through and think about, although most of them look doable on immediate examination.

What's more important though, is that everyone that has a HAWK kit now should try to put all of these into some sort of priority.

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 > EG1/2 decay

Vel > harmonics mapping

Vel > oscillator interval
Vel > oscillator detuneVel > LFO speedVel > LFO wave change
Vel > EG1/2 release

Mike.




________________________________
From: David Mochen <davidmochen@ hotmail.com>
To: korgpolyex@yahoogro ups.com
Sent: Friday, January 9, 2009 1:06:51 PM
Subject: Re: [korgpolyex] best hardware arpeggiator


Hi,
 
*Vel > Eg 1, 2, 3, and 4 Amplitude (not 
sure if this is the best techie way to describe it but, basically, the harder 
you hit, the louder it sounds/the more the VCF opens up/the more EG4 affects 
global pitch/noise)
 
*Vel > all EG steps (att, dec, brk p, slope, 
sus, rel) or at least some of them
 
*Vel > filter cutoff and reso
 
*Vel > FM-800
 
*Vel > oscillator interval
 
*Vel > oscillator detune
 *Vel > LFO speed
 
*Vel > LFO wave change
 
*Vel > "muting/unmuting" the different 
harmonics? Say, play lightly, only first harmonic is heard... play harder, a 
more sawtooth-like sound 
is heard as the remaninig 3 harmonics are engaged. 
Dunno if it is feasible, though.
 
(if any other ideas come to me, i'll let you 
know)
 
BTW, all the above should be possible to be 
assigned both positive and negative modulation on the targets. Also, some sort 
of keyboard tracking would be cool.
 
Who knows? maybe the Atomahawk 800 will end up as a 
poor-man Oberheim Matrix 12? Ha, it feels so nice just asking The Man for 
more... like a kid in a candy store...
 
dave
 
----- Original Message ----- 
From: Michael  Hawkins 
To: korgpolyex@yahoogro ups.com 
Sent: Friday, January 09, 2009 10:45  AM
Subject: Re: [korgpolyex] best hardware  arpeggiator

OK, this is great feedback.

I've been making good progress going  back over my code and collapsing certain parts of it into reusable functions  so that the memory use is actually dropping right now.

I also have been  thinking about the ARP too. It is not on the top of my list that is for sure.  I think a simple ARP is a good idea for those of us who don't use computers or  a hardware sequencer. But how many of us are in that position?

Since I  was able to get the sustain pedal working and actually change the EG1/2  sustain in real time according to the pedal, it is now quite possible to  change any part of the EG parameters according to velocity.

I believe I  can do the same for EG3.

So I can see that altering attack on EG1/2 or  EG3 might be things we'd like to change according to velocity.

What  other parameters might we want changed according to  velocity?

Mike





________________________________
 From: David Mochen  <davidmochen@ hotmail.com>
To: korgpolyex@yahoogro ups.com
Sent: Friday, January 9, 2009 9:09:53  AM
Subject: Re: [korgpolyex]  best hardware arpeggiator


i'd say the HAWK-800 is well on the way to "killer" without a sequencer  or 
arpeggiator. somewhat disregarding my own personal wish-list (LCD &  sysex 
for panel events), i think velocity sensitivity is the *only* thing  the 
kit is "missing".

-- 
...atom

 
100% agree.
 
Dave

 
Messages in this topic  (1)  Reply  (via web post)  | Start a new topic  
MARKETPLACE

________________________________
From kitchen basics to easy recipes - join the Group from Kraft Foods  
Recent Activity
	*  3
New MembersVisit Your Group  
Yahoo! News
Get it all here
Breaking news to
entertainment news
Group Charity

Re: [korgpolyex] Velocity sensitive

2009-01-09 by Michael Hawkins

Oh and the HAWK-800 kit still has the sequencer.




________________________________
Show quoted textHide quoted text
From: "electrohead2000@..." <electrohead2000@...>
To: "korgpolyex@yahoogroups.com" <korgpolyex@yahoogroups.com>
Sent: Friday, January 9, 2009 1:52:54 PM
Subject: Re: [korgpolyex] Velocity sensitive


Your priority list looks good. Has anyone mentioned Velocity > MG depth?
Also, I might have missed something earlier, does the Hawk kit disable the sequencer?



On Jan 9, 2009, at 1:37 PM, Michael Hawkins <korgpolyex800@ yahoo.com> 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). 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.

The rest I will parse through and think about, although most of them look doable on immediate examination.

What's more important though, is that everyone that has a HAWK kit now should try to put all of these into some sort of priority.

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 > EG1/2 decay

Vel > harmonics mapping

Vel > oscillator interval
Vel > oscillator detuneVel > LFO speedVel > LFO wave change
Vel > EG1/2 release

Mike.




________________________________
From: David Mochen <davidmochen@ hotmail.com>
To: korgpolyex@yahoogro ups.com
Sent: Friday, January 9, 2009 1:06:51 PM
Subject: Re: [korgpolyex] best hardware arpeggiator


Hi,
 
*Vel > Eg 1, 2, 3, and 4 Amplitude (not 
sure if this is the best techie way to describe it but, basically, the harder 
you hit, the louder it sounds/the more the VCF opens up/the more EG4 affects 
global pitch/noise)
 
*Vel > all EG steps (att, dec, brk p, slope, 
sus, rel) or at least some of them
 
*Vel > filter cutoff and reso
 
*Vel > FM-800
 
*Vel > oscillator interval
 
*Vel > oscillator detune
 *Vel > LFO speed
 
*Vel > LFO wave change
 
*Vel > "muting/unmuting" the different 
harmonics? Say, play lightly, only first harmonic is heard... play harder, a 
more sawtooth-like sound 
is heard as the remaninig 3 harmonics are engaged. 
Dunno if it is feasible, though.
 
(if any other ideas come to me, i'll let you 
know)
 
BTW, all the above should be possible to be 
assigned both positive and negative modulation on the targets. Also, some sort 
of keyboard tracking would be cool.
 
Who knows? maybe the Atomahawk 800 will end up as a 
poor-man Oberheim Matrix 12? Ha, it feels so nice just asking The Man for 
more... like a kid in a candy store...
 
dave
 
----- Original Message ----- 
From: Michael  Hawkins 
To: korgpolyex@yahoogro ups.com 
Sent: Friday, January 09, 2009 10:45  AM
Subject: Re: [korgpolyex] best hardware  arpeggiator

OK, this is great feedback.

I've been making good progress going  back over my code and collapsing certain parts of it into reusable functions  so that the memory use is actually dropping right now.

I also have been  thinking about the ARP too. It is not on the top of my list that is for sure.  I think a simple ARP is a good idea for those of us who don't use computers or  a hardware sequencer. But how many of us are in that position?

Since I  was able to get the sustain pedal working and actually change the EG1/2  sustain in real time according to the pedal, it is now quite possible to  change any part of the EG parameters according to velocity.

I believe I  can do the same for EG3.

So I can see that altering attack on EG1/2 or  EG3 might be things we'd like to change according to velocity.

What  other parameters might we want changed according to  velocity?

Mike





________________________________
 From: David Mochen  <davidmochen@ hotmail.com>
To: korgpolyex@yahoogro ups.com
Sent: Friday, January 9, 2009 9:09:53  AM
Subject: Re: [korgpolyex]  best hardware arpeggiator


i'd say the HAWK-800 is well on the way to "killer" without a sequencer  or 
arpeggiator. somewhat disregarding my own personal wish-list (LCD &  sysex 
for panel events), i think velocity sensitivity is the *only* thing  the 
kit is "missing".

-- 
...atom

 
100% agree.
 
Dave

 
Messages in this topic  (1)  Reply  (via web post)  | Start a new topic  
MARKETPLACE

________________________________
From kitchen basics to easy recipes - join the Group from Kraft Foods  
Recent Activity
	*  3
New MembersVisit Your Group  
Yahoo! News
Get it all here
Breaking news to
entertainment news
Group Charity

Re: [korgpolyex] Velocity sensitive

2009-01-09 by Alex Drinkwater

And I'd add (again)
EG3 decay (though I'm aware that would only be useful with certain  
Breakpoint/Slope setting, I still think it would be nice to get a  
'twangier', tighter envelope on bass sounds with higher velocity, for  
example).
Otherwise the list looks good to me.

a|x
Show quoted textHide quoted text
On 9 Jan 2009, at 20:16, Michael Hawkins wrote:

> Which MG depth? DCO or VCF, resonance MG or FM-800 MG?
>
> The list could get so long that there's no way the Poly has the  
> cycles to handle it.
>
> In fact, I really think the Poly is probably only capable of  
> handling one at a time. Otherwise, Poly notes will sound half an  
> hour after they were hit.
>
> So I have split the velocity features into two groups.
>
> Group 1 - technically simple and not CPU intensive
> Vel > filter cutoff
> Vel > resonance
> Vel > FM-800
> Vel > EG3 depth
> Vel > VCF MG depth
> Vel > DCO MG depth
> Vel > harmonics mapping
> Vel > oscillator detune - *** I doubt I would ever use this  - vote  
> to remove from list
>
> Group2  - technically complex and CPU intensive
> Vel > EG1/2 attack
> Vel > EG1/2 decay
> Vel > EG1/2 release
> Vel > LFO speed - *** I doubt I would ever use this - vote to remove  
> from list
> Vel > LFO waveform change - *** I doubt I would ever use this - vote  
> to remove from list
> Vel > oscillator interval - *** I doubt I would ever use this - vote  
> to remove from list
>
> I am working on other features at the moment so there is no rush to  
> get this all agreed upon in a day or two but I would like to see  
> everyone put their two cents in and work on this list.
>
> Another thing that is out floating right now is getting EG4 created  
> and working. I am beginning to think that there simply won't be  
> enough CPU cycles to do it at all. One way to get CPU cycles back  
> would be to change the EG's into ADSR instead of the ADBSSR Korg  
> type. Who would be disappointed if we just made them into ADSR?
>
> Mike.
>
> From: "electrohead2000@..." <electrohead2000@...>
> To: "korgpolyex@yahoogroups.com" <korgpolyex@yahoogroups.com>
> Sent: Friday, January 9, 2009 1:52:54 PM
> Subject: Re: [korgpolyex] Velocity sensitive
>
>
> Your priority list looks good. Has anyone mentioned Velocity > MG  
> depth?
> Also, I might have missed something earlier, does the Hawk kit  
> disable the sequencer?
>
>
> On Jan 9, 2009, at 1:37 PM, Michael Hawkins <korgpolyex800@  
> yahoo.com> 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). 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.
>>
>> The rest I will parse through and think about, although most of  
>> them look doable on immediate examination.
>>
>> What's more important though, is that everyone that has a HAWK kit  
>> now should try to put all of these into some sort of priority.
>>
>> 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 > EG1/2 decay
>> Vel > harmonics mapping
>> Vel > oscillator interval
>> Vel > oscillator detune
>> Vel > LFO speed
>> Vel > LFO wave change
>> Vel > EG1/2 release
>>
>> Mike.
>>
>> From: David Mochen <davidmochen@ hotmail.com>
>> To: korgpolyex@yahoogro ups.com
>> Sent: Friday, January 9, 2009 1:06:51 PM
>> Subject: Re: [korgpolyex] best hardware arpeggiator
>>
>>
>> Hi,
>>
>> *Vel > Eg 1, 2, 3, and 4 Amplitude (not sure if this is the best  
>> techie way to describe it but, basically, the harder you hit, the  
>> louder it sounds/the more the VCF opens up/the more EG4 affects  
>> global pitch/noise)
>>
>> *Vel > all EG steps (att, dec, brk p, slope, sus, rel) or at least  
>> some of them
>>
>> *Vel > filter cutoff and reso
>>
>> *Vel > FM-800
>>
>> *Vel > oscillator interval
>>
>> *Vel > oscillator detune
>>
>> *Vel > LFO speed
>>
>> *Vel > LFO wave change
>>
>> *Vel > "muting/unmuting" the different harmonics? Say, play  
>> lightly, only first harmonic is heard... play harder, a more  
>> sawtooth-like sound
>> is heard as the remaninig 3 harmonics are engaged. Dunno if it is  
>> feasible, though.
>>
>> (if any other ideas come to me, i'll let you know)
>>
>> BTW, all the above should be possible to be assigned both positive  
>> and negative modulation on the targets. Also, some sort of keyboard  
>> tracking would be cool.
>>
>> Who knows? maybe the Atomahawk 800 will end up as a poor-man  
>> Oberheim Matrix 12? Ha, it feels so nice just asking The Man for  
>> more... like a kid in a candy store...
>>
>> dave
>>
>> ----- Original Message -----
>> From: Michael Hawkins
>> To: korgpolyex@yahoogro ups.com
>> Sent: Friday, January 09, 2009 10:45 AM
>> Subject: Re: [korgpolyex] best hardware arpeggiator
>>
>>
>> OK, this is great feedback.
>>
>> I've been making good progress going back over my code and  
>> collapsing certain parts of it into reusable functions so that the  
>> memory use is actually dropping right now.
>>
>> I also have been thinking about the ARP too. It is not on the top  
>> of my list that is for sure. I think a simple ARP is a good idea  
>> for those of us who don't use computers or a hardware sequencer.  
>> But how many of us are in that position?
>>
>> Since I was able to get the sustain pedal working and actually  
>> change the EG1/2 sustain in real time according to the pedal, it is  
>> now quite possible to change any part of the EG parameters  
>> according to velocity.
>>
>> I believe I can do the same for EG3.
>>
>> So I can see that altering attack on EG1/2 or EG3 might be things  
>> we'd like to change according to velocity.
>>
>> What other parameters might we want changed according to velocity?
>>
>> Mike
>>
>>
>>
>> From: David Mochen <davidmochen@ hotmail.com>
>> To: korgpolyex@yahoogro ups.com
>> Sent: Friday, January 9, 2009 9:09:53 AM
>> Subject: Re: [korgpolyex] best hardware arpeggiator
>>
>>
>> i'd say the HAWK-800 is well on the way to "killer" without a  
>> sequencer or
>> arpeggiator. somewhat disregarding my own personal wish-list (LCD &  
>> sysex
>> for panel events), i think velocity sensitivity is the *only* thing  
>> the
>> kit is "missing".
>>
>> -- 
>> ...atom
>>
>> 100% agree.
>>
>> Dave
>>
>>
>>
>>
>> Messages in this topic (1) Reply (via web post) | Start a new topic
>> MARKETPLACE
>> From kitchen basics to easy recipes - join the Group from Kraft Foods
>> Recent Activity
>>  3
>> New Members
>> Visit Your Group
>> Yahoo! News
>> Get it all here
>>
>> Breaking news to
>>
>> entertainment news
>>
>> Group Charity
>>
>
>
>

Re: [korgpolyex] Velocity sensitive

2009-01-09 by Atom Smasher

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

Re: [korgpolyex] Velocity sensitive

2009-01-09 by Michael Hawkins

the overall volume control is too slow to respond fast enough for a decent reaction to velocity

the existing EG math/code per DCO does not in any way take into account total volume

that means it is just too complex and too difficult to do

and then the CPU cycles would make it impossible to do anyway

sorry ppl but velocity to volume is not going to happen

not on my watch anyway

Mike.

Show quoted textHide quoted text
From: Atom Smasher
To: korgpolyex@yahoogroups.com
Sent: Friday, January 9, 2009 5:21:49 PM
Subject: Re: [korgpolyex] Velocity sensitive

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/impossibl e 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


Re: [korgpolyex] Velocity sensitive

2009-01-09 by Atom Smasher

On Fri, 9 Jan 2009, Michael Hawkins wrote:

> Group 1 - technically simple and not CPU intensive
> Vel > filter cutoff
> Vel > resonance
> Vel > FM-800
> Vel > EG3 depth
=====================

EG3 depth is on the simple list? can EG1/2 depth also be on this list, and 
used together to implement velocity->volume?


> Vel > VCF MG depth
> Vel > DCO MG depth
> Vel > harmonics mapping
> Vel > oscillator detune - *** I doubt I would ever use this  - vote to remove from list
==============

i dunno.... i think i can see vel->detune being useful... but if i can 
control detune from a midi knob-box then i guess velocity control isn't 
needed.


>
> Group2  - technically complex and CPU intensive
> Vel > EG1/2 attack
> Vel > EG1/2 decay
>
> Vel > EG1/2 release
> Vel > LFO speed - *** I doubt I would ever use this - vote to remove from list
> Vel > LFO waveform change - *** I doubt I would ever use this - vote to remove from list
>
> Vel > oscillator interval - *** I doubt I would ever use this - vote to remove from list
==================

i'll agree with you about scrapping the last three.


> I am working on other features at the moment so there is no rush to get 
> this all agreed upon in a day or two but I would like to see everyone 
> put their two cents in and work on this list.
>
> Another thing that is out floating right now is getting EG4 created and 
> working. I am beginning to think that there simply won't be enough CPU 
> cycles to do it at all. One way to get CPU cycles back would be to 
> change the EG's into ADSR instead of the ADBSSR Korg type. Who would be 
> disappointed if we just made them into ADSR?
==================

for now, i'll sit out any ADBSSR/ADSR debates.

mike: next time you appraoch a project like this, do you think you'd 
remove the CPU and put a new one on the expansion board?


-- 
         ...atom

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

 	"The livestock sector emerges as one of the top two or
 	 three most significant contributors to the most serious
 	 environmental problems, at every scale from local to
 	 global. The findings of this report suggest that it
 	 should be a major policy focus when dealing with
 	 problems of land degradation, climate change and air
 	 pollution, water shortage and water pollution and loss
 	 of biodiversity."
 		-- Livestock's long shadow, 2006
 		UN report sponsored by WTO, EU, AS-AID, FAO, et al

Re: [korgpolyex] Velocity sensitive

2009-01-09 by Michael Hawkins

Notice how EG3 has a depth parameter which means that it is written into the code already. And that is because it is ONE EG to handle.

Trying to expand that function to all eight operating DCO's would be 8 times as much code and 8 times as much CPU cycles.

Yes, in retrospect, I should have done the same thing that the team that designed the Europa upgrade for the Jupiter-6 did. They removed the CPU and replaced it.

In the case of the Poly-800, I should have removed the CPU and dropped in one of those nice little ARM LINUX mini computers like the TS7200.

http://www.embeddedarm.com/products/arm-sbc.php#ts-7200-series

I would have written all of the code in C++ (my "native" language) and would never have to worry about CPU cycles ever again.

Oh well.

Mike.


Show quoted textHide quoted text
From: Atom Smasher
To: korgpolyex@yahoogroups.com
Sent: Friday, January 9, 2009 5:36:46 PM
Subject: Re: [korgpolyex] Velocity sensitive

On Fri, 9 Jan 2009, Michael Hawkins wrote:

> Group 1 - technically simple and not CPU intensive
> Vel > filter cutoff
> Vel > resonance
> Vel > FM-800
> Vel > EG3 depth
============ =========

EG3 depth is on the simple list? can EG1/2 depth also be on this list, and
used together to implement velocity->volume?

> Vel > VCF MG depth
> Vel > DCO MG depth
> Vel > harmonics mapping
> Vel > oscillator detune - *** I doubt I would ever use this - vote to remove from list
============ ==

i dunno.... i think i can see vel->detune being useful... but if i can
control detune from a midi knob-box then i guess velocity control isn't
needed.

>
> Group2 - technically complex and CPU intensive
> Vel > EG1/2 attack
> Vel > EG1/2 decay
>
> Vel > EG1/2 release
> Vel > LFO speed - *** I doubt I would ever use this - vote to remove from list
> Vel > LFO waveform change - *** I doubt I would ever use this - vote to remove from list
>
> Vel > oscillator interval - *** I doubt I would ever use this - vote to remove from list
============ ======

i'll agree with you about scrapping the last three.

> I am working on other features at the moment so there is no rush to get
> this all agreed upon in a day or two but I would like to see everyone
> put their two cents in and work on this list.
>
> Another thing that is out floating right now is getting EG4 created and
> working. I am beginning to think that there simply won't be enough CPU
> cycles to do it at all. One way to get CPU cycles back would be to
> change the EG's into ADSR instead of the ADBSSR Korg type. Who would be
> disappointed if we just made them into ADSR?
============ ======

for now, i'll sit out any ADBSSR/ADSR debates.

mike: next time you appraoch a project like this, do you think you'd
remove the CPU and put a new one on the expansion board?

--
...atom

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

"The livestock sector emerges as one of the top two or
three most significant contributors to the most serious
environmental problems, at every scale from local to
global. The findings of this report suggest that it
should be a major policy focus when dealing with
problems of land degradation, climate change and air
pollution, water shortage and water pollution and loss
of biodiversity. "
-- Livestock's long shadow, 2006
UN report sponsored by WTO, EU, AS-AID, FAO, et al


midi control

2009-01-09 by Atom Smasher

going over the MIDI implementation chart, it looks like all patch 
parameters are available for real time control via NRPNs.

cool, i've got a pc1600x so i can work with that. for the benefit of 
everyone else, should assign a priority of things we'd like to have under 
CC control?

  CC 80-83 seem like good candidates for controlling LFO speeds...
  CC 91-94 seem like good candidates for controlling LFO depths...
  etc...

i think the focus here shouldn't be around making it completely editable 
using CCs, but making it controllable in a performance environment using 
CCs. so things like LFOs, filters, FM... things that would be good for 
tweaking in front of 50000 screaming fans... those are things i would like 
to see under CC control, without the need for NRPNs. that would make them 
accessible, and tweakable, from just about anything that can send CCs.

so, the first question is: can the CPU handle this type of thing? i'd 
think it would be a lighter load than NRPNs.

the next questions are: is this something we want? is this something mike 
can do?


-- 
         ...atom

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

 	"The road to the future leads us smack into the wall. We
 	 simply ricochet off the alternatives that destiny
 	 offers: a demographic explosion that triggers social
 	 chaos and spreads death, nuclear delirium and the
 	 quasi-annihilation of the species... Our survival is no
 	 more than a question of 25, 50 or perhaps 100 years."
 		-- Jacques Cousteau, 1910-1997

Re: [korgpolyex] Velocity sensitive

2009-01-09 by Atom Smasher

On Fri, 9 Jan 2009, Michael Hawkins wrote:

> the overall volume control is too slow to respond fast enough for a 
> decent reaction to velocity
===========

that might be better than nothing.



-- 
         ...atom

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

 	"The seafood industry is literally plundering the ocean
 	 of life and some fifty percent of fish caught from the
 	 oceans is fed to cows, pigs, sheep, chickens etc in the
 	 form of fish meal. It also takes about fifty fish
 	 caught from the sea to raise one farm raised salmon."
 		-- Capt Paul Watson, A Very Inconvenient Truth

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Gordon JC Pearce MM3YEQ

On Fri, 2009-01-09 at 17:59 -0600, Alec Jahn wrote:
> OVERCLOCK THAT SOB!

You know, it's something we thought about for the Sequential Sixtrak...

It uses a Z80A CPU, and uses a periodic interrupt for a lot of its
timing.  Looking at it, I began to wonder if replacing the Z80A with a
Z80B and clocking at 6MHz might work...

Gordon

Re: midi control

2009-01-10 by zoinky420

--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
>> the next questions are: is this something we want? is this something 
mike 
> can do?
> 
> 

Like you, I've got a pc-1600x, so NRPNs are fine by me, but I can see 
how it might be flexible to have important stuff, (at least filter cut 
off, freq, resonance) accessible by CC.  But I think that could be 
reserved as a 'final touch'.  The various velocity routings you were 
talking about sound a lot more important.

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Alexandre Souza

> OVERCLOCK THAT SOB!

    Or put a faster processor. There are faster 8085s around, the 800'one is 
running at 6MHz, it can be run at 8 MHz and there are faster (but harder to 
find) versions. What about a Z80 in its place?

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Alec Jahn

I m only a novice at architecture (programmed gameboys in my day.... last year).  More cycles per second is great, but would that even solve the problem?  I

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Gordon JC Pearce MM3YEQ

On Sat, 2009-01-10 at 04:03 -0600, Alec Jahn wrote:

> Then I ask, (again, noobness showing), what controls the clock in our
> 800s?  Something as simple as the FSB on a normal PC?

It's just a crystal.  There's nothing as complicated as the FSB in a PC
motherboard.  Put a higher frequency crystal in, and the CPU goes
faster.  Put a lower frequency crystal in, and it goes slower.

The problem comes about when you have timers controlled from the same
crystal, because they will clock correspondingly faster.  In the
Poly-800 the actual oscillators are generated by a set of programmable
dividers, so if you clocked these faster the pitch would be raised.  If
a timer was generating a periodic interrupt, these would happen faster,
so things like envelope updates would happen faster.  You could get
round this by programming the divider for a lower output rate.

> Also, could you just swap out the chip itself for a better one - a
> simple "upgrade"?  I wouldn't think it'd be that easy, yet I'm
> unfamiliar with these 'vintage' architectures in comparison to stuff
> from the last decade.

Well, if you look at any computer-controlled synth, there's generally
not a lot to it (let's leave the really serious digital behemoths out of
it for now).  In the Poly-800 you only need to program the dividers to
generate squarewaves, set a couple of analogue switches for the
square/saw outputs and chorus, and drive a DAC for the VCF controls.  It
wouldn't be hard to come up with a replacement CPU that would drop in to
replace the 8085, and feed the appropriate control signals to the
peripherals.  Well, I say "it wouldn't be hard", that's obviously
relative...

Gordon

Re: [korgpolyex] midi control

2009-01-10 by Michael Hawkins

yes, this sort of thing is totally doable

although I am wondering why NRPN's are not enough. Every parameter is controllable via NRPN's and most hardware and software MIDI controllers support them.

Show quoted textHide quoted text
From: Atom Smasher
To: korgpolyex@yahoogroups.com
Sent: Friday, January 9, 2009 6:13:04 PM
Subject: [korgpolyex] midi control

going over the MIDI implementation chart, it looks like all patch
parameters are available for real time control via NRPNs.

cool, i've got a pc1600x so i can work with that. for the benefit of
everyone else, should assign a priority of things we'd like to have under
CC control?

CC 80-83 seem like good candidates for controlling LFO speeds...
CC 91-94 seem like good candidates for controlling LFO depths...
etc...

i think the focus here shouldn't be around making it completely editable
using CCs, but making it controllable in a performance environment using
CCs. so things like LFOs, filters, FM... things that would be good for
tweaking in front of 50000 screaming fans... those are things i would like
to see under CC control, without the need for NRPNs. that would make them
accessible, and tweakable, from just about anything that can send CCs.

so, the first question is: can the CPU handle this type of thing? i'd
think it would be a lighter load than NRPNs.

the next questions are: is this something we want? is this something mike
can do?

--
...atom

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

"The road to the future leads us smack into the wall. We
simply ricochet off the alternatives that destiny
offers: a demographic explosion that triggers social
chaos and spreads death, nuclear delirium and the
quasi-annihilation of the species... Our survival is no
more than a question of 25, 50 or perhaps 100 years."
-- Jacques Cousteau, 1910-1997


Re: [korgpolyex] Velocity sensitive

2009-01-10 by Michael Hawkins

As far as I knew, the OKI 80C85 as used in the Poly is the fastest 8085 available.

Can you point me at a link for the faster version?

Show quoted textHide quoted text
From: Alexandre Souza
To: korgpolyex@yahoogroups.com
Sent: Saturday, January 10, 2009 4:42:26 AM
Subject: Re: [korgpolyex] Velocity sensitive

> OVERCLOCK THAT SOB!

Or put a faster processor. There are faster 8085s around, the 800'one is
running at 6MHz, it can be run at 8 MHz and there are faster (but harder to
find) versions. What about a Z80 in its place?


Re: [korgpolyex] Velocity sensitive

2009-01-10 by Michael Hawkins

the problem with the slow CPU is that the onset of notes tends to slow down as you add more features.

A good example is the four LFO's where once there was only one.

The original Poly only had to initialize one LFO. Now it has to initialize four.

The initialization of the LFO's (when they're not free running) has to occur at note down onset.

The code is small but when you multiply it by four from its original, it is going to have an impact.

Then, on top of that, there are numerous new features implemented in the Poly that also require initialization at onset of notes.

FM-800 EG follow and MG, Resonance follow and MG, to name just a few.

I've spent a great deal of time optimising the code for speed and size.

Then on top of that, the envelopes are software driven too. There is a large amount of mathematics used to create those ADBSSRR envelopes.

All of the math has to be able to be executed within a specific amount of time so that the interrupt service routine clock keeps accurate time. Otherwise, the envelopes would stretch or shrink according to the complexity of the programmed envelope.

I DON'T like the idea of using a heatsink on our Poly's because that implies that your batteries will go flat in no time at all.

One of the best features of the Poly is that you can walk the stage with it.

Whatever we do from this point forward must be able to be done without any additional hardware modification.

Mike




________________________________
Show quoted textHide quoted text
From: Alec Jahn <ocedtotehmax@...>
To: korgpolyex@yahoogroups.com
Sent: Saturday, January 10, 2009 5:03:47 AM
Subject: Re: [korgpolyex] Velocity sensitive


I'm only a novice at architecture (programmed gameboys in my day.... last year).  More cycles per second is great, but would that even solve the problem?  I can understand the simplicity of getting more done in the same ammount of time...  Is there anything in the circuit that relies on that particular/steady clockspeed (interrupts were mentioned) (I'm thinking of old games and the audio processor on (again...) the gameboy, a "four voice" analog synth basically - when the clockspeed was increased, IE playing a game on a Super Gameboy or some newer-than-the- old-grey- brick-models, the game would technically run slightly faster and the audio would be that "percent" higher in pitch... amongst some other minor glitches... this was just a ~2% increase or so, not 33% or higher as our possible suggestion/max) .  Could this be done through the HAWK mods, or would it have to be a separate addition?
Then I ask, (again, noobness showing), what controls the clock in our 800s?  Something as simple as the FSB on a normal PC?
 
Also, could you just swap out the chip itself for a better one - a simple "upgrade"?  I wouldn't think it'd be that easy, yet I'm unfamiliar with these 'vintage' architectures in comparison to stuff from the last decade.
 
I do like the thought of having a little heatsink in my synth if needed.  I think I'll fashion one anyway, a nice bright copper one.
 


 
On Sat, Jan 10, 2009 at 3:42 AM, Alexandre Souza <alexandre-listas@ e-secure. com.br> wrote:

> OVERCLOCK THAT SOB!

Or put a faster processor. There are faster 8085s around, the 800'one is 
running at 6MHz, it can be run at 8 MHz and there are faster (but harder to 
find) versions. What about a Z80 in its place?

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Alexandre Souza

> As far as I knew, the OKI 80C85 as used in the Poly is the fastest 8085 
> available.
> Can you point me at a link for the faster version?

    http://www.scribd.com/doc/6997402/Intel-8085-Microprocessor-Architecture

    Here it says about a Tundra second-sourced 8085 at 8MHz, the fastest 
avaiable.

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Alexandre Souza

> I DON'T like the idea of using a heatsink on our Poly's because that 
> implies that your batteries will go flat in no time at all.
> One of the best features of the Poly is that you can walk the stage with 
> it.
> Whatever we do from this point forward must be able to be done without any 
> additional hardware modification.

    Mike, if I were using a Poly around the stage, surely I'd use a Li-Pol 
battery or a gel cell. No way I'd use D size cells on that.

    And, if I have to have a MIDI cable tethered to my keyboard, I'd modify 
it to get 9VAC thru the midi cable. I did it already on one here in Brazil.

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Alex Drinkwater


On 10 Jan 2009, at 15:09, Michael Hawkins wrote:

Then on top of that, the envelopes are software driven too. There is a large amount of mathematics used to create those ADBSSRR envelopes.

Would it be worth implementing a switchable ADSR-only envelope system, if that would save cycles, and therefore speed up response-time?

a|x

Re: [korgpolyex] Velocity sensitive

2009-01-10 by Michael Hawkins

Well, at the moment, I still don't completely understand the EG's math. But I think what you're saying would be true.

Then the problem becomes how to fit it all into the remaining space in the three flash EEPROM's.

And I also don't feel like maintaining different versions of firmware, which I think would be necessary.

Give me a few more months and I'll see where we're at on this one.

Mike.


Show quoted textHide quoted text
From: Alex Drinkwater
To: korgpolyex@yahoogroups.com
Sent: Saturday, January 10, 2009 5:36:54 PM
Subject: Re: [korgpolyex] Velocity sensitive


On 10 Jan 2009, at 15:09, Michael Hawkins wrote:

Then on top of that, the envelopes are software driven too. There is a large amount of mathematics used to create those ADBSSRR envelopes.

Would it be worth implementing a switchable ADSR-only envelope system, if that would save cycles, and therefore speed up response-time?

a|x

Re: [korgpolyex] Velocity sensitive

2009-01-11 by David Mochen

hi there,
The suggested items were just as many as i could imagine. of course the adbssr thingie is not that relevant or useful... would have been great to modulate the DEPTH of the EGs.
As regards Vel > detune, I do think it has potential. Imagine a patch that increasingly changes cutoff, reso and fm800 according to vel... add to that detune... you could get a crazy sound at 127 with detune al the way up to 3 (noticed how the beating accelerates as you go up?). Being it one of the "easy mods", I vote for it to stay :).
Thanks a lot
dave
Show quoted textHide quoted text
----- Original Message -----
Sent: Friday, January 09, 2009 7:36 PM
Subject: Re: [korgpolyex] Velocity sensitive

On Fri, 9 Jan 2009, Michael Hawkins wrote:

> Group 1 - technically simple and not CPU intensive
> Vel > filter cutoff
> Vel > resonance
> Vel > FM-800
> Vel > EG3 depth
=====================

EG3 depth is on the simple list? can EG1/2 depth also be on this list, and
used together to implement velocity->volume?

> Vel > VCF MG depth
> Vel > DCO MG depth
> Vel > harmonics mapping
> Vel > oscillator detune - *** I doubt I would ever use this - vote to remove from list
==============

i dunno.... i think i can see vel->detune being useful... but if i can
control detune from a midi knob-box then i guess velocity control isn't
needed.

>
> Group2 - technically complex and CPU intensive
> Vel > EG1/2 attack
> Vel > EG1/2 decay
>
> Vel > EG1/2 release
> Vel > LFO speed - *** I doubt I would ever use this - vote to remove from list
> Vel > LFO waveform change - *** I doubt I would ever use this - vote to remove from list
>
> Vel > oscillator interval - *** I doubt I would ever use this - vote to remove from list
==================

i'll agree with you about scrapping the last three.

> I am working on other features at the moment so there is no rush to get
> this all agreed upon in a day or two but I would like to see everyone
> put their two cents in and work on this list.
>
> Another thing that is out floating right now is getting EG4 created and
> working. I am beginning to think that there simply won't be enough CPU
> cycles to do it at all. One way to get CPU cycles back would be to
> change the EG's into ADSR instead of the ADBSSR Korg type. Who would be
> disappointed if we just made them into ADSR?
==================

for now, i'll sit out any ADBSSR/ADSR debates.

mike: next time you appraoch a project like this, do you think you'd
remove the CPU and put a new one on the expansion board?

--
...atom

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

"The livestock sector emerges as one of the top two or
three most significant contributors to the most serious
environmental problems, at every scale from local to
global. The findings of this report suggest that it
should be a major policy focus when dealing with
problems of land degradation, climate change and air
pollution, water shortage and water pollution and loss
of biodiversity."
-- Livestock's long shadow, 2006
UN report sponsored by WTO, EU, AS-AID, FAO, et al

Re: Velocity sensitive

2009-01-11 by zoinky420

--- In korgpolyex@yahoogroups.com, "Alexandre Souza" <alexandre-
listas@...> wrote:
>
> > As far as I knew, the OKI 80C85 as used in the Poly is the fastest 
8085 
> > available.
> > Can you point me at a link for the faster version?
> 
>     http://www.scribd.com/doc/6997402/Intel-8085-Microprocessor-
Architecture
> 
>     Here it says about a Tundra second-sourced 8085 at 8MHz, the 
fastest 
> avaiable.
>

yeah but unless it's CMOS (that's what the C in 80C85 means), it's 
going to be a power-hog in comparison.  All 80C85 is the 'battery 
power' version of 8085.

Re: Velocity sensitive

2009-01-11 by zoinky420

--- In korgpolyex@yahoogroups.com, "Alexandre Souza" <alexandre-
listas@...> wrote:
>
> > I DON'T like the idea of using a heatsink on our Poly's because 
that 
> > implies that your batteries will go flat in no time at all.
> > One of the best features of the Poly is that you can walk the 
stage with 
> > it.
> > Whatever we do from this point forward must be able to be done 
without any 
> > additional hardware modification.
> 
>     Mike, if I were using a Poly around the stage, surely I'd use a 
Li-Pol 
> battery or a gel cell. No way I'd use D size cells on that.
> 

I'd use rechargable double-A's in D sheaths.


>     And, if I have to have a MIDI cable tethered to my keyboard, 
I'd modify 
> it to get 9VAC thru the midi cable. I did it already on one here in 
Brazil.

Interesting but potentially dangerous if somebody else grabs that 
midi feed not knowing there's power on it.  You could also provide it 
from the audio cable on TRS I suppose, since you may not always need 
a MIDI cable plugged in, but you will always need the audio out 
cable...

Re: [korgpolyex] Re: Velocity sensitive

2009-01-11 by Alexandre Souza

> Interesting but potentially dangerous if somebody else grabs that
> midi feed not knowing there's power on it.  You could also provide it
> from the audio cable on TRS I suppose, since you may not always need
> a MIDI cable plugged in, but you will always need the audio out
> cable...

    There are two pins which are not used in the MIDI specification. You can 
feed 9VDC there and supply the Poly.

Re: Velocity sensitive

2009-01-12 by zoinky420

--- In korgpolyex@yahoogroups.com, "Alexandre Souza" <alexandre-
listas@...> wrote:
>
> > Interesting but potentially dangerous if somebody else grabs that
> > midi feed not knowing there's power on it.  You could also provide 
it
> > from the audio cable on TRS I suppose, since you may not always need
> > a MIDI cable plugged in, but you will always need the audio out
> > cable...
> 
>     There are two pins which are not used in the MIDI specification. 
You can 
> feed 9VDC there and supply the Poly.
>

yeah, that means you have to build your own cable because those wires 
don't exist in regular MIDI cables.  So you've got a 9vdc adaptor 
running into a hacked-together MIDI cable - what a mess.  Why not just 
plug the adaptor into the socket the Poly 800 already has??

Re: [korgpolyex] Re: Velocity sensitive

2009-01-12 by Alexandre Souza

> yeah, that means you have to build your own cable because those wires
> don't exist in regular MIDI cables.  So you've got a 9vdc adaptor
> running into a hacked-together MIDI cable - what a mess.  Why not just
> plug the adaptor into the socket the Poly 800 already has??

    One more plug, one more adapter, more sources of problems. Do it 
whatever you like, I did this way and the guy keeps using it with no 
troubles until today :o)

Re: Velocity sensitive

2009-01-12 by zoinky420

--- In korgpolyex@yahoogroups.com, "Alexandre Souza" <alexandre-
listas@...> wrote:
>
> > yeah, that means you have to build your own cable because those 
wires
> > don't exist in regular MIDI cables.  So you've got a 9vdc adaptor
> > running into a hacked-together MIDI cable - what a mess.  Why not 
just
> > plug the adaptor into the socket the Poly 800 already has??
> 
>     One more plug, one more adapter, more sources of problems. 

Well the source of power will exist regardless of how it gets to the 
Poly800.  You could acheive the same physical versatility of a single 
cord going to the Poly800 by simply taping or using wire-ties to run 
the power line against and parallel to the MIDI cable.  

>Do it 
> whatever you like, I did this way and the guy keeps using it with no 
> troubles until today :o)

I'm sure it works I just think it's over-engineered.  But there are no 
potential technical problems with it, contrary to what I stated 
previously.

Datasheet?

2009-01-12 by Marcus Wilson

G'day Mike

I have been going through some archives, is this the datasheet you  
were chasing??

Marcus Wilson

Re: [korgpolyex] Datasheet?

2009-01-13 by Michael Hawkins

Marcus,

For a brief moment I thought you had found the datasheet for the MSM5232.

My hopes have been dashed once again. :-(

Mike.

Show quoted textHide quoted text
From: Marcus Wilson
To: korgpolyex@yahoogroups.com
Sent: Monday, January 12, 2009 4:52:50 PM
Subject: [korgpolyex] Datasheet?

G'day Mike

I have been going through some archives, is this the datasheet you
were chasing??

Marcus Wilson


Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.