Korg Poly800/EX800 Users

Well, now that I've successfully implemented dual LFO modulation of
the DCO, VCF, resonance and FM-800, I have a question for all Poly fans.

How many of you would be bothered if I was to slow the LFO's down a
little bit? I personally never use the LFO at it highest speed
settings. In fact, it's rather difficult to tell the difference
between say about 12 - 15 settings because the rate is so high.

If I slowed the LFO down then I would be able to set up the second
modulators to use LFO1 or LFO2 instead of just SLFO3 and SLFO4.

Any comments or suggestions will be much appreciated.

Mike.

It seems lika a good idea to me.

/ Lasse T.

----- Original Message ----- 

From: "korgpolyex800" <korgpolyex800@...>
To: <korgpolyex@yahoogroups.com>
Sent: Tuesday, September 16, 2008 1:48 PM
Subject: [korgpolyex] A question for all Poly fans - slowing down the LFO's?


> Well, now that I've successfully implemented dual LFO modulation of
> the DCO, VCF, resonance and FM-800, I have a question for all Poly fans.
>
> How many of you would be bothered if I was to slow the LFO's down a
> little bit? I personally never use the LFO at it highest speed
> settings. In fact, it's rather difficult to tell the difference
> between say about 12 - 15 settings because the rate is so high.
>
> If I slowed the LFO down then I would be able to set up the second
> modulators to use LFO1 or LFO2 instead of just SLFO3 and SLFO4.
>
> Any comments or suggestions will be much appreciated.
>
> Mike.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

----- Original Message -----

From: korgpolyex800

To: korgpolyex@yahoogroups.com

Sent: Tuesday, September 16, 2008 8:48 AM

Subject: [korgpolyex] A question for all Poly fans - slowing down the LFO's?

Well, now that I've successfully implemented dual LFO modulation of
the DCO, VCF, resonance and FM-800, I have a question for all Poly fans.

How many of you would be bothered if I was to slow the LFO's down a
little bit? I personally never use the LFO at it highest speed
settings. In fact, it's rather difficult to tell the difference
between say about 12 - 15 settings because the rate is so high.

If I slowed the LFO down then I would be able to set up the second
modulators to use LFO1 or LFO2 instead of just SLFO3 and SLFO4.

Any comments or suggestions will be much appreciated.

Mike.

On Tue, 16 Sep 2008, korgpolyex800 wrote:

> How many of you would be bothered if I was to slow the LFO's down a 
> little bit? I personally never use the LFO at it highest speed settings. 
> In fact, it's rather difficult to tell the difference between say about 
> 12 - 15 settings because the rate is so high.
>
> If I slowed the LFO down then I would be able to set up the second 
> modulators to use LFO1 or LFO2 instead of just SLFO3 and SLFO4.
>
> Any comments or suggestions will be much appreciated.
====================

1) can you just change the rate of speed increase? ie; make it more of a 
log curve, so that the new 15 == the old 15, but maybe the new 12 == the 
old 11.

2) can an extra parameter be added for the range? low/high/ohmygod?

3) can the LFO speed (among other parameters) be made to respond to 6-7 
bits of incoming controller data, even if it only saves 4 bits to memory? 
i think this option would be the best (for most parameters that seem 
limited to 4 bit), because it would allow a very fluid (non zipper) 
control via midi, but still conserve memory usage.



-- 
         ...atom

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

 	"A people that values its privileges above its principles
 	 soon loses both."
 		-- Dwight D. Eisenhower

i use the faster setting on the LFO all the  time.  Iike to modulate the  VCF very fast with a slow release, sounds kinda Tangerine Dream.

Great questions Atom,

1) no, the problem is that the LFO's and EG's and the display are
clocked by interrupt 6.5 on the 8085 CPU. This clock runs at about
2400 - 3600 Hz. This means that the CPU is interrupted to run the EG
and MG code up to 3600 times per second. Obviously then, there is only
a finite amount of time for that routine to complete. As I've added
more and more features to the HAWK-800, so to the code has become
longer and it takes more time for the CPU to execute. Now I've hit up
against a wall where the code is now beginning to take more time to
execute than there is time available. This causes the EG's to slow
down (and we already know the Poly-800 wasn't that fast on the EG side
to begin with). So the only way to improve the situation is to slow
something down. I am now doing this by executing different functions
each time the interrupt service routine is called.

2) no, see above.

3) yes, this is possible but I don't propose to do this in the near
term because it would require a second rewrite of the rewrite of the
LFO's and there are other things I'd like to move on to such as the
arpeggiator. Also, I find that the new waveforms and modulations that
you get from four (4) LFO's makes them really quite flexible and the
MIDI control is quite versatile too. But I do like the idea of
increasing the resolution.

Mike.

--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> On Tue, 16 Sep 2008, korgpolyex800 wrote:
> 
> > How many of you would be bothered if I was to slow the LFO's down a 
> > little bit? I personally never use the LFO at it highest speed
settings. 
> > In fact, it's rather difficult to tell the difference between say
about 
> > 12 - 15 settings because the rate is so high.
> >
> > If I slowed the LFO down then I would be able to set up the second 
> > modulators to use LFO1 or LFO2 instead of just SLFO3 and SLFO4.
> >
> > Any comments or suggestions will be much appreciated.
> ====================
> 
> 1) can you just change the rate of speed increase? ie; make it more
of a 
> log curve, so that the new 15 == the old 15, but maybe the new 12 ==
the 
> old 11.
> 
> 2) can an extra parameter be added for the range? low/high/ohmygod?
> 
> 3) can the LFO speed (among other parameters) be made to respond to 6-7 
> bits of incoming controller data, even if it only saves 4 bits to
memory? 

