I've been trying to make a cheapo Hammond 'emulation' (I'm using the term lightly). 9 drawbars means 9 sines per voice, which really eats into the possible voice count.
Is there anything obvious I'm missing that would make this more efficient while still retaining full 'drawbar' control?
Best approach for additive 'organ' patch?
Drawbar organ emulation
Looped samples?
Mind you, that's a lot of samples, if you want to cover every possible combination of 9 harmonics...
a|x
A drawbar organ has (typically) 91 fixed, chromatically tuned oscillators running all the time, pressing a key taps the outputs of these oscillators according to the drawbar settings.
http://electricdruid.net/technical-aspects-of-the-hammond-organ/
http://www.goodeveca.net/RotorOrgan/ToneWheelSpec.html
That does not match well with the voice allocation mechanism...
I believe it is possible, but not by patching together standard objects. I opened a topic in the AxoObject Coding category for further discussion.
Haha, I'm not literally trying to make it possible for every key to sound at once like an actual organ! However, the most I've managed is 5 voices reliably, with 6 I started to get stuck notes as the Axoloti dropped MIDI messages. 8 would be a nice target I guess - would allow big two hand chords.
So what I have at the moment is a voice subpatch with 9 sine wave oscillators tuned to the 9 relative pitches of the drawbars, plus a short decaying burst of white noise as a simple keyclick emulation. It seems like 54 sine oscillators is too much (6*9), I was just wondering if I was missing something that might make my organ voice cheaper. I'm going to try experimenting with a single phasor and multiple sine lookups.
@toneburst Thanks for the suggestion, but my goal is definitely to try and replicate the drawbar control (on my Korg MicroKontrol's faders - unfortunately it's one fader short but never mind). A wavetable approach had occurred to me, but it's not controllable in the way I'd want.
EDIT: I think I'm onto something with the single phasor - multiple lookup approach. A leftwards bitshift of the phasor does give me octaves up, the overflow means that the phasor wraps nicely! Unfortunately, the bitshifts only give me powers of 2 so I can only get octaves when I need integer multiples like 3 and 5 to get the in between harmonics. Still, I might be able to get away with a few phasors with bitshifts to duplicate harmonics like 3 and 6.
For reference, this is what I had before I made this thread.
organ voice 2.axs (11.4 KB)
I'll post the bitshifted phasor version soon.
organ voice 3.axs (14.8 KB)
I think there's a definite optimisation here, but I feel like more could be gained if I could run them all off the same phasor. Would a *i object with overflow be possible? i could be an integer inlet or an attribute (both would be useful for different things).
As a side note, multiplication with saturation causes cool phase distortion. That could be useful for something else...
Having run into the 6 voice limit with 9 sines per voice, I am interested in this topic.
But I don't understand your references to how you use the phasor.. is there something online that could help me?
I made several weeks ago this drawbar-like sine oscillator with 7 harmonics. It could be used for a cheapo organ emulations. Althoug it's not really hammond-like, because the intervals are pure and not tempered. I could make a tempered interval version of it (would be quite easy).
So the phasor is a 'raw' phase accumulator, which is the core of a digital oscillator. It ramps up from 0 to +64 repeatedly. If you look at the math/sin object, you'll see that 0 to +64 corresponds to 0 to 360 degrees of the sine wave. If I multiply the output of the phasor by 2 then it's now effectively going from 0 to +128 (although because of the overflow it basically just counts from 0 to +64 twice for every one input cycle). Either way, it gives a sine an octave above the phasor input. Keep multiplying it by 2 and you get more octaves. If I could multiply by arbitrary numbers like 3 or 5 then I could get all the harmonics from one phasor. As it is I have to use two phasors and a standalone sine oscillator.
No, as noted a few posts back - it saturates. So doubling the phasor's level with the gain object means that the 0 to 32 section of the phasor output is now 0 to 64 and the 32 to 64 section just sits at 64. If you use this signal for sine look up you get phase distortion, which is cool, but not what I'm trying to achieve at the moment.
The method I described requires the overflow to work. The bitshift (<<) object overflows, the gain object saturates.
Watch out for execution order effects, "<<3" should precede the "-1".
Another pitfall with this approach is aliasing, if you shift up with +2 octaves you'll run into aliases when the fundamental pitch is 6kHz or more.
I changed the order but didn't notice any audible difference. (I am in a bit noisy environment.) But this principle does allow for other multiples than powers of two, that was my point.
Also for practical purposes, for an organ patch the 6kHz limit is more than enough.
I made a test with one phasor and nine different sine frequencies derived from there, as stated in http://www.soundonsound.com/sos/nov03/articles/synthsecrets.htm
This with 8 voices of polyphony and a chorus effect use 97% of the CPU.
The execution order is sure to be not optimal but it's an idea?
Until you'd modulate the pitch somehow. Still probably not a huge difference, when the modulation is subtle.
And indeed, 6kHz pitch is pretty high, but if you'd add a third octave that limit becomes 3kHz. Still that's playable, just want to explain where to expect the limits of this approach.
Yes! I feel stupid now for forgetting that I can get 3 by subtracting 1 from 4.
That first bit-shift object isn't doing anything! I doubt it's having much of an impact on CPU usage but it's still a small waste. By the way, the 10th harmonic is +3 +Maj 3rd (harmonic rather than tempered).
It's worth getting into the habit of thinking about execution order from the start of a patch and laying things out accordingly, occasionally it makes a big difference and I spent ages debugging a sequencer patch where it turned out to be the execution order messing things up. Unfortunately good execution order requires you to lay things out in rows. Like you, I used to lay things out in columns because it made more visual sense to me but I've had to get into the habit of rows.
The order can be puzzling sometimes with a lot of connections if it is not even obvioys what should happen before something else. This caused me some trouble when I made my drum machine swing but I moved the suspect around until it worked
I wonder if there is much difference in CPU usage between the - and << objects. Like, would it be better to get six by 2*3 or 8-2, or does it really matter.
Oh and another thing.. the summed signal from the sines is way too hot to make use of the full range of the dials on the mixer. So ideally they should all be attenuated before that stage but I don't think 8 voices is possible in that case? I made a parent patch that has the monophonic noise click and that prevented me from getting 8. (Btw I think I read (possibly in that SOS article) that the click should only happen on the first of overlapping notes? That's not how I made mine because it sounded weird but on the other hand I'm not too familiar with Hammonds.)
Also; any ideas on how to get a Vox Continental sound for my Doors moments?
A general rule is that for an object with two inputs, you'd want both the objects feeding that input to be before that object. In some cases you might want both of them to actually be after that object, but the place where you'd run into problems most is if one of the objects feeding it is before and one is after. That would cause a 16 sample delay for audio rate stuff and a 1 sample delay for k-rate stuff. This is usually the cause of logic glitches and things. I was having trouble with the gate not being synchronised to the note output in a sequencer I made and that turned out to be the culprit. Ever since then, I've always paid attention to execution order from the beginning so that debugging is easier.
Yes, I discovered that too problem too. I included some bitshift >> objects to attenuate the sine waves before sending them to the mixer. I was working on the assumption that a bitshift is cheaper than a *. I think >>3 (cutting the volume to an 8th) was sufficient to allow all drawbars out without clipping.
I was including the click in the voice patch, but that's probably a waste of resources. I'm not sure whether the click should only be on the first note coming out of silence or whether it should be on every note. I've never played a real electro-mechanical Hammond so I'm not sure what behaviour is correct, but I believe the click was caused by the fact that the contacts under the keys were actually part of the audio path and the click is the sound of the switches closing, like the pop you get when plugging a jack in. It's possible you get a louder click on the first note as the mixer inputs would have been floating, whereas a second note joining in would be connecting to the mixer that already has an input.
Hmm, well I think a Vox Continental is simpler in some ways and more complicated in others. They have simpler drawbar selections but two voices ('flute' and 'reed', or sine and square).
I think the architecture goes 16', 8' and 4' drawbars, and then one labelled IV, which contains a predefined mix of 4 high harmonics (I think it includes 2 1/2', 2', 1 3/5' and 1', but don't quote me on that).
There is then a drawbar for the sines and a drawbar for the squares. I think the sines are mixed according to the footage drawbars, as are the squares (but separately). The voice drawbars then control the levels of the sine mix and the square mix.
So... we need to derive 7 harmonics from the phasor and get the sines from them but also get the squares somehow. Dist/inf maybe? I suspect that might start to alias too early for us though. Then there's the elaborate mixing scheme whereby the sine mix and the square mix are controlled from the same drawbars. I suppose the best way to think about that is to have separate mixers for both sine and square and then a mix 2 g for the two.