Building musical synthesizers and keyboards

[Fungus]

I just discovered this guy on Youtube:



Thought I'd plug him.



Apparently he's built most of that stuff himself. He doesn't look old enough to me, but... 



He even has an oscilloscope and signal theory tutorial:

[Fungus]

Just reading some of the mad things he does in his synthesizers, eg. clock an Arduino synth using a 555 timer then ramp the clock speed up and down with a potentiometer for pitch change - it's completely 'analog'(!)

[JanJansen]

Thermistors or NTC's can be used to temperature compensate VCO's. These are cheap, available at 1% tolerance from Digikey. I sandwiched one of these
between the two transistors of the exponential converter using epoxy.

https://www.digikey.com/product-detail/en/vishay-bc-components/NTCS0805E3472FMT/BC2576CT-ND/2237413

A tutorial on exponential convertors and temperature compensation at http://www.schmitzbits.de/expo_tutorial/ shows how.

Most NTC manufacturers have application notes describing how to linearize their response. I used this technique in a VCO I designed about 20 years ago.
It worked very well.

Thank you, i have to read about this, making these thermistors linear for VCO, if i cant find out i will make a topic about this, thanks.

At only 2 channels per DSPIC, with a very fast DAC, you have enough processing power to replicate an analog synth to the point where it would be indistinguishable from an analog synth.  You should be able to do 4 to 8 channels with a cheap CD audio grade DAC.

I am using DSPIC33FJ128GP802 with build in stereo DAC ( delta sigma ).
And yes i get 4 voices out of it ( @ 44K1Hz ) with the free compiler, when upgrading compiler i should be able to get 8 voices polyphony.
( i,m to much still a beginner to have external DAC )

What 16 bit audio DAC do you recommend to buy, i dont wanto harvest it out of old CD players.
Once i get busy with 32 bit i need external audio DAC, since there are currently still no 32bit PICs with audio DAC.

Yep, at some point the 'analog' part can be simulated so well you can't tell the difference. It's just a case of processing power. 192kHz simulation is probably enough for sound.

If a analog noise-generator is used for random values in the chip, yes, then you can fool me with digital, else it sounds predictable.

Why do you need one per key? You just need a bank of them and one other master uC reading the keyboard and telling them what to do.

Exact, dont need 128 chips, only the max nr voices you wanto play together.
The only problem i see is how to implement the LFO ?, do you use the ADC on all chips to sample the LFO ?

Floating point DSPs have been reasonably cheap since the early 1990s.

Ok, the 32bit PICs seem to also have fast float supported.
I use this DSPIC wich has very slow float, impossible to use for realtime performance.

I made everything integer, it is more accurate then using float.
When using other chips with float support i can imagine it is still better to use integer math, if you have enough size for all lookuptables.

[Fungus]

Exact, dont need 128 chips, only the max nr voices you wanto play together.
The only problem i see is how to implement the LFO ?, do you use the ADC on all chips to sample the LFO ?

I imagine you recreate the LFO on every chip.

[Fungus]

If a analog noise-generator is used for random values in the chip, yes, then you can fool me with digital, else it sounds predictable.

Only if it's a lookup table.

It's all really just a case of processing power, run a random number generator with a high enough period and it won't repeat.

[BrianHG]

If a analog noise-generator is used for random values in the chip, yes, then you can fool me with digital, else it sounds predictable.

Only if it's a lookup table.

It's all really just a case of processing power, run a random number generator with a high enough period and it won't repeat.

Yup, running a 2 different 96 bit shifting random number generators, 1 summing & 1 xor with the right 2 coefficients, results xored together, using any middle 16-32 bits as your random integer will make a non-repeating random noise generator.  You may use 2 or 4 of each 72 bit result to get more than 1 different random number at the same time.

Programming this properly in assembly for a PIC32 will get this random number down to around 20 clock cycles + 9 words of ram.
Programming this in C will be tricky to achieve the same efficiency as assembly since it's mostly 96 bit rotates/adds&xors with a few fixed numbers.

Simpler smaller random number generators exist, but, the patterns are predictable to the ear, especially 8 bit, 16 bit and 24 bit varieties.  Even 32 bit for the simpler varieties.

[Fungus]

It's all really just a case of processing power, run a random number generator with a high enough period and it won't repeat.

Yup, running a 2 different 96 bit shifting random number generators....