> i think this option would be the best (for most parameters that seem 
> limited to 4 bit), because it would allow a very fluid (non zipper) 
> control via midi, but still conserve memory usage.
> 
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"A people that values its privileges above its principles
>  	 soon loses both."
>  		-- Dwight D. Eisenhower
>

OK, so let me clarify the question slightly.

What if the maximum speed was what 14 is right now? Is that fast
enough to keep everyone happy? In other words, 15 would become 14, 14
would become 13 and so on all the way down to 1 and 1 becomes twice as
slow as it is now. Is that OK by everyone?

I sure hope so, otherwise my modulators can go no further.

Mike.

--- In korgpolyex@yahoogroups.com, Russ <russdaren@...> wrote:
>
> i use the faster setting on the LFO all the  time.  Iike to modulate
the  VCF very fast with a slow release, sounds kinda Tangerine Dream.
>

On Mittwoch 17 September 2008, korgpolyex800 wrote:
[...]
> I sure hope so, otherwise my modulators can go no further.

Would it be possible to do this only when the extended LFO are in use?  
In other words, any original patch stays like it was and only if you 
start using the extended features you have to adapt the speeds?


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

cool... is #3 officially on the wish list?

perhaps another way to address #1,2 would be to use different lookup 
tables (you are using lookup tables?) for different speeds. as an LFO 
speed increases, the human ear just has a harder time making out what 
waveform it is... so beyond a certain range, maybe there can be an 
"ohmygod" range where the waveforms aren't really distinguishable as 
"saw", "sine", etc and you can maybe use a distorted waveform that's 
optmized for high speed. the only exception would be random.

might that be a way to get crazy-fast LFOs out of the old CPU?

also, what is the maximum safe frequency to run the CPU (without adding 
coolers)? is that what it's running at?

thanks...


On Wed, 17 Sep 2008, korgpolyex800 wrote:

> 3) yes, this is possible but I don't propose to do this in the near term 
> because it would require a second rewrite of the rewrite of the LFO's 
> and there are other things I'd like to move on to such as the 
> arpeggiator. Also, I find that the new waveforms and modulations that 
> you get from four (4) LFO's makes them really quite flexible and the 
> MIDI control is quite versatile too. But I do like the idea of 
> increasing the resolution.

> --- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>>
>> 3) can the LFO speed (among other parameters) be made to respond to 6-7 
>> bits of incoming controller data, even if it only saves 4 bits to 
>> memory? i think this option would be the best (for most parameters that 
>> seem limited to 4 bit), because it would allow a very fluid (non 
>> zipper) control via midi, but still conserve memory usage.




-- 
         ...atom

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

 	"You ask me why the IWW is not patriotic to the United States.
 	 If you were a bum without a blanket; if you had left your
 	 wife and kids when you went west for a job, and had never
 	 located them since; if your job had never kept you long
 	 enough in a place to qualify to vote; if you slept in a
 	 lousy, sour bunkhouse, and ate food just as rotten as they
 	 could give you and get by with it; if deputy sheriffs shot
 	 your cooking cans full of holes and spilled your grub on the
 	 ground; if your wages were lowered on you when the bosses
 	 thought they had you down...if every person who represented
 	 law and order and the nation beat you up, railroaded you to
 	 jail, and the good Christian people cheered and told them to
 	 go to it, how in hell do you expect a man to be patriotic?
 	 This war is a businessman's war and we don't see why we
 	 should go out and get shot in order to save the lovely state
 	 of affairs that we now enjoy."
 		-- William 'Big Bill' Haywood

Nice idea and that's why it's already implemented wherever I can do so.

But it cannot be applied to modulators that rely on the first two
LFO's. Thus, we're out of luck with that.

Mike.

--- In korgpolyex@yahoogroups.com, ASSI <Stromeko@...> wrote:

>
> On Mittwoch 17 September 2008, korgpolyex800 wrote:
> [...]
> > I sure hope so, otherwise my modulators can go no further.
> 
> Would it be possible to do this only when the extended LFO are in use?  
> In other words, any original patch stays like it was and only if you 
> start using the extended features you have to adapt the speeds?
> 
> 
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+
> 
> Wavetables for the Terratec KOMPLEXER:
> http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
>

I knew someone would eventually suggest over clocking the CPU.

The only problem with that is that those old CPU's had a maximum clock
rate that really was the maximum clock rate. And that is the principle
that applies to the old 80C85.

Look up tables are used for the sine wave. But I found that the fast
code for triangle, saw, random and PWM was to use real code.

So we're out of luck with that too.

I'll do a little test tonight and see how it goes with the LFO only
slowed down by half.

Mike


