Organ Tone Wheel development.

Studiowaves · 2024-07-17T07:35:04+00:00

There was an error rendering this rich post.

The nice thing about an organ tone wheel is how the phase between notes played at different times remains the same. This is quite different than a polyphonic ensemble because playing octaves or other intervals can produce a variety of phase relationships between the notes. With a polyphonic instrument while holding down a low A note with a strong second harmonic and randomly playing an octave higher, will produce different second harmonic volumes . However with a single tone wheel the notes will stay consistent because the notes played are really simply fading in notes from the same continuously running tone wheel. So there is no phase difference at any time. I'm curious how others would make a monophonic rotating tone wheel within Reaktor yet still be able to tap into the tone wheel with multiple notes like a polyphonic instrument. At the moment I think it's easier said than done. Does anyone care to propose a solution to this problem?

Find more posts tagged with

Reaktor Building

Comments

colB

https://community.native-instruments.com/discussion/33263/organ-tone-wheel-development

Every note has a different tone wheel. they are in groups of 4, each group has its own gearing from the main spindle, so apart from octaves, the rest do move in and out of phase with each other over time.

To model the behaviour in a poly situation, so that when voices are re-assigned starting phase is 'correct' for that note, should be relatively easy, there are probably many ways to achieve it.

Most obvious would be to just have a shared 64 bit accumulator that only resets on power up, and use modulo arithmetic to calculate the starting phase from that when a new poly note is started. (at 48000Hz, a 64 bit accumulator will maintain suitable precision (sample accurate) for hundreds of years).

You just need to know the motor speed, gear ratios, and number of teeth on the tone wheels. That info is readily available online.

The real challenge is modelling the tonewheel/pickup interaction, and of course, the leslie speaker. There are academic papers out there relating to both of these topics.

Studiowaves

I think it can be done by running 11 ramp type oscillators simultaneously. They need to be the top octave of the organ keys. Next, you can tap onto these ramps and do two things. First, rig something up that locks on to the ramps current value but has it's own reset. So for example say a note an octave down from high C was played and high C was the highest frequency of all 11 ramps. When the octave down note is played, initialize it's ramp with the current value of high C's ramp. Then let it clock up in tandem with C2 but let it continue to clock twice as long as C3. So now we have a ramp that is an octave down from C3 but has twice the amplitude. Next divide the amplitude by 2 and use the ramp in place of the ramp in the ramp to sine converter. I think you'll get a phase coherent octave down sine wave. Of course playing a note 2 octaves down will need to be 4 times as long and divided by 4 to get a note 2 octaves down. So that takes care of the phase problems with a polyphonic synth where the sine start at zero when the note is played. You also need to fade the note in to minimize the click because it doesn't start at 0. Once you have the ability to generate the ramp of the fundamental that is phase locked with one of the 11 master ramps you're good to go. This ramp can be multiplied by 2 or 3 or whatever to generate sinewaves that have their volume adjusted by the drawbars. Basically whenever a single note is played it is first phase locked with one of the 11 master continuously running oscillators, next it is divided down by the number of octaves it is below the masters and then scaled by dividing by the same number. Then this new ramp also generates 8 other ramps that are the frequency ratios of the 8 drawbars. Like 2, 4, 2 and 2/3 etc. Since there is a sub oscillator which I think is labeled 16 in might be best to generate a ramp for each note that is another octave down for starters. Then make the other 7. I think they are just time 2,3,4,5,6,7 or something like that in reality by end up being label as 16, 8, 4, 2 and two thirds and so on. I can't think of any other way to do it. I don't see one long ramp like your talking about yet. If anything it might be one continuous clock, which it is. Please elaborate…

colB

There is just one main drive in a Hammond, so just one audio rate counter, and some simple modulo arithmetic, and gear ratio calculations (that will just be constant values in an implementation) will do everything you need, for all the tone wheels.

colB

Here is a sketch of what I was describing. It works just fine, however there is an issue due to a limitation of core integer arithmetic, so it's not a complete solution.

At the top you can see the ramp being generated (ideally this would be in a separate monophonic core cell, but we can't send doubles across primary without extra code that would obfuscate this somewhat).

Then each partial has it's frequency calculated, after which, modulo arithmetic is used based on that frequency to generate a 0..1 phase which is scaled and turned into a sine wave.

(all this fuss to try and synchronise the phases of partials is probably pointless. Real Hammonds have a clutch on every tone wheel that is fairly light, the wheels are not phase aligned, and can probably drift somewhat during use)

Anyway, the problem is that core only handles 32 bit integers, so after maybe 24 hours, this model collapses. That seems like it shouldn't matter, but if it's no good, it's no good.

It would be possible to work around that limitation in various ways, a better model of the drive train would make it simple enough to sort because we could count motor revolutions, and just store the fractional part of the current one… that would sort the problem completely, but I'm not sure that it's even necessary to lock phases for a reasonable model, might even be bad.

The real trick(s) IMO are modelling the other stuff accurately, like the waveforms, particularly for the lowest pitches/partials which are not sines… also the gear ratios probably don't give exact equal temperament frequencies, and some of the tone wheels are used for different tasks, e.g. sometimes as a fundamental, sometimes as a higher harmonic. Those will be a compromise in one or even both of those contexts.

I did have a quick go at a rough sketch of the Vibrato scanner based chorus. This does give a nice effect… this sort of thing is what makes the difference IMO.

Other things to implement for a good model:

convincing distortion/saturation

rate envelope for the chorus when switching it on/off changing rate

accurate waveforms (particularly the low end for that growl - not ever getting that from sines).

pickup simulation

decent model of the transient 'click' that is so important for the character of the instrument (switch bounce and broadband electrostatic noise burst or something).

more accurate scanner model

good leslie speaker model (yeah right :-))