I don't know if 96 bits is needed bu that's the principle - run 2 or 3 simple generators and combine them.

https://en.wikipedia.org/wiki/KISS_(algorithm)

RC4 is very efficient on 8-bit machines if you've got a 256 bytes of RAM to spare: https://en.wikipedia.org/wiki/RC4

[JanJansen]

What i mean is analog noise is not as perfect flat, makes unpredictable,
you have to try it yourself.

[BrianHG]

It's all really just a case of processing power, run a random number generator with a high enough period and it won't repeat.

Yup, running a 2 different 96 bit shifting random number generators....

I don't know if 96 bits is needed bu that's the principle - run 2 or 3 simple generators and combine them.

https://en.wikipedia.org/wiki/KISS_(algorithm)

RC4 is very efficient on 8-bit machines if you've got a 256 bytes of RAM to spare: https://en.wikipedia.org/wiki/RC4

64 bit + 32 extra bits at the top on the xor/adding shifting barrel means if you use all 64 bits as a result, they will still be absurdly random.

[BrianHG]

What i mean is analog noise is not as perfect flat, makes unpredictable,
you have to try it yourself.

You can easily filter the results with a few additional multiply adds with a few words of ram.  But, remember, the simple table, or basic 8/16/24/32 bit random number generators, especially the ones which are available to call in the 'C' compilers are not that flat at all.  Putting them through an FFT leaves peaks and bumps which is how at times engineers reverse engineer random number generators.  Even when I've done some 2D noise filters using them on images left distinct patterns in the picture if the background was all black with just the right amount grey grain.  Sorta why I had to learn about the larger 64 & 96 bit DIY random number generator varieties.  They do make a real difference.  Unless your 8/16/32bit MCU signal generator was programmed by someone looking into random number generation at cryptography levels, they will all have the flaw of using simple patterns or using existing basic RND 'C' calls to achieve their noise and it will show (be audible) in when attempting to synthesize analog sounds since each cycle is calculated to a perfect clock.  This cannot happen in a true analog domain, or, you need a good enough random number generator to replicate the true analog domain effect.  If you want a filtered noise, like pink noise & a high pass on the VLF frequencies, this is all to easy to do if you put in the effort.

Note that all the most annoying aspect replicating patterns of the standard C RND functions used are mostly in the VLF domain which vanishes in the 96bit generator.  Combine this VLF with pitch bending in a synth does create a audibly traceable crap effect just like when I tried to use the same RND on my 2D images when the resolution and brightness mix was just right.


If you don't believe how bad the current state of the RND generators are and that they are truly behind what you are hearing, go to this website and just scroll down to the 2 images in the middle of the page:
http://boallen.com/random-numbers.html

Use that in your synth, and it will leave audible artifacts, because the noise isn't actually white of flat at all & there is a repetitive nature to it.

I mean just look at how lousy that 32 bit floating point random number generator is.  You cant say that noise is truly white...

[GK]

This discussion in the context of synth noise generation isn't making a lot of sense 

A maximal-count LFSR (linear feedback shift register) will repeat its bit sequence every (2^n)/2 clock cycles, where n is the number of register bits.

So a 24-bit LFSR clocked at 44kHz will repeat its bit sequence every 190s. Nobody has the auditory memory to pick up on that.

For 96 bits that increases to 900320028571185654472090s. 

[helius]

LFSRs are common in hardware implementations. They are rather inefficient in software: unless your processor has very complex instructions, it needs to do three instructions (a shift, a mask, and an xor) per tap. For a 24-bit shift register with 8 taps, that is 24*8*3 = 576 instructions per word output. Times 44.1 kHz is already 25.4 MIPS; this is a stupid way to use a processor.

[GK]

LFSRs are common in hardware implementations. They are rather inefficient in software: unless your processor has very complex instructions, it needs to do three instructions (a shift, a mask, and an xor) per tap. For a 24-bit shift register with 8 taps, that is 24*8*3 = 576 instructions per word output. Times 44.1 kHz is already 25.4 MIPS; this is a stupid way to use a processor.

The "word" does not repeat every 1/44100 s - only one bit is shifted out per "clock" cycle. Make that 1.05 MIPS. And you don't need 8 taps either; just choose an adequate shift register size that requires less taps for "maximal" count. And if you don't require your noise to be white right up to 20kHz you can get away with a bit rate much less than 44k. I only picked 24-bits and 44k as an example to put perspective on the bit sequence repetition rate.