--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> cool... is #3 officially on the wish list?
> 
> perhaps another way to address #1,2 would be to use different lookup 
> tables (you are using lookup tables?) for different speeds. as an LFO 
> speed increases, the human ear just has a harder time making out what 
> waveform it is... so beyond a certain range, maybe there can be an 
> "ohmygod" range where the waveforms aren't really distinguishable as 
> "saw", "sine", etc and you can maybe use a distorted waveform that's 
> optmized for high speed. the only exception would be random.
> 
> might that be a way to get crazy-fast LFOs out of the old CPU?
> 
> also, what is the maximum safe frequency to run the CPU (without adding 
> coolers)? is that what it's running at?
> 
> thanks...
> 
> 
> On Wed, 17 Sep 2008, korgpolyex800 wrote:
> 
> > 3) yes, this is possible but I don't propose to do this in the
near term 
> > because it would require a second rewrite of the rewrite of the LFO's 
> > and there are other things I'd like to move on to such as the 
> > arpeggiator. Also, I find that the new waveforms and modulations that 
> > you get from four (4) LFO's makes them really quite flexible and the 
> > MIDI control is quite versatile too. But I do like the idea of 
> > increasing the resolution.
> 
> > --- In korgpolyex@yahoogroups.com, Atom Smasher <atom@> wrote:
> >>
> >> 3) can the LFO speed (among other parameters) be made to respond
to 6-7 
> >> bits of incoming controller data, even if it only saves 4 bits to 
> >> memory? i think this option would be the best (for most
parameters that 

> >> seem limited to 4 bit), because it would allow a very fluid (non 
> >> zipper) control via midi, but still conserve memory usage.
> 
> 
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"You ask me why the IWW is not patriotic to the United States.
>  	 If you were a bum without a blanket; if you had left your
>  	 wife and kids when you went west for a job, and had never
>  	 located them since; if your job had never kept you long
>  	 enough in a place to qualify to vote; if you slept in a
>  	 lousy, sour bunkhouse, and ate food just as rotten as they
>  	 could give you and get by with it; if deputy sheriffs shot
>  	 your cooking cans full of holes and spilled your grub on the
>  	 ground; if your wages were lowered on you when the bosses
>  	 thought they had you down...if every person who represented
>  	 law and order and the nation beat you up, railroaded you to
>  	 jail, and the good Christian people cheered and told them to
>  	 go to it, how in hell do you expect a man to be patriotic?
>  	 This war is a businessman's war and we don't see why we
>  	 should go out and get shot in order to save the lovely state
>  	 of affairs that we now enjoy."
>  		-- William 'Big Bill' Haywood
>

On Wed, 17 Sep 2008, ASSI wrote:

> Would it be possible to do this only when the extended LFO are in use? 
> In other words, any original patch stays like it was and only if you 
> start using the extended features you have to adapt the speeds?
================

this might be overboaord, but maybe a way for the OS to say;
  "hey, the CPU load is 0.85 and the LFO is running at speed 'x'.it's time 
to multiply the LFO speed by 0.8".

this also makes me curious... since the EX800 doesn't have to scan a 
keyboard, are there more CPU cycles available for other tasks? not that 
i'm suggesting a different range of LFO speeds for the poly and the ex... 
yet...


-- 
         ...atom

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

 	"The test of a first-rate intelligence is the ability to hold
 	 two opposed ideas in mind at the same time and still retain
 	 the ability to function. One should, for example, be able to
 	 see that things are hopeless and yet be determined to make
 	 them otherwise."
 		-- F. Scott Fitzgerald

On Wed, 17 Sep 2008, korgpolyex800 wrote:

> I knew someone would eventually suggest over clocking the CPU.
===============

i didn't mean to imply that. i'm not eager to cook anything in my old 
gear.


> The only problem with that is that those old CPU's had a maximum clock 
> rate that really was the maximum clock rate. And that is the principle 
> that applies to the old 80C85.
=================

maximum clock rate is, too a point, a function of temperature. but no, i 
don't want to have a liquid nitrogen cooled EX800.


> Look up tables are used for the sine wave. But I found that the fast 
> code for triangle, saw, random and PWM was to use real code.
==================

i would still think that it would be feasible to use a distorted wave in a 
lookup table and get "ohmygod" fast LFOs, without burdening the CPU... but 
i'll take your word for it if that's not the case.

as a crypto geek, i'm still curious how you're calculating the random 
wave, and what the period is.


-- 
         ...atom

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

 	"Never have the armies of the North brought peace,
 	 prosperity, or democracy to the peoples of Asia,
 	 Africa, or Latin America. In the future, as in the
 	 past five centuries, they can only bring to these
 	 peoples further servitude, the exploitation of their
 	 labor, the expropriation of their riches, and the denial
 	 of their rights. It is of the utmost importance that the
 	 progressive forces of the West understand this."
 		-- Samir Amin,
 		director of Forum du Tiers Monde in Dakar, Senegal

Hi Atom,

the way the LFO works is to count from 0 to 255.

At the slowest rate (0), the LFO increments in steps of 1. That is,
1,2,3,4,5... 255,0,1,2,3,4,5...

When it's running at it's fastest rate it is counting from 0 to 255
increasing steps of addition.

The table looks like this for the increments.

MG_TABLE:	.db 1		; 1
		.db 2		; 2
		.db 3		; 3
		.db 4		; 4
		.db 6		; 6
		.db 8		; 8
		.db 0Bh		; 11
		.db 0Eh		; 14
		.db 11h		; 17
		.db 15h		; 21
		.db 19h		; 25
		.db 1Eh		; 30
		.db 24h		; 36
		.db 2Bh		; 43
		.db 34h		; 52
		.db 3Eh		; 62

Decimal addition is shown on the right.

This means that at the highest LFO speed there are only 4 distinct
points in the triangle wave. So there is no way to tell the CPU to
step up the speed any further. It's going as fast through the waveform
as it possibly can. Atleast not without causing major aliasing of the
waveforms.

You're right about the EX800. When you select the global parameter for
setting the software to run as the EX800, the code stops executing the
keyboard and joystick scanning and handling.

But let's not go there just yet. :-)

Mike



--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> On Wed, 17 Sep 2008, ASSI wrote:
> 
> > Would it be possible to do this only when the extended LFO are in
use? 
> > In other words, any original patch stays like it was and only if you 
> > start using the extended features you have to adapt the speeds?
> ================
> 
> this might be overboaord, but maybe a way for the OS to say;
>   "hey, the CPU load is 0.85 and the LFO is running at speed
'x'.it's time 
> to multiply the LFO speed by 0.8".
> 
> this also makes me curious... since the EX800 doesn't have to scan a 
> keyboard, are there more CPU cycles available for other tasks? not that 
> i'm suggesting a different range of LFO speeds for the poly and the
ex... 

