But how high is your Note On ?
If the midi keyboard don’t have an organ mode where the mire on is on the first switch touched, you may trick by midi rules sometimes. Activating “percussion mode” or so
… Or hack the keyboard. The midibox project have a keyboard variant.
If it were possible to build a keyboard with effective and consistent Hall effect then these curious side-effects could be emulated, especially with a MIDI 2.0 enabled link (both keyboard and synth engine). You could possibly detect the amount of key press and send an appropriate note-on + velocity which the synth engine could interpret to sound some of the tone wheels. Changing the key position could send another note-on with a different velocity, triggering different quantity of tone wheels. You may be able to get both the fast action from light touch and the variable (computed randomness) quantity of tone wheels based on light touch pressure - not the traditional synth action aftertouch that occurs when pressing hard on the key but instead, variation at the very top of the key press. This is very much emulating design flaws but as described in the Hammond manual, this is a desirable defect.
Of course, the synth engine also needs to be modified - but that is within our gift! setBfree is open source and eminently hackable. And it could possibly be done in a way that does not require configuration, e.g. using low value velocity settings that are unlikely to be produced by normal playing and may allow for some interesting new effects even with traditional synth action keyboards.
Returning to the original post - the B3 (which setBfree mimics) does not have velocity control but it does have (by happy accident) a flaw that sounds fewer tone wheels (still at full audio level) if touched lightly which is a pseudo velocity.
None of this is available out-of-the-box and it seems that (almost?) all existing MIDI controllers are unsuitable. It also seems unlikely that anyone will build an affordable version of such a keyboard, given the complexity of design and construction and the small potential custom base. Once you move to the high-priced end of the market then you may as well spend the money on the real thing. Hammond are again producing these pieces of furniture. (I have seen the challenges of transporting a real B3 & Leslie cabinet. It makes a drummer’s life look easy!)
People keep posting electronic links in this post but the biggest challenge is mechanical. The electronics and the code is (relatively) simple.
[Edit] I have started a thread here with some of my ideas in which I reference someone’s efforts detailed here to implement a Hall effect keyboard. This could be a real prospect for the DIY hacker. I certainly have some keyboards sitting idle that could be enhanced by such an add-on.
I have a very nice Pratt-Read keyboard which came with my Aries synthesizer kit; I believe it was intended for use with an organ originally. When I sold the synth modules, it seemed a shame to waste the keyboard so I took it apart and rebuilt it into a MIDI keyboard that could be used with all my other stuff.
The key system was made so that there was one “upper” bus, one “lower” bus and a connection for each key. The individual keys were attached to a small gold-plated spring; it normally rested against the upper bus, and pressing a key bent the spring so that its contact moved from the upper to the lower bus.
After some experimentation, I was able to determine that there was a sizable interval between break and make which I could use to determine key velocity. Using a microprocessor and some digital logic, I scanned through the keys and marked each one as one of four states: up, down, going down, coming up - a simple state machine. Without going into petty details, it was easy to track the state of each key and the velocity with which it was pressed (or released!) so those could be sent as MIDI messages. It has quite a bit of range and I was able to get almost the full 0-255 velocity values.
I never attempted to send a message when only the upper contact was broken, but if I wanted to emulate the behavior of an organ keyboard this would probably have been the way to do it since the breaking of the upper contact required less pressure than a full depression of the key.
I don’t know if this style of keyboard is still easy to obtain, but for anyone who wants to pursue this it might be worth experimenting with to see if it’s possible to have a keyboard with “organ” mode as well as standard “synth” or “piano” mode.
That is how my first (still unfinished) keyboard project worked. As you say, the time interval between the break and make contacts gives the data to deduce note on & note off velocity. Note that there are 127 values for velocity. (Note-on value = 0 is reserved for note-off and offers the ability to use running status for both note on and off but without note-off velocity.)
IR distance sensors also looks like a good way to go. I think the Kioshi Piano Silent System uses them. Here’s an interesting installation guide video https://youtu.be/7Z2kU3nbtm8?feature=shared
That’s right - I don’t remember how I scaled the raw values but it surely ended up with 0-127 being sent out over MIDI. Otherwise it would have behaved strangely. I have a series of presets for the velocity curve as well, in case one felt better than another for a particular device. It could be varied from exponential to linear to logarithmic with a thumbwheel switch.
I know it’s a lot to ask, but could you give us the average depth you have to depress a key to get the ‘top break’ in millimeters with whatever precision you can easily achieve?
Do any of our readers own a real Hammond B3 (or similar) organ? I am interested to hear how close setBfree emulation is, particularly when changing drawbar settings from zero to one. There is a noticable click if you hold a note then add a drawbar (changing from zero) which I suspect to be a lack of soft fade, i.e. the new tonewheel sound is added at whatever point in the cycle it happens to be, with the resulting discontinuity and click. Does the analogue circuitry in a real B3 avoid such clicks?
Maybe I am being too optomistic to think this collection of zynthian users may have such a large piece of furniture in their studio and I may need to go in search of the real thing out in the wild but I am not sure that an owner of such a beast will let me twiddle with their drawbars whilst listening for clicks!
I find the click rather disturbing so may consider modifying the source code to remove it but, seetBfree tries to emulate the B3, warts and all, so such an change may be unwelcome.
Real B3 organs are notorious for their lack of debouncing on all sorts of things. Most notibly pressing a key itself as it has a contact for each drawbar under the key. So a click from opening a drawbar wouldn’t surprise me. This is additional to the “percussion” setting that utilises the top drawbar for an impulse sound when you press a key.
It’s what B3 owners describe as the organs charactor.
Later organs, like the T- series did add a bunch of circuitry to eliminate clicks and pops and are considerd ‘sterile’ in comparison. Proving you can’t win.
Ohh, but the click is lovely. It’s part of B3’s sound and setBfree emulates It quite nicely. Anyway, you don’t need to modify the code. This and many other features can be adjusted via config file.
Regards
I do not find any mention of a configuration that will avoid clicks when changing tonewhee from 0 to 1. @jofemodo can you tell us what that config is? Understand that I am not talking about the optional percussion sound. I am talking about the click when switching drawbar settings whilst holding a note.
Everything you never wanted to know about drawbars.
You ‘should’ be hearing a click at every indent if it’s emulating the break-before-make drawbars. Sounds like it needs more clicks.
Try setting
#osc.attack.model=click
To
osc.attack.model=linear
I think that relates to the note attack (maybe percussion) rather than drawbar which sounds similarly splatty with both settings. FYI these settings need to be changed in /zynthian/config/setbfree/zynthian.cfg
because zynthian overwrites configuration when it starts setBfree, using this file as its template.
It’s absolutely not percussion. That’s noted in the config file.
## --- PERCUSSION ---
##
## Fast percussion decay time in seconds.
##
#osc.perc.fast=1.0
##
##
## Slow percussion decay time in seconds.
##
#osc.perc.slow=4.0
##
##
## Basic volume of the percussion signal, applies to both normal and soft.
##
#osc.perc.gain=3.0
##
##
## Normal percussion amplification
##
#osc.perc.normal=1.0
##
##
## Soft percussion amplification
##
#osc.perc.soft=0.5012
##
##
## Percussion signal bus select. Selects the signal buses used for
## second (a) and third (b) percussion sounds. Accepted values 0-8.
##
#osc.perc.bus.a=3
#osc.perc.bus.b=4
##
##
## Percussion trigger bus select. Selects the bus to be muted when
## percussion is enabled. Accepted values 0-8 and -1 to disable (no
## bus is muted by percussion).
##
#osc.perc.bus.trig=8
##
##
vs
## --- KEY CONTACT ARTIFACTS (KEY CLICK) ---
##
## These parameters selects the models applied during attack and release.
## The recognized values are:
## click several random contact bounces
## shelf debounced on/off transition, randomized in time
## cosine sine-based fade in/out envelope
## linear linear fade in/out envelope
##
#osc.attack.model=click
#osc.release.model=linear
##
##
## The amount of random attenuation applied to a closing bus-oscillator
## connection. Applies to click, range (0 ... 1), larger values gives
## more noise.
##
#osc.attack.click.level=0.5
##
##
## The minimum length of a key-click noise burst, in terms of the available
## unit. 1.0 corresponds roughly to 5.87 ms.
##
#osc.attack.click.minlength=0.1;
##
##
## The maximum length of a key-click noise burst, in terms of the available
## unit. 1.0 corresponds roughly to 5.87 ms.
##
#osc.attack.click.maxlength=0.5;
##
##
## The amount of random attenuation applied to an opening bus-oscillator
## connection (release).
##
#osc.release.click.level=0.25
The reason why i suggested it is because it’s possible that opening a drawbar might effectively act as a keypress and follow the same code path.