[Someone]

LFSRs are common in hardware implementations. They are rather inefficient in software: unless your processor has very complex instructions, it needs to do three instructions (a shift, a mask, and an xor) per tap. For a 24-bit shift register with 8 taps, that is 24*8*3 = 576 instructions per word output. Times 44.1 kHz is already 25.4 MIPS; this is a stupid way to use a processor.

The "word" does not repeat every 1/44100 s - only one bit is shifted out per "clock" cycle. Make that 1.05 MIPS. And you don't need 8 taps either; just choose an adequate shift register size that requires less taps for "maximal" count. And if you don't require your noise to be white right up to 20kHz you can get away with a bit rate much less than 44k. I only picked 24-bits and 44k as an example to put perspective on the bit sequence repetition rate.

Exactly, you can select efficient polynomials which are easier to implement on the chosen platform, I'll see if I can find the AVR examples I came up with that were all just a few instructions per byte.

[BrianHG]

This discussion in the context of synth noise generation isn't making a lot of sense 

A maximal-count LFSR (linear feedback shift register) will repeat its bit sequence every (2^n)/2 clock cycles, where n is the number of register bits.

So a 24-bit LFSR clocked at 44kHz will repeat its bit sequence every 190s. Nobody has the auditory memory to pick up on that.

For 96 bits that increases to 900320028571185654472090s. 

Check the image in my above posted link of Microsoft's 32bit number generator.  Tapping the MSB shows that repeated 1 bit pattern.  The full blown 24bit number generator in your example may not repeat for 190s, but, within that, the loudest part of the signal, which is the most important part to our ears, may be repeating once a second or faster.

I chose a cheap version of a 96 bit RND number generator which runs on a single shift of the 2 different bulks with nothing more than XOR and addition with 2 fixed integers since it can be cheaply adapted to a 16 or 32 bit MCU in only a few instructions running once.  We are talking around 20 cpu clocks.  This cheap ass quick method only reveals around 48 bits of true randomness, but creates wild noise very quick.  A proper full 96 bit generator requires shifting and individual bit test + xor-ing, in addition to the second random generation which is based of bit-test and addition which makes a nasty loop eating up a ton of CPU mips for nothing, or, you can write this into an FPGA to do a full transform once every clock cycle.

If you actually even tap bit 96 in a large random number generator, it will also seem to repeat on it's ow fairly quick as well.  Luckily, I avoid this by using the center 32 bits which appear completely random on their own.

[Fungus]

If you don't believe how bad the current state of the RND generators are and that they are truly behind what you are hearing, go to this website and just scroll down to the 2 images in the middle of the page:
http://boallen.com/random-numbers.html

Use that in your synth, and it will leave audible artifacts, because the noise isn't actually white of flat at all & there is a repetitive nature to it.

I always thought the standard random number generators were bad on purpose - to force people to go out and find one that actually fits their application.