> yet...
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"The test of a first-rate intelligence is the ability to hold
>  	 two opposed ideas in mind at the same time and still retain
>  	 the ability to function. One should, for example, be able to
>  	 see that things are hopeless and yet be determined to make
>  	 them otherwise."
>  		-- F. Scott Fitzgerald
>

Here's my pseudo random number generator.

It is by no means very random.

; my pseudo random number generator - used for the LFO randomiser
; returns a random number in A

RANDOMIZE:	push	h ; save HL
		lxi	h, M_RANDOM ; point at the previous value (seed)
		mov	a, m ; put the seed value into A
		cpi	0 ; check for seed equals zero
		jnz	RANDOMIZEA ; if seed is zero jump to randomizea
		cma ; compliment A
		mov	m, a ; put A back into seed
RANDOMIZEA:	rlc ; rotate left through carry
		adi	43 ; add 43 offset
		mov	m, a ; save in seed
		pop	h ; load HL
		ret ; return with pseudo random in A

I would be more than happy for you to suggest something better as long
as it doesn't add any CPU cycles. :-)

Mike



--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> On Wed, 17 Sep 2008, korgpolyex800 wrote:
> 
> > I knew someone would eventually suggest over clocking the CPU.
> ===============
> 
> i didn't mean to imply that. i'm not eager to cook anything in my old 
> gear.
> 
> 
> > The only problem with that is that those old CPU's had a maximum
clock 
> > rate that really was the maximum clock rate. And that is the
principle 
> > that applies to the old 80C85.
> =================
> 
> maximum clock rate is, too a point, a function of temperature. but
no, i 
> don't want to have a liquid nitrogen cooled EX800.
> 
> 
> > Look up tables are used for the sine wave. But I found that the fast 
> > code for triangle, saw, random and PWM was to use real code.
> ==================
> 
> i would still think that it would be feasible to use a distorted
wave in a 
> lookup table and get "ohmygod" fast LFOs, without burdening the
CPU... but 

> i'll take your word for it if that's not the case.
> 
> as a crypto geek, i'm still curious how you're calculating the random 
> wave, and what the period is.
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"Never have the armies of the North brought peace,
>  	 prosperity, or democracy to the peoples of Asia,
>  	 Africa, or Latin America. In the future, as in the
>  	 past five centuries, they can only bring to these
>  	 peoples further servitude, the exploitation of their
>  	 labor, the expropriation of their riches, and the denial
>  	 of their rights. It is of the utmost importance that the
>  	 progressive forces of the West understand this."
>  		-- Samir Amin,
>  		director of Forum du Tiers Monde in Dakar, Senegal
>

i can deal.  fo sheezy!

jb


--- In korgpolyex@yahoogroups.com, "korgpolyex800" <korgpolyex800@...>
wrote:

>
> OK, so let me clarify the question slightly.
> 
> What if the maximum speed was what 14 is right now? Is that fast
> enough to keep everyone happy? In other words, 15 would become 14, 14
> would become 13 and so on all the way down to 1 and 1 becomes twice as
> slow as it is now. Is that OK by everyone?
> 
> I sure hope so, otherwise my modulators can go no further.
> 
> Mike.
> 
> --- In korgpolyex@yahoogroups.com, Russ <russdaren@> wrote:
> >
> > i use the faster setting on the LFO all the  time.  Iike to modulate
> the  VCF very fast with a slow release, sounds kinda Tangerine Dream.
> >
>

assembler?!?! i should have known.... and i've always considered C a low 
level language...

despite the verbose comments (is all of the code commented that well?) i 
can't follow it. can you give a brief explanation?




On Thu, 18 Sep 2008, korgpolyex800 wrote:

> Here's my pseudo random number generator.
>
> It is by no means very random.
>
> ; my pseudo random number generator - used for the LFO randomiser
> ; returns a random number in A
>
> RANDOMIZE:	push	h ; save HL
> 		lxi	h, M_RANDOM ; point at the previous value (seed)
> 		mov	a, m ; put the seed value into A
> 		cpi	0 ; check for seed equals zero
> 		jnz	RANDOMIZEA ; if seed is zero jump to randomizea
> 		cma ; compliment A
> 		mov	m, a ; put A back into seed
> RANDOMIZEA:	rlc ; rotate left through carry
> 		adi	43 ; add 43 offset
> 		mov	m, a ; save in seed
> 		pop	h ; load HL
> 		ret ; return with pseudo random in A
>
> I would be more than happy for you to suggest something better as long
> as it doesn't add any CPU cycles. :-)


-- 
         ...atom

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

 	"It has become appallingly obvious that our
 	 technology has exceeded our humanity."
 		-- Albert Einstein

On Samstag 20 September 2008, Atom Smasher wrote:
> assembler?!?! i should have known.... and i've always considered C
> a low level language...

In C:

((m ? m : -m) << 1) + 43;

Better? :-)

> despite the verbose comments (is all of the code commented that
> well?) i can't follow it. can you give a brief explanation?

It is somwthing that looks like a LFSR, but isn't (the feedback is 
actually missing).  When I find some time I'll simulate to see what 
the cycle length is for different seed values.

> On Thu, 18 Sep 2008, korgpolyex800 wrote:
> > Here's my pseudo random number generator.
> >
> > It is by no means very random.
> >
> > ; my pseudo random number generator - used for the LFO randomiser
> > ; returns a random number in A
> >
> > RANDOMIZE:	push	h ; save HL
> > 		lxi	h, M_RANDOM ; point at the previous value (seed)
> > 		mov	a, m ; put the seed value into A
> > 		cpi	0 ; check for seed equals zero
> > 		jnz	RANDOMIZEA ; if seed is zero jump to randomizea
> > 		cma ; compliment A
> > 		mov	m, a ; put A back into seed

This line is redundant because you save the seed again later on.

