I’m building a MIDI controller using original Hammond organ manuals and drawbars. How would I go about making a controller based on the MBHP that satisfies the following requirements:
Reads 32 pots and 32 switches, including ones that aren’t momentary contact (the preset keys, etc.)
No LCD
Would I have to make any modifications to MIOS to get this to work? I’ve never done any PIC programming before.
You might also want to post the question under Midification which is an area more specifically focused on adding MIDI to keyboards.
Are you trying to MIDIfy a Hammond keyboard and drawbars or are you trying to MIDIfy a Hammond Organ and still be able to use the tonewheel generators, presets, drawbars, etc.?
If you’re trying to build a Native Instruments B4 controller, then your MIDIbox will need to be able to read the drawbar positions and transmit MIDI controller messages. MIDIbox can easily handle the keyboard encoding but you only need one bus and not the other eight. But I wouldn’t delete or remove the switch contacts because that would lighten the touch a little on the keys. The preset keys on the Hammonds are like radio buttons so you might have issues with switches that aren’t momentary. If I were doing it, I’d remove the latching hardware and install LEDs just above the preset keys to indicate the active preset. You don’t need to have a LCD but it would be simpler if you had one.
You will have to build a MIOS application but Thorsten has made the programming as easy as possible. Several of us have been working on B4 controllers. Perhaps we should get together and establish the specifications for a MIOS MIDIBoxB4 application that is as universal as possible.
I want to build a B4 controller from a single 44-key M3 keyboard and a single set of nine drawbars. The M3 had no presets so I would just use push buttons for the presets. I’d use an LCD display to show the drawbar positions of the presets. When the “B natural” preset is selected the drawbars are the controllers.
If you’re trying to MIDIfy a Hammond Organ, that’s going to be a lot harder to do…
I’m thinking of building a MIDI controller for B4 with Hammond parts, not MIDIfying a working Hammond. I’d like to play jazz organ, so I need two full 61 key manuals and a pedalboard.
As far as the keyboard encoding goes, there is an encoder at http://www.geocities.com/JDPetkov/Hardware/midikeyb/midikeyb.htm that will encode a 61 key manual to MIDI. The PCB design by Vern Jones provides an additional multiplexer to work with busbar-style keying. If I can do the keyboard encoding with MIDIbox alone, without needing an additional encoder, that would be great as well.
Could MIDIbox just see the drawbars as sliding potentiometers, with each additional click of the drawbars adding an additional resistor into the circuit? That’s how it’s done with the B4ce encoder for Hammond at http://www.geocities.com/JDPetkov/Hardware/B4ce/B4ce.htm
That’s a good idea with the presets. I’d also like to have the capability for presets to work as they do on a real Hammond, where the Bb and the B make the organ use the settings on the drawbars and the rest of the preset keys make the organ use presets.
Actually, I’ve been toying with the idea of Semi-MIDIfying an M3. 
Since an M3 has no presets, MIDIBox could very easily add presets by using motorfaders to move the drawbars. The motorfader pot would only be used by MIDIBox for drawbar positioning; the harmonics would still be set by the drawbar contacts themselves.
Classical organ combination actions are usually triggered by thumb studs under each manual instead of the “radio button latching keyboard” method used by Hammond. So, I would just add an arrangement of black and white buttons with LEDs just under the last octave of each manual. When a preset button is pressed, the drawbars move to their stored position and the LED above the thumb stud lights. To store a new position, simply move the drawbars as you wish, press another button to tell MIDIBox that you’re storing a new preset and press the appropriate preset button to store that drawbar position to that button.
Thousands of tonewheel organ owners wish that could be added to their organs. :D
Press the button under the bottom C and the motorfaders pull all the drawbars to zero. This is as close to the cancel key as I can dream up. The high B and A#would be special presets that MIDIBox would store automatically any time another preset were selected. When the B or A# is pressed, the drawbars return to the last position they were in when another preset was selected (for the ultimate in reality, you could wire up the percussion button to automatically turn off when using any preset other than B… :
). That is the closest thing I can imagine on an M3 to the B3’s presets without major work…
Thorsten has indicated that the motorfaders move very, very fast. ;D
I’ve seen Petkov’s stuff. MIDIBox is superior in flexibility, power and FREE (well as close to free as it gets…) Look at the advanced applications for MIDIBox, in contrast, a B4 controller is child’s play…
A digital input multiplexer is a standard part of the MIOS system. Up to 128 inputs are possible without too much effort other than additional PCBs. More than 128 inputs are possible by multiplexing the multiplexed lines (if you know what I mean) but you’d have to do the programming and it would be a rather non-standard implementation. For reasons I’ll expain below, I’d stick with the standard.
Using the drawbars as they are in the Hammond is certainly possible. As I understand the B4, it is looking for MIDI controller messages that are linear and are not tied to the 9 drawbar positions ( 0 - 8 ) since most MIDI controllers have strictly linear slide pots and not drawbars. MIDIBox should be able to let you set certain resistance points in reading the drawbars to equal MIDI controller messages but you might have to do some coding to make it happen. I have a set of M3 drawbars in front of me and I don’t know whether to stick with all those contacts designed to directly attenuate analog audio signals or just strip the drawbar and knob and attach them to a 10k slide pot like MIOS expects…
You should look at the pipe organ messages in this Forum section. They need to use multiple cores in their MIDIfication and I think you will too. First of all, you need more than 128 inputs. Just for the keys alone, you need 61+61+25 = 147. Then you need inputs for percussion switches, vibrato, the presets, etc. Then there are number of B4 controls that would work great as encoders, instead of pots (i.e. Amplifier Drive, Leslie Acceleration, etc.). Encoders use two digital inputs each. Finally, I believe that B4 is expecting the manuals and pedal are on individual MIDI channels (i.e. Upper on Channel 1, Lower on Channel 2 and Pedals on Channel 3, etc.) which would be easier done on a core by core basis.
Here’s how I’d do it. One core for the Swell, one for the Great and one for the pedal clavier. A kit in the US is $25 a core, not including shipping. The software needs to be developed, of course. The basic MIOS B4 application would be designed to work as nearly as possible the same way on each core. The cores are easily connected together and one MIDI Out to your PC running B4. The first 61 inputs on each core are the keyboard inputs (yes, that means you could have a 61 key pedal board but consistency is really good…). The next 12 inputs are the presets, then the remaining inputs like vibrato, Leslie on-off, etc. The first nine analog inputs would be the drawbars, then the swell (it’s gotta be in there somewhere…), etc. You should provide for using either pots or encoders for some of the B4 functions like Leslie speed, amplifier drive, etc. Remember that B4 has presets, but so can your MIDIBox controller. Encoders are generally considered more desirable than pots because no matter what value is stored in your MIDIBox preset, the encoder can be turned up or down without worrying about the end of rotation.
Another reason to use a single core per manual is some folks, (like me!) want to just do a single manual controller for B4. If we get a one manual MIDIBoxB4 working, the other two are easy! To further mix things up, I’m also trying to control the weak implementation of a drawbar organ in some models of Yamaha’s digital pianos (they omit the 1 3/5’ drawbar which is badly out of tune in a Hammond anyway and add some extra percussion features that I wish a Hammond had…) If we (and there are a couple more of us looking at building a B4 controller) line out a standard for ins/outs, etc., then oddballs like my Yamaha application are actually easier.
Now that I look closer at the B4 controls I’ve altered my thoughts a little. The swell or upper keyboard is the minimum B4 implementation and it includes all the functions that may be shared by all the manuals, vibrato, the presets, amplifier and rotary settings, etc. Only one more core is needed to add the great or lower keyboard and the pedals and their drawbars.
Note that B4 expects that the MIDI control message will be the following for each drawbar position:
Drawbar Hex
0 00
1 0A
2 1E
3 2D
4 3C
5 4E
6 63
7 72
8 7F
So to use standard Hammond drawbars, MIDIBox would have to read the analog resistance of the drawbar and convert that resistance to one of the nine hex numbers above for B4 to recognize the drawbar position.
Hi folks. So the project MidiBoxB4 is getting started ?
@Jim: I would skip the idea of using motor faders. Reason: You would have to sync the movement of the motor fader to the movement of the drawbar (db): You have 128 steps for one controller. if the db is moved for one position it means an increasement of the midi controller value of 16 (decimal). With the fader moving for an midi value increment of 16 this length must be fitting to your db. Might be a difficult thing to do.
I will use LEDs indicating db position instead. The same way as the guys from Clavia used the LEDs on the Clavia Nord Electro: Take a look.
http://www.clavia.se/pictures/nordelectro/NE2drawabarsLarge.jpg
But I need some more LEDs.
24 x 8 LEDs for the db
4 LEDs for Drive , Percussion, 2x Vibrato
6 LEDs for Chorus Vibrato Selector
10 LEDs for Bank Select Indication
9 LEDs for Harmonic Selector
24 LEDs for Preset Selection
3 LEDs as Leslie speed indication
That makes 248 LEDs. ;D Just timemultiplex them and everything will be fine.
Encoders for the other features would be fine. But I think that I don’t need them. I think I only need the drive section and the Vibrato Selection to change live on the fly. All other features of the B4 will be saved in presets.
But that doesn’t mean we should skip the code for all the others features: I would suggest we code an full featured implementation of the B4 and while building your box leave out all the things you don’t need.
Feature list:
61 switches for upper keyboard
61 switches for lower keyboard
25 switches for pedal
24 switches for Preset Keys
6 switches for Drive, Percussion, 2x Vibrato, Rotator, Velocity (I think we could just skip the last 2 switches I won’t turn the Rotator Off or the Veloctiy On, but who knows)
10 position switch for Bank Select
9 Position switch for Harmonic Select (could be solved as 25th drawbar instead, what do you think?)
6 position switch for Chorus Vibrato Selector (Keyboard View)
24 analog inputs for the db
2 Encoders for Percussion volume and decay
2 Encoders for Vibrato mix and depth
1 Encoders for keyboard click
4 Encoders for drive section
8 Encoders for rotor section
4 Encoders for microphone section
1 analog input (volume pedal) for swell (the length of the connection calbe might become a problem as T.K. mentioned in one thread that they shoulln’t get too long)
3 position switch for the Halfmoon Leslie
Yes, I would like to have a 3 position switch in order to add something the guys from N.I. didn’t think of: Leslie Brake. This can be achieved by setting both rotor slow controller values to zero. Shouldn’t be a problem at all.
So we need 205 switches (digital inputs) 25 analog inputs and 21 digital inputs for the encoders. That could ask too much of one single core, what do you think? ;)
Thus, 248 digital outputs for the LEDs. (Which could archieved by 4 multiplexed DOUT Modules
Ah, to add just another thing. It could be possible to indicate midi value of the encoders with LED rings ass well. I don’t need it. Whats up with you, guys ?
So. Writing that all took a lot of time (especially when you’re not a native english speaker/writer). Hope to read from you soon).
Best
andreas
Andreas,
I am very, very grateful to all to whom English is not their native language for taking the time on this forum to use English. There is not one of us to whom English IS their native language who has not struggled with its weird spelling, awkward grammar and seeming endless tendency to steal words from other languages. Your English, Andreas, is excellent.
I’ll answer your message in more detail later tonight. I may still toy with the idea of the motorfaders later but not for MIDIBoxB4. For one thing, 24 drawbars would require a minimum of three cores.
I think two cores will work just fine for a full implementation. Organized properly, one core will handle a single keyboard and two cores will handle two manuals and the pedals. I guess if you do want LED rings, then additional output multiplexing will be needed. The LCD display will show the encoder position any way and I don’t see microphone position, accel speeds, etc. as really needing LED rings. I agree the LED drawbar indicators are really desirable (like the Nord), but the drawbar positions could also be shown on the LCD display so they’re not really manditory either.
More later.
Thanks for the compliment regarding my english. I really appreciate it.
"I’ll answer your message in more detail later tonight. I may still toy with the idea of the motorfaders later but not for MIDIBoxB4. For one thing, 24 drawbars would require a minimum of three cores. "
You mean 3 cores are needed if motor fader are used, right ?
That is true.
@LEDs: I don’t need LED rings for the encoders either. A LCD displaying drawbarsettings will be fine aswell, but I’d like to have those LEDs cause I’m planning to use the MidiBoxB4 on stage and I’d like to “see what I get”.
@one core for 2nd keyboard and pedal:
I searched the archiv and found the old post (it was in the german section). “Spanky” was asking about the max cable length between core and devices like switches or pots etc. Thorsten said everything longer 1m (3 feet) might get critical. “Spanky” tried it out with a cable of 3 meter (10 feet) (only switches were connected) and it worked well, so it looks like this problem is solved too.
Since some time I’m thinking of adding a second db set for the upper manual (like the big Hammonds have) with a button (not one of the preset keys, an additional key) to switch between the two sets.
Programming all the stuff in MIOS could become a problem. But I think if we’re all working together it shoulnd’t be a problem at all. Just in case we’re stuck, I know a good forum to post our problems ;)
Take care
andreas
I wanted to clear one item up. As far as I know, B4 does not report back to the controller the position of the drawbars for their internal presets. If you select a B4 preset from your keyboard controller, only the drawbars on the computer monitor will move. If you want your keyboard LED “drawbars” to “move” to the same positions in the B4 software, you will have to “hard code” them into MIDIBoxB4. When you create your own presets in B4, you’ll also have to program MIDIBoxB4 to match the preset.
Or, you could ignore the B4 presets completely and just use MIDIBoxB4 to store and recall the presets and simply issue the drawbar positions to B4 when each new MIDIBoxB4 preset is selected. B4 would act only as the sound engine.
Does this make sense?
Hi everyone (Andreas, thank you very much for letting me know about this thread)
You can add me too in the MB64-B4 project. I have almost finished the whole MB64 circuit and I am in the stage of designing the case before soldering the pots and the drawbars (I am using actual drawbars, borrowed the idea form Andreas - borntob4). 
After reading the thread, I agree with Andreas that the MB64 - B4 application must be designed so as to fully cover the controls of the b4 software. Upon the realisation of the I have a suggestion to make derived from my own experience with my b-4 project.: I am going to to incorporate to my project only the controls of the B4 panel - NOT the manuals (I will be using two Roland 76-key Keybords for the 2 manuals and will later at some point buy or build a midi pedal). In order to achieve full b4 panel control PLUS control for the bass pedal only one MB64 (one core) is needed. If one wants to midify 2 manuals (e.g. two Hammond manuals) then the most appropriate platform for achieving this is the MB128 . Every key will need to be connected to a digital input. So in order to connect 2 manuals one one needs 61 + 61 = 122 digital inputs. The MB128 has 128 digital inputs, so you can connect 2 manuals and have 6 more digital inputs to use for somenting else (e.g. 1 rotary encoder for prgr change and the 4 menu buttons).
So I would suggest if one makes a MIOS B4 application, the entire panel control should be designed for one core (one MB 64). If one wants to midify 2 manuals this is already achieveable by using the MB128 and program it to send just midi note on messages when the keys connected are pressed and midi note off messages when the keys are not pressed. To summarize, full B4 control can be achieved with MB platforms this way
1 x MB128: the 2 manuals only
1 x MB64: Everything else
One more thing: about the multiplexed LEDs idea, I think that this cannot be done with the current MB64 firmware because the LEDs are designed to respond to the digital in functions and NOT to external messages (I hope I am wrong). If it could be possible to alter that, then I think that the 64 Digital outputs of the MB64 are enough for thsi job
I hope we make something good out of this exchange of experiences!!
Best regards
Dimitris
I don’t need anything fancy at all. Just something that will read the drawbars and the expression pedal and the other various switches on the organ.
I think we don’t need quite so many LEDs. It’s an organ, after all, and I’d like to use this to make something that feels like a Hammond. You don’t need LEDs to show where the drawbars are. As for the rotating encoders, I’d much rather have regular pots so I can feel where they are without having to look.
The presets should be stored in the MIDIBox itself so I can have the same presets no matter which computer I use the organ with.
For the time being, I think I’m just going to build two 64-key keyboard encoders for the manuals and 2 MIDIBox Plus modules to use for the drawbars.
Now the discussion is going on. Let me see.
First of all.
@Jim: “As far as I know, B4 does not report back to the controller the position of the drawbars for their internal presets.”
Fortunately you’re wrong. As I know from the Keyboards forum (german keyboards magazine) and just tested myself (I hooked the B4 to a MIDI monitor of my MIDITEMP PM-88E (a midimerger and midimatrix)) the B4 reports every MIDI-event to the MIDI-Out of your soundcard (which can be connected to the In-Port of the Core) and therefore it is possible to let N.I. B4 controll the LEDs.
@Dimitris: With your MB64 beeing ready you might be done. All you wanted were those drawbars, switches and pots. You only have to configure your box and your done. Or am I wrong. Flash the MB64 software to your core and link the events to your input devices with serge’s editor and go B4ing.
@oldmacman: first of all welcome to the project.
Your right, it’s only an organ, but I made some expierence with a Hammond XB-2 (digital clone) in a rock cover band. In a band you often have thousands of sounds that are linked to special songs or even certain parts of songs. Using the presets gives you no controll of your settings (no display except the screen). the XB-2 had a small display indicating your drawbar settings after using a preset key. that was crappy, because it was a little bit tiney and you had no idea if you have choosen the right presets. With LEDs indicating your settings you “see what you’re getting/hearing”. If I wouldn’t need the LEDs - to be honest- I think I would go and buy JD Pedkov’s circuit:
http://www.geocities.com/JDPetkov/Hardware/B4ce/B4ce.htm
That would save time (=money) (I know you guys living in the U.S. wouldn’t think of it because of the shipping costs).
@all: I think the project should be organized this way:
Core 1: handling the upper manual and everything else besides lower manual and pedal clavier
That makes 119 switches, 25 analog inputs (db and swell pedal) and 21 digital inputs (question is still: do we need encoders. I’m not shure. Maybe pots are enough. Using pots would simplify the amplication, I would say.)
Plus the LED (in my opinion/case). As I mentioned before we just talking about all the things to add for programming. Oldmacman, in case you don’t like the LEDs (it’s also a matter of money, LEDs are expensive and I have no idea how to integrate them to the cabinet) leave them and the DOUT-PCBs out.
And one core is able to do it (see MIOS specs).
Core 2: based on MIDIO128 handling lower manual and pedal board
It’s getting late. Hope to read from you soon.
Best
andreas
Dimitris has a good point that not everyone is going to also encode a keyboard. Many just want a drawbar controller to support a MIDI keyboard controller (or two). I agree that one MB64 app be used for the control functions and one MB128 app be used for keyboard encoding. But, a full Hammond implementation of 2 61 key manuals and 1 25 key pedal clavier would be more than 128 inputs…
I think that the first core should not only support the controls but a least one keyboard as well. Andreas, the published specs for MB64 indicate that “up to 64 Push-Buttons” are supported. So it would appear that, without recoding MB64, it couldn’t support a 61 note manual and everything else we want to do. MB64 also won’t give Andreas enough outputs for the LED drawbars…
How about this idea? As Dimitris suggests, all B4 controls, other than manual keyboard scanning and LED drawbar indicators are handled in the first core. There should be enough digital inputs left (Dimitris, is this correct?) in MB64 to encode the 25 pedals. This will allow someone to build DIY pedals to use with two MIDI keyboard controllers and the B4 controls. The drawbar positions can be displayed on the LCD.
To encode the two 61 key manuals and/or display the drawbar positions as LEDs. MB128 will be used as the second core. I’m very glad to hear, Andreas, that B4 sends the controller settings out when the presets are selected. That makes things much easier.
So, Dimitris, have you established your I/O assignments? How do you have the analog inputs, digital outputs, etc. connected to MB64?
Andreas, at current exchange rates, Petkov’s PCB costs $190 US plus shipping. I’ll stick with SmashTV’s prices and far cheaper shipping… Also, I think with all of us working together, we’ll get a better product. Because I have a MIDI keyboard controller I’m tempted to follow along behind Dimitris and get the control stuff working before I tackle my keyboard. From what I read about MB128, it should be very, very easy to encode your keyboard and drive the drawbar LEDs.
Jim
@Jim:“How about this idea? As Dimitris suggests, all B4 controls, other than manual keyboard scanning and LED drawbar indicators are handled in the first core. There should be enough digital inputs left (Dimitris, is this correct?) in MB64 to encode the 25 pedals.”
Nope, that doesn’t work out. We need 58 switches for the console keys including presets. MB64 supports only 64 switches. But we need 83 for adding pedal switches to the function switches. But we could use analog inputs for Bank Select and Precussion Harmonic Select (e.g. analog pot. rather than switch input). That would save 19 switches and it would work.
" Andreas, at current exchange rates, Petkov’s PCB costs $190 US plus shipping. I’ll stick with SmashTV’s prices and far cheaper shipping… Also, I think with all of us working together, we’ll get a better product. "
I fully agree with you. While working all togeher we can develop a more powerful circuit than JDPedkov’s.
Later more from me
andreas
Dimitirs’ suggestion is good and easy to do. If the length of the cable from core to bass pedal dosn’t get too long (sub-d-25 pins cable could be used) it might work out.
If it doesn’t, never mind. It wouldn’t kill your budget to use 3 core for the project (one additional for the pedal bass).
But we don’t need to work further on because (as far as I understood the MB64) everything is already prepared and has only to be configured with “serge’s editor”. Same with MIDIO128 for all of us who like to have keyboards. Only the LED-thing has to be coded. >:(
Best
andreas
Hello everyone
I am very glad this discussion is growing
Jim I have not yet connected anyhting to the MB circuit. I have just completed (almost) all the soldering of the components on the PCB, so I am now at the process of designing the actual case of the controller (I think I ll make it out of wood - it adds a more “vintage” touch) and afterwards I will connect the pots and buttons. It is more convenient this way, since, after you have the housing of the project ready, you can calculate more accurately the length of the cables, where you want your PCB to be screwed on etc. I had actually made a desing for my case, when I bumped on this B4 discussion, so I have started making alterations. The most important one is the use of real drawbars like Andreas is doing.
Andreas (and everypone), I think you don’ t need 58 digital inputs. If you look at the B4 midi implementaion chart (if one does not have it I ll be glad to send it via e-mail), only 6 of the controls require a “push button”. The other controls can all be analog (potentiometers). In addition, you don’ t really need switches for the presets, one can program manually some 20 presets and store them to the midibox memory (Bankstick). The only thing that is needed is a rotary encoder for selecting fast every B4 software preset (I think there are about 128 presets). The rotary encoder will be programmed to send prgr. chage + and prgr change - messages to the B4 software, so that with 3-4 turns or so of the encoder, you will be able to jump from preset one to preset 128. A rotary encoder only needs 2 digital ins. With the addition of the 4 menu buttons this is a total of 6+2+4= 12 digital inputs needed. The rest 52 digital inputs are sufficient for connecting a bass pedal board (unfortunateluy not a manual keyboard).
Thus I think that a full B4 control device is possible with only one core!!
Still I don’t get how one can use the 240+ multiplexed LEDs, since the LEDS
of the MIDIBox are not programmed to respond to analog in values, they
respond only to digital in values. So the only way to have LED bargraphs the
way Andreas intends is to use Rotary encoders connected to the digital ins of the
MB64 or MB128. But this way it will not be posiible to use real drawbars 
What I am saying is this: Even if one can achieve to program the MB simware as to set the multiplexed LED bargraphs to respond to the control messages receivedby the MB midi in, the problem will be that if real drawbars are connected to the analog inputs (like me and Andreas are going to do) then the move of the drawbars wll not alter the indications of the bargraphs in real time. (Again I really hope I am completely wrong, but this is the impression I have -I really want to have LED bargraphs).
Anyway I guess it will be also difficult to program the multiplexing, so as to fit all those leds into a one core project - I do not have any programming experience myself!
Best regards
Dimitris
@Hermes: "Thus I think that a full B4 control device is possible with only one core!! "
Yep, needs some coding though. You have to add 64 analog inputs to MIDIO128.
@Hermes: "I think you don’ t need 58 digital inputs. If you look at the B4 midi implementaion chart (if one does not have it I ll be glad to send it via e-mail), only 6 of the controls require a “push button”.
That’s true aswell. But there is one problem: chorus vibrato selector in the keyboard view. This switch is not listed in the midi implementaion chart. But it could be recoded using an analog 6 position switch and defining the two midicontroller (vibrato mix and depth) to each position. But this switch must be hooked to 6 digital inputs on order to add this “second output” (2nd midicontroller). For example C1 woul be 64 (mix) and 32 (depth), V3 would be 127 (mix) and 96 (depth). I would like to have this switch (and I think oldmacman aswell) to be as close B3 as it’s possible to be. Coding will be needed aswell.
@LEDs: I think I have bad news. I don’t think that Hermes is describing a problem, but I didn’t check it though.
But what I found out is that B4 doesn’t send controller data when a preset key is pressed. It only sends program change. And therefore it is not possible to indicate a drawbar setting called by preset changes. :'(
And without this: I don’t need LEDs. If the LEDs are only able to indicate the real drawbar setting (which I see anyway on my organ) I don’t think why we should keep them.
Disappointed I’ m going to bed and whimper for a little while
andreas
Yeah, Petkov’s project is really expensive. I’m in the US, and it would cost $170 plus shipping just for the PC boards and PIC for the B4ce and two keyboard multiplexers.
Is it possible to alter the firmware to make it possible to use non-momentary-action switches? That way, the presets would work right, the original rocker switches for percussion, vibrato, etc. could be used, and the Leslie switch could actually be thrown. I’d like to use a house wiring on/off switch for the Leslie so I can hit it with my knee or something.
I think it’s a good idea to put drawbars/switches/etc. in a separate assembly from the keyboard encoder. That way, people can use the MIDIBoxB4 with MIDI keyboards they already have.