tone wheel sketch 03.ens

colB

yeah, I quickly tried with unsynchronised sines, and the sound is identical AFAIKT.

Studiowaves

https://community.native-instruments.com/discussion/comment/166616#Comment_166616

I see what you're doing.

I don't know it the modulo's create exact frequencies though. Are they a little bit off?

This may be a good way to generate the draw bar tones but the ramp will eventually reach it's max. Maybe start out with 11 equal tempered ramps of the lowest notes or highest notes ever played and connect those ramps to these modules for the draw bars. That'll mitigate the forever increasing ramp.

Perhaps use the ramps of the highest notes played and create a sub oscillator from the note played that stays in sync with the master oscillator. Or the other way around and start out with the lowest notes running the master oscillators. That might be better because there's better resolution to start out with.

I read an article and found something out I didn't know, some organs actually had 12 bars. One for each note and a dummy for balance of some sort. I guess that's why we need 11 master ramps. One for each note. Seems like the modulo's would still act like independent ramps even if they don't start at 0. But that's ok because the note on and off need attack and release time. So the offset won't be so bad. Also it might work out better if the low notes have longer attack and release times than the higher notes.

colB

https://community.native-instruments.com/discussion/comment/166862#Comment_166862

I don't know it the modulo's create exact frequencies though. Are they a little bit off?

Its very simple math. Do the frequencies sound off to you? do you want them to be off?

Studiowaves

https://community.native-instruments.com/discussion/comment/166618#Comment_166618

Yeah, they are perfectly in sync. So far so good. Too bad the ramp can't reset. It can but the length has to be divided equally by all tones multiplied by each other. That's a big number.

Studiowaves

https://community.native-instruments.com/discussion/comment/166872#Comment_166872

They don't sound off but I heavily edited my original response after I realized the main ramp has a time restriction. I guess it depends on whether an organ part actually stops with no notes. It could be reset and held at 0 waiting for any key to be pressed if the counter lasts long enough. That's about the only problem I see.

Studiowaves

Hey Colin, check this out. Your solution is perfect. I had no idea a 64bit ramp will continue for 266,879,977,918.25161481481481481481 hours at 192k sample rate. Holy cow, did I do the math wrong or something. If that's right, your solution is perfect. There is something else that needs to be done with a tone wheel though. Organs have something called foldback that prevents tones from getting too deep or too high. We talk about that once before but to refresh your memory they basically crossfade descending tones into below around 30 hz or so into the octave high. They also do the same for high tones except the crossfade climbing notes in notes playing an octave down. The modulo might work for that but I'm not sure how to do it. Basically any drawbar needs to start repeating the same octave over and over when the tones are too high of too low. Generally the fundamental tone of an organ is not the problem, it's the drawbar that cause the problem. Those good organs managed to pull that off with the teeth. I think it ends up sounding better than simple filtering. Otherwise I see no reason to do it. I found the info a while back on how it was done. If I remember, they had it down to a fine art. Every draw bar was customized to start the foldback process at a certain tone.

Can the modulo's be set to turn over if the ramp is going down? The modulo's only need to start working above or below a certain threshold of the drawbar tones. I don't think it's necessary for the actual pitch of the key pressed, just the drawbars. The 16 foot bar is the problem going down and the others are the problem going up.

colB

Foldback is a strategy to reduce unit cost and weight by reusing tonewheels where possible. So for very high notes and sometimes low notes, an upper harmonic might use an existing tone wheel in the 'wrong' octave, because it sounds OK, and otherwise the price and weight of the units would be even more ridiculous.

So for higher notes, sometimes an upper harmonic might re-use that harmonic from the note an octave lower. And for low notes, they might reuse some particular harmonic from the same note an octave above.

The hammond organs seem to have a fairly agricultural tonewheel selections system per note. Each key is a large multi-pole switch, one pole for each harmonic/tonewheel. It's really like a large matrix switching system. The audio signal from the always active tonewheels is routed directly through these 9 pole physical switches. In that context, reusing a tonewheel as different harmonics of different notes is relatively trivial.

That's also what gives the characteristic transient click at the start of each note.