> > RANDOMIZEA:	rlc ; rotate left through carry
> > 		adi	43 ; add 43 offset
> > 		mov	m, a ; save in seed
> > 		pop	h ; load HL
> > 		ret ; return with pseudo random in A
> >
> > I would be more than happy for you to suggest something better as
> > long as it doesn't add any CPU cycles. :-)


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Actually, the more time I spend writing this code in assembler, the
more I realize how clever the guys who came up with C were. And I wish
I was doing this all in C.

The pseudo number generator is known as a Linear Congruential Random
Number Generator. You can all about it
http://www.daylight.com/meetings/emug98/Sayle/sample.html.

Since we're working in 8 bits, it's periodicity is short. And it could
be made to be much better than it is. I just got a result that sounded
OK and stayed with that. But I am sure that I will go back and revisit
this little code snippet and work on it some time.

Meanwhile, the equation looks like this.

Xn+1 = (aXn+c) mod m

And yes, all of the code that I have written is commented like that
and all of the original Korg code that I understand is commented like
that. Is there a problem with my commenting?

Mike


--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> assembler?!?! i should have known.... and i've always considered C a
low 
> level language...
> 
> despite the verbose comments (is all of the code commented that
well?) i 

> can't follow it. can you give a brief explanation?
> 
> 
> 
> 
> On Thu, 18 Sep 2008, korgpolyex800 wrote:
> 
> > Here's my pseudo random number generator.
> >
> > It is by no means very random.
> >
> > ; my pseudo random number generator - used for the LFO randomiser
> > ; returns a random number in A
> >
> > RANDOMIZE:	push	h ; save HL
> > 		lxi	h, M_RANDOM ; point at the previous value (seed)
> > 		mov	a, m ; put the seed value into A
> > 		cpi	0 ; check for seed equals zero
> > 		jnz	RANDOMIZEA ; if seed is zero jump to randomizea
> > 		cma ; compliment A
> > 		mov	m, a ; put A back into seed
> > RANDOMIZEA:	rlc ; rotate left through carry
> > 		adi	43 ; add 43 offset
> > 		mov	m, a ; save in seed
> > 		pop	h ; load HL
> > 		ret ; return with pseudo random in A
> >
> > I would be more than happy for you to suggest something better as long
> > as it doesn't add any CPU cycles. :-)
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"It has become appallingly obvious that our
>  	 technology has exceeded our humanity."
>  		-- Albert Einstein
>

Wow, now that I look at it in C, it definitely needs improvement. LOL

Mike.

--- In korgpolyex@yahoogroups.com, ASSI <Stromeko@...> wrote:

>
> On Samstag 20 September 2008, Atom Smasher wrote:
> > assembler?!?! i should have known.... and i've always considered C
> > a low level language...
> 
> In C:
> 
> ((m ? m : -m) << 1) + 43;
> 
> Better? :-)
> 
> > despite the verbose comments (is all of the code commented that
> > well?) i can't follow it. can you give a brief explanation?
> 
> It is somwthing that looks like a LFSR, but isn't (the feedback is 
> actually missing).  When I find some time I'll simulate to see what 
> the cycle length is for different seed values.
> 
> > On Thu, 18 Sep 2008, korgpolyex800 wrote:
> > > Here's my pseudo random number generator.
> > >
> > > It is by no means very random.
> > >
> > > ; my pseudo random number generator - used for the LFO randomiser
> > > ; returns a random number in A
> > >
> > > RANDOMIZE:	push	h ; save HL
> > > 		lxi	h, M_RANDOM ; point at the previous value (seed)
> > > 		mov	a, m ; put the seed value into A
> > > 		cpi	0 ; check for seed equals zero
> > > 		jnz	RANDOMIZEA ; if seed is zero jump to randomizea
> > > 		cma ; compliment A
> > > 		mov	m, a ; put A back into seed
> 
> This line is redundant because you save the seed again later on.
> 
> > > RANDOMIZEA:	rlc ; rotate left through carry
> > > 		adi	43 ; add 43 offset
> > > 		mov	m, a ; save in seed
> > > 		pop	h ; load HL
> > > 		ret ; return with pseudo random in A
> > >
> > > I would be more than happy for you to suggest something better as
> > > long as it doesn't add any CPU cycles. :-)
> 
> 
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+
> 
> Factory and User Sound Singles for Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
>

For those interested check out wikipedia
http://en.wikipedia.org/wiki/Linear_congruential_generator

The waveform generation code has to be fast and it has to generate not
just random but triangle, sawtooth, sine, square PWM as well.

So I chose to pick a recurrence relation that was fast and "sounded"
random and it does that "reasonably" well. It is by no means random it
just sounds somewhat random.

Mike.

--- In korgpolyex@yahoogroups.com, ASSI <Stromeko@...> wrote:

>
> On Samstag 20 September 2008, Atom Smasher wrote:
> > assembler?!?! i should have known.... and i've always considered C
> > a low level language...
> 
> In C:
> 
> ((m ? m : -m) << 1) + 43;
> 
> Better? :-)
> 
> > despite the verbose comments (is all of the code commented that
> > well?) i can't follow it. can you give a brief explanation?
> 
> It is somwthing that looks like a LFSR, but isn't (the feedback is 
> actually missing).  When I find some time I'll simulate to see what 
> the cycle length is for different seed values.
> 
> > On Thu, 18 Sep 2008, korgpolyex800 wrote:
> > > Here's my pseudo random number generator.
> > >
> > > It is by no means very random.
> > >
> > > ; my pseudo random number generator - used for the LFO randomiser
> > > ; returns a random number in A
> > >
> > > RANDOMIZE:	push	h ; save HL
> > > 		lxi	h, M_RANDOM ; point at the previous value (seed)
> > > 		mov	a, m ; put the seed value into A
> > > 		cpi	0 ; check for seed equals zero
> > > 		jnz	RANDOMIZEA ; if seed is zero jump to randomizea
> > > 		cma ; compliment A
> > > 		mov	m, a ; put A back into seed
> 
> This line is redundant because you save the seed again later on.
> 
> > > RANDOMIZEA:	rlc ; rotate left through carry
> > > 		adi	43 ; add 43 offset
> > > 		mov	m, a ; save in seed
> > > 		pop	h ; load HL
> > > 		ret ; return with pseudo random in A
> > >
> > > I would be more than happy for you to suggest something better as
> > > long as it doesn't add any CPU cycles. :-)
> 
> 
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+
> 
> Factory and User Sound Singles for Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
>