(nb. there's no 'perfect' RNG).

[Fungus]

Check the image in my above posted link of Microsoft's 32bit number generator.  Tapping the MSB shows that repeated 1 bit pattern.

Yep. ANY generator that cycles through all possible combinations of values in a sequence will have at least one bit that goes 010101010101010 and probably another one that goes 00110011001100110011, etc.

At the end of the day it's just a complicated counter. Every bit has to follow some sort of a sequence.

The way to overcome this problem is to XOR two (or more) unrelated RNGs together.

https://en.wikipedia.org/wiki/KISS_(algorithm)

[BrianHG]

Check the image in my above posted link of Microsoft's 32bit number generator.  Tapping the MSB shows that repeated 1 bit pattern.

Yep. ANY generator that cycles through all possible combinations of values in a sequence will have at least one bit that goes 010101010101010 and probably another one that goes 00110011001100110011, etc.

At the end of the day it's just a complicated counter. Every bit has to follow some sort of a sequence.

The way to overcome this problem is to XOR two (or more) unrelated RNGs together.

https://en.wikipedia.org/wiki/KISS_(algorithm)

Your link has an error, I think the closing bracket needs to be included to show the proper wikipedia page.
Yup, the 96 bit generator I use is actually 2 different 48 bit generators summed together.

[GK]

This discussion in the context of synth noise generation isn't making a lot of sense 

A maximal-count LFSR (linear feedback shift register) will repeat its bit sequence every (2^n)/2 clock cycles, where n is the number of register bits.

So a 24-bit LFSR clocked at 44kHz will repeat its bit sequence every 190s. Nobody has the auditory memory to pick up on that.

For 96 bits that increases to 900320028571185654472090s. 

The full blown 24bit number generator in your example may not repeat for 190s, but, within that, the loudest part of the signal, which is the most important part to our ears, may be repeating once a second or faster.

I'm sorry, but this is just wrong. From (a reference immediately at hand) AOE 2nd ed, page 440:

9.37 Power spectrum of shift register sequences.

The output spectrum generated by maximal-length shift registers consists of noise extending from the repeat frequency of the entire sequence, fclock/K, up to the clock frequency (fclock) and beyond. It is flat within +/-0.1dB up to about 12% of the clock frequency, dropping rather rapidly beyond its -3dB point of 44% fclock.

[BrianHG]

@GK, would you accept that in this document: https://web.archive.org/web/20161007061934/http://courses.cse.tamu.edu/csce680/walker/lfsr_table.pdf
Page 1, table 1, the 24 bit LFSR-4 is the 24bit LFSR random number generator you are talking about?
Or this one: http://www.xilinx.com/support/documentation/application_notes/xapp052.pdf
Page 5, table 3, the 24 bit LFSR-4 is the 24bit LFSR random number generator you are talking about?
(The 2 differ slightly by choosing 2 different bits to xor with the output, but they should be close)

If so, give me this weekend and I will plot the monochrome results on a 2d B&W image and going a step further I'll plot another version using bits 24 & 23 to create 4 shades of grey to see if we have any visual pattern.  If the results are a perfect snow, then yes, there would be no coincidental mixing artifacts with this noise generator mixed with other tones in a music synthesizer.

If there are any visible patterns, these patterns will, when mixed with some tones or notes in a music synthesize create an audible artifact.
Can we agree on this much?

(I like these challenges and will admit defeat if I cant find any patterns...)

[Fungus]

If there are any visible patterns, these patterns will, when mixed with some tones or notes in a music synthesize create an audible artifact.
Can we agree on this much?

It probably will, but not necessarily.

It all depends on how you choose the bits that go into the sound. As noted above, each bit in the RNG will follow some sort of a sequence.

How audible the artifacts are will depend on the bits you choose for the MSBs of the sound samples.

[BrianHG]

If there are any visible patterns, these patterns will, when mixed with some tones or notes in a music synthesize create an audible artifact.
Can we agree on this much?

It probably will, but not necessarily.

It all depends on how you choose the bits that go into the sound. As noted above, each bit in the RNG will follow some sort of a sequence.

How audible the artifacts are will depend on the bits you choose for the MSBs of the sound samples.

It's the nasty problem with synths that they usually use nice smooth pitch bends and wobbles with means if there are any hidden patterns in the noise, it will come in and out of the sound as phase go in and out.  This is one of those things that only the users of the analog synths instruments will hear where as us, the public wouldn't notice a thing, or, if we do, we would believe it is the way it supposed to sound.

[Fungus]

If you actually even tap bit 96 in a large random number generator, it will also seem to repeat on it's ow fairly quick as well.  Luckily, I avoid this by using the center 32 bits which appear completely random on their own.

Each of those 32 bits will follow its own pattern, just like bit 96.

[BrianHG]

If you actually even tap bit 96 in a large random number generator, it will also seem to repeat on it's ow fairly quick as well.  Luckily, I avoid this by using the center 32 bits which appear completely random on their own.

Each of those 32 bits will follow its own pattern, just like bit 96.

If it was a single 96 bit LFSR generator with only 4 xored bits at the top, yes.  Since it is 2 different 48 bit generators, only one of which is a LFSR generator, the sum results breaks up the pattern.

[Fungus]

If you actually even tap bit 96 in a large random number generator, it will also seem to repeat on it's ow fairly quick as well.  Luckily, I avoid this by using the center 32 bits which appear completely random on their own.

Each of those 32 bits will follow its own pattern, just like bit 96.

If it was a single 96 bit LFSR generator with only 4 xored bits at the top, yes.  Since it is 2 different 48 bit generators, only one of which is a LFSR generator, the sum results breaks up the pattern.

Ah, OK, I'm confusing two threads.