For a Reaktor model, its not important to 'reuse' a tonewheel, you could just create one the same… The main thing would be to 'catch' the notes that use foldback and treat them as special cases, changing the frequency of some harmonics. Just a few compares and router would do it simply enough…

Like:

If P = someFolbackNote then Harmonic5pitch = 96 else Harmonic5pitch = 108

…that sort of thing. Very simple to implement in a Reaktor model.

Alternatively, just create a big table with entries for all partials for all notes, and just look up the table each time for every note.

The potential issue here is that maybe? in the hardware, if multiple notes are reusing the same tonewheels, those tonewheels will not be cumulatively added to the output mix, and so be louder over all. The are just being passively mixed in. So if a tonewheel is being switched into the mix in in say 4 different places, it won't be 4 times louder, because it's still just one tonewheel and it's a passive matrix. That might be more important that the idea of phase locking (which i'm pretty sure is a red herring due to the way the tonehweel clutches work).

I'll have to have a think about how best to implement that to see if it makes a difference to the sound.

Studiowaves

https://community.native-instruments.com/discussion/comment/166978#Comment_166978

That makes sense, I was thinking they may have tried to fatten up the upper registers by folding back the overtones that are way up there above the 3-4k, the high tones produced by the drawbars. I guess that's possible but maybe it was a case of making the most with what teeth they had to work with. I'm kinda leaning towards the lookup table suggestion because I found a list of what they actually used for each note and where each drawbar started its foldback. The tables could easily be made with excel and it should be easy on the cpu because each table will only be addressed when a note is played and it's event based. Probably have two tables, another for relative volume for each tone. That might equate to what they did for the most part. The click is easy and the percussion could be done with fm. I think they had a choice of either a third harmonic or second harmonic percussive tone that was only kicked in on the first note played and anytime after all keys have been released.

Anyway, that was pretty good thinking using a single ramp with the modulo's. That might actually come in handy for a lot of things. I guess it works because all ramps initialize at start up. You don't really have to have the overtones for the draw bars if you're making a synth of some sort and it might fix up an everyday subtractive synth too. It is kind of irritating when your playing octaves on low bass notes and the timbre changes depending on your timing. Ya man, that's pretty swift, I guess the only drawback is the need to fade in the note. Without a fade in you'll get a click if it doesn't start at zero. That's what I though the click was on the organ but they may have produced a click by another means so all notes would have the same click volume or at least sound like they do. This is pretty good, it has a section of fold back.https://electricdruid.net/technical-aspects-of-the-hammond-organ/#:~:text=Harmonic%20foldback%20is%20used%20to%20reduce,tonewheels%20%281-91%29%20used%20for%20each%20harmonic.&text=Harmonic%20foldback%20is%20used,used%20for%20each%20harmonic.&text=is%20used%20to%20reduce,tonewheels%20%281-91%29%20used%20for

colB

Click is mostly from the initial discontinuity to the current waveform position, however, it's not just a simple jump. There are 9 switches, one per partial, that will have a tiny delay between their activation due to the mechanical nature of the hardware. Each of the 9 switches will also have some switch bounce, so multiple clicks before settling. This combination means that it's a more chunky musical click, and although it's variable and somewhat random, its always there.

Using the correct partial frequencies really does make a difference to the sound - more authentic. Particularly in the context of saturation where the intermodulation doesn't seems so dissonant.

tonewheel example01.zip

(excuse the noodling, Im no keyboard player, but you can hear the key click …I pulled out a few couple of drawbars half way through)

Chet Singer

Here's another way to do it.

Hammy 91 | Entry | Reaktor User Library (native-instruments.com)

It's an instrument that is 91-note polyphonic, since a Hammond has 91 tone wheels. Each voice is a single fixed-pitch sine oscillator. There's an event switching mechanism to route the keys being pressed through the drawbars to the oscillators. It also includes harmonic foldback.

colB

https://community.native-instruments.com/discussion/comment/167623#Comment_167623

Ah, very nice solution. voice shifting the amplitudes.

It solves one of the more problematic issues of modelling the tonewheels polyphonically. The voice shift info says "if multiple voices are routed to the same output voice, they will be summed". So when a tonewheel is used by multiple different notes, the voice shift automagically guarantees the correct amplitude.

I will be trying this out :)

Also need to work out how to do the scanner properly. I have basically the same thing as you do, but the real thing isn't actually a delay line, it is built from cascaded LC filters, so the delay is filter group delay, meaning that the chorus effect changes with frequency . That's probably why it has such a rich sound. I found a paper on modelling this, but it is heavy going.

Also need to find some source for info on the tonewheel pickups and transformer based filters. It seems that the tonewheels themselves don't produce a particularly good sine, but the pickup might(?) be tuned to help isolate the fundamental, and then the transformer/filter does the same thing with a resonant filter… Would be nice just to see some spectograms for individual tonewheels at that point after the filter… then just hack something together to give a similar spectrum.

Quick links

Unanswered questions