On Sat, 20 Sep 2008, korgpolyex800 wrote:

> And yes, all of the code that I have written is commented like that and 
> all of the original Korg code that I understand is commented like that. 
> Is there a problem with my commenting?
==================

the original korg code is commented like that??? i thought all you'd get 
from interrogating the EPROM would be machine code, and you'd have to 
decompile it just to get assembly...?


-- 
         ...atom

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

 	"The incidence of disease has increased
 	 in proportion to the progress of science."
 		-- Akbarali Jetha

On Sat, 20 Sep 2008, korgpolyex800 wrote:

> Since we're working in 8 bits, it's periodicity is short. And it could 
> be made to be much better than it is. I just got a result that sounded 
> OK and stayed with that. But I am sure that I will go back and revisit 
> this little code snippet and work on it some time.
============

i won't pretend to understand the algorithm right now...  but i'm 
wondering if it can be seeded with `random` midi or wheel data...? it may 
be a naive suggestion, but if the seed can be the address of, say, the 
most recently recevied midi note/CC message (sync messages should be 
ignored), would that benefit the randomness? and if midi messages are 
being received while the random LFO is running, then it would also 
increase the period?


-- 
         ...atom

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

 	"Every great advance in natural knowledge has
 	 involved the absolute rejection of authority."
 		-- Julian Huxley

It was just binary in the EPROM. I commented the code after it was
disassembled by the disassembler.

There is very little of the disassembled code that I've not commented.

The envelope generators is about all that's left that isn't fully
commented.

And even that is slowly getting thoroughly commented.

Mike



--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> On Sat, 20 Sep 2008, korgpolyex800 wrote:
> 
> > And yes, all of the code that I have written is commented like
that and 
> > all of the original Korg code that I understand is commented like
that. 
> > Is there a problem with my commenting?
> ==================
> 
> the original korg code is commented like that??? i thought all you'd
get 

> from interrogating the EPROM would be machine code, and you'd have to 
> decompile it just to get assembly...?
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"The incidence of disease has increased
>  	 in proportion to the progress of science."
>  		-- Akbarali Jetha
>

If you would just buy the kit, you would find out how random the
random waveform generator is. :-)

Mike

--- In korgpolyex@yahoogroups.com, Atom Smasher <atom@...> wrote:
>
> On Sat, 20 Sep 2008, korgpolyex800 wrote:
> 
> > Since we're working in 8 bits, it's periodicity is short. And it
could 
> > be made to be much better than it is. I just got a result that
sounded 
> > OK and stayed with that. But I am sure that I will go back and
revisit 
> > this little code snippet and work on it some time.
> ============
> 
> i won't pretend to understand the algorithm right now...  but i'm 
> wondering if it can be seeded with `random` midi or wheel data...?
it may 

> be a naive suggestion, but if the seed can be the address of, say, the 
> most recently recevied midi note/CC message (sync messages should be 
> ignored), would that benefit the randomness? and if midi messages are 
> being received while the random LFO is running, then it would also 
> increase the period?
> 
> 
> -- 
>          ...atom
> 
>   ________________________
>   http://atom.smasher.org/
>   762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
>   -------------------------------------------------
> 
>  	"Every great advance in natural knowledge has
>  	 involved the absolute rejection of authority."
>  		-- Julian Huxley
>

On Sat, 20 Sep 2008, korgpolyex800 wrote:

> If you would just buy the kit, you would find out how random the random 
> waveform generator is. :-)
=============

as soon as the atom-o-hawk is ready to ship...


-- 
         ...atom

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

 	"Nothing will benefit human health and increase
 	 chances for survival of life on Earth as much
 	 as the evolution to a vegetarian diet."
 		-- Albert Einstein

On Samstag 20 September 2008, korgpolyex800 wrote:
> Wow, now that I look at it in C, it definitely needs improvement.

If it's really implemented like you've commented, that would be so bad 
you should have heard as the longest cycle would be 9.  Maybe your 
assembler uses different mnemonics, but I think RLC should be "rotate 
circular", not "rotate through carry".  If so, then the C expression 
transforms to something more complicated:

m = ((m ? m : -m) << 1) + (m&0x80 ? 44 : 43);

Since you're not using a homogeneous recurrence (by virtue of adding 
43) zero is actually not a forbidden state and by excluding zero you 
indeed shorten the longest cycle from 128 to 121.  A better 
recurrence would therefore be:

m += (m&0x80 ? 44 : 43);

or equivalently:

; my pseudo random number generator - used for the LFO randomiser
; returns a random number in A

RANDOMIZE:      push    h ; save HL
                lxi     h, M_RANDOM ; point at the previous value
                mov     a, m ; put the seed value into A
RANDOMIZEA:     rlc ; rotate A circular
                adi     43 ; add 43 offset
                mov     m, a ; save in seed
                pop     h ; load HL
                ret ; return with pseudo random in A

The cycles associated with different seed values then are (seed before 
the colon, cycle length at the end in brackets):

0:	43, 129, 46, 135, 58, 159, 106, 255, 42, 127, 41, 125, 37, 117, 21, 
85, 213, 214, 216, 220, 228, 244, 20, 83, 209, 206, 200, 188, 164, 
116, 19, 81, 205, 198, 184, 156, 100, 243, 18, 79, 201, 190, 168, 
124, 35, 113, 13, 69, 181, 150, 88, 219, 226, 240, 12, 67, 177, 142, 
72, 187, 162, 112, 11, 65, 173, 134, 56, 155, 98, 239, 10, 63, 169, 
126, 39, 121, 29, 101, 245, 22, 87, 217, 222, 232, 252, 36, 115, 17, 
77, 197, 182, 152, 92, 227, 242, 16, 75, 193, 174, 136, 60, 163, 114, 
15, 73, 189, 166, 120, 27, 97, 237, 6, 55, 153, 94, 231, 250, 32, 
107, 1, 45, 133, 54, 151, 90, 223, 234, 0, 
[128]
2:	47, 137, 62, 167, 122, 31, 105, 253, 38, 119, 25, 93, 229, 246, 24, 
91, 225, 238, 8, 59, 161, 110, 7, 57, 157, 102, 247, 26, 95, 233, 
254, 40, 123, 33, 109, 5, 53, 149, 86, 215, 218, 224, 236, 4, 51, 
145, 78, 199, 186, 160, 108, 3, 49, 141, 70, 183, 154, 96, 235, 2, 
[60]
9:	61, 165, 118, 23, 89, 221, 230, 248, 28, 99, 241, 14, 71, 185, 158, 
104, 251, 34, 111, 9, 
[20]
30:	103, 249, 30, 
[3]
44:	131, 50, 143, 74, 191, 170, 128, 44, 
[8]
48:	139, 66, 175, 138, 64, 171, 130, 48, 
[8]
52:	147, 82, 207, 202, 192, 172, 132, 52, 
[8]
68:	179, 146, 80, 203, 194, 176, 140, 68, 
[8]
76:	195, 178, 144, 76, 
[4]
84:	211, 210, 208, 204, 196, 180, 148, 84, 
[8]
212:	212, 
[1]

There is a slight DC bias to the longest sequence and a strong one to 
all the others.  I think it would be easier to just put a random 
table into memory (if you can spare the 256 bytes).  That way you 
could even make this a general waveform by allowing to load new 
tables into memory and/or switch between different ones later on.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Yeah, the lookup table is looking more and more the right way to go.

But it's not going to stop me from releasing the latest software. :-)

Mike.



--- In korgpolyex@yahoogroups.com, ASSI <Stromeko@...> wrote:

>
> On Samstag 20 September 2008, korgpolyex800 wrote:
> > Wow, now that I look at it in C, it definitely needs improvement.
> 
> If it's really implemented like you've commented, that would be so bad 
> you should have heard as the longest cycle would be 9.  Maybe your 
> assembler uses different mnemonics, but I think RLC should be "rotate 
> circular", not "rotate through carry".  If so, then the C expression 
> transforms to something more complicated:
> 
> m = ((m ? m : -m) << 1) + (m&0x80 ? 44 : 43);
> 
> Since you're not using a homogeneous recurrence (by virtue of adding 
> 43) zero is actually not a forbidden state and by excluding zero you 
> indeed shorten the longest cycle from 128 to 121.  A better 
> recurrence would therefore be:
> 
> m += (m&0x80 ? 44 : 43);
> 
> or equivalently:
> 
> ; my pseudo random number generator - used for the LFO randomiser
> ; returns a random number in A
> 
> RANDOMIZE:      push    h ; save HL
>                 lxi     h, M_RANDOM ; point at the previous value
>                 mov     a, m ; put the seed value into A
> RANDOMIZEA:     rlc ; rotate A circular
>                 adi     43 ; add 43 offset
>                 mov     m, a ; save in seed
>                 pop     h ; load HL
>                 ret ; return with pseudo random in A
> 
> The cycles associated with different seed values then are (seed before 
> the colon, cycle length at the end in brackets):
> 
> 0:	43, 129, 46, 135, 58, 159, 106, 255, 42, 127, 41, 125, 37, 117, 21, 
> 85, 213, 214, 216, 220, 228, 244, 20, 83, 209, 206, 200, 188, 164, 
> 116, 19, 81, 205, 198, 184, 156, 100, 243, 18, 79, 201, 190, 168, 
> 124, 35, 113, 13, 69, 181, 150, 88, 219, 226, 240, 12, 67, 177, 142, 
> 72, 187, 162, 112, 11, 65, 173, 134, 56, 155, 98, 239, 10, 63, 169, 
> 126, 39, 121, 29, 101, 245, 22, 87, 217, 222, 232, 252, 36, 115, 17, 
> 77, 197, 182, 152, 92, 227, 242, 16, 75, 193, 174, 136, 60, 163, 114, 
> 15, 73, 189, 166, 120, 27, 97, 237, 6, 55, 153, 94, 231, 250, 32, 
> 107, 1, 45, 133, 54, 151, 90, 223, 234, 0, 
> [128]
> 2:	47, 137, 62, 167, 122, 31, 105, 253, 38, 119, 25, 93, 229, 246, 24, 
> 91, 225, 238, 8, 59, 161, 110, 7, 57, 157, 102, 247, 26, 95, 233, 
> 254, 40, 123, 33, 109, 5, 53, 149, 86, 215, 218, 224, 236, 4, 51, 
> 145, 78, 199, 186, 160, 108, 3, 49, 141, 70, 183, 154, 96, 235, 2, 
> [60]
> 9:	61, 165, 118, 23, 89, 221, 230, 248, 28, 99, 241, 14, 71, 185, 158, 
> 104, 251, 34, 111, 9, 
> [20]
> 30:	103, 249, 30, 
> [3]
> 44:	131, 50, 143, 74, 191, 170, 128, 44, 
> [8]
> 48:	139, 66, 175, 138, 64, 171, 130, 48, 
> [8]
> 52:	147, 82, 207, 202, 192, 172, 132, 52, 
> [8]
> 68:	179, 146, 80, 203, 194, 176, 140, 68, 
> [8]
> 76:	195, 178, 144, 76, 
> [4]
> 84:	211, 210, 208, 204, 196, 180, 148, 84, 
> [8]
> 212:	212, 
> [1]
> 
> There is a slight DC bias to the longest sequence and a strong one to 
> all the others.  I think it would be easier to just put a random 
> table into memory (if you can spare the 256 bytes).  That way you 
> could even make this a general waveform by allowing to load new 
> tables into memory and/or switch between different ones later on.
> 
> 
> Achim.
> -- 
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+
> 
> Factory and User Sound Singles for Waldorf Blofeld:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
>

On Sun, 21 Sep 2008, korgpolyex800 wrote:

> Yeah, the lookup table is looking more and more the right way to go.
>
> But it's not going to stop me from releasing the latest software. :-)
=================

aye.

it's probably my interest in crypto that makes me obsess about the quality 
of PRNGs, so feel free to tell me i'm nuts... how about a big lookup table 
(big being 256-1024 values, derived from high quality RNG) and a function 
that periodically selects a new pseudo-random location within the table to 
read from and/or reverses the read direction.

things were so much simpler when a "sample and hold" circuit was just 
that, derived from transistor noise.


-- 
         ...atom

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

 	"If you step back and look at the data, the optimum amount of
 	 red meat you eat should be zero."
 		-- Walter Willett, M.D., of Brigham and Women's
 		Hospital, director of a study that found a close
 		correlation between red meat consumption and
 		colon cancer.

On Mon, 2008-09-22 at 09:24 +1200, Atom Smasher wrote:

> things were so much simpler when a "sample and hold" circuit was just 
> that, derived from transistor noise.

Use diode noise feeding a pin on the CPU to give random 1s and 0s, and
sample them when you get the chance.

Gordon

On Sonntag 21 September 2008, Atom Smasher wrote:
> it's probably my interest in crypto that makes me obsess about the
> quality of PRNGs, so feel free to tell me i'm nuts...

Head over to www.ciphersbyritter.com then. :-)

> things were so much simpler when a "sample and hold" circuit was
> just that, derived from transistor noise.

It is actually quite difficult to reduce the correlation of such 
signals so that they pass the even the third or fourth test of 
randomness.  About the only source ouf physical randomness that 
doesn't have these problems is radioactive decay (and that is a 
problem in itself).  If all you need is something that doesn't 
overtly repeat and has a white spectrum, things are comparatively 
easy.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

On Sun, 21 Sep 2008, ASSI wrote:

>> it's probably my interest in crypto that makes me obsess about the 
>> quality of PRNGs, so feel free to tell me i'm nuts...
>
> Head over to www.ciphersbyritter.com then. :-)
==============

i'm not that kind of nut. i'm the kind of nut that uses 4096 RSA 
encryption keys on my pgp key.


-- 
         ...atom

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

 	"The universe is not hostile, nor yet is it friendly.
 	 It is simply indifferent."
 		-- John Hughes Holmes

Atom Smasher wrote:
> On Sun, 21 Sep 2008, ASSI wrote:
> 
>>> it's probably my interest in crypto that makes me obsess about the 
>>> quality of PRNGs, so feel free to tell me i'm nuts...
>> Head over to www.ciphersbyritter.com then. :-)
> ==============
> 
> i'm not that kind of nut. i'm the kind of nut that uses 4096 RSA 
> encryption keys on my pgp key.

Use 4097 bits.  Not only is it twice as hard to crack, but no-one would 
guess it was a funny size...

Gordon

I swear I shall never mention the word "random" on this list ever again!

Mike.

--- In korgpolyex@yahoogroups.com, Gordon JC Pearce <gordon@...> wrote:

>
> Atom Smasher wrote:
> > On Sun, 21 Sep 2008, ASSI wrote:
> > 
> >>> it's probably my interest in crypto that makes me obsess about the 
> >>> quality of PRNGs, so feel free to tell me i'm nuts...
> >> Head over to www.ciphersbyritter.com then. :-)
> > ==============
> > 
> > i'm not that kind of nut. i'm the kind of nut that uses 4096 RSA 
> > encryption keys on my pgp key.
> 
> Use 4097 bits.  Not only is it twice as hard to crack, but no-one would 
> guess it was a funny size...
> 
> Gordon
>

We can use traditional synthesizer term from analog times - S/H  
(Sample @ Hold).

Daniel Forro

On 22 Sep 2008, at 7:56 AM, korgpolyex800 wrote:

> I swear I shall never mention the word "random" on this list ever  
> again!
>
> Mike.
>
>

On Sun, 21 Sep 2008, Gordon JC Pearce wrote:

>> i'm not that kind of nut. i'm the kind of nut that uses 4096 RSA 
>> encryption keys on my pgp key.
>
> Use 4097 bits.  Not only is it twice as hard to crack, but no-one would 
> guess it was a funny size...
==================

when dealing with symmetric encryption, each extra bit doubles the 
keyspace. with asymmetric encryption (RSA) it doesn't quite scale the way. 
http://en.wikipedia.org/wiki/Cryptographic_key_length#Asymmetric_algorithm_key_lengths


-- 
         ...atom

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

 	"We hang the petty thieves and appoint
 	 the great ones to public office."
 		-- Aesop