RVBottomly

You are flying along, Tony. I can't keep up with your posts. You asked about "reit." On the Baldwin it is a control for how fast some percussive features repeat. For example, the marimba stop sounds like repeated mallet blows are hitting the blocks. Reit controls the rate of the repetition (or reiteration). Same thing for some other percussion effects. On my Cinema II, turning the reit clockwise increased the rate. I hardly used it, myself, but that's what it is.

Thanks for the kind offer, Tony. Happily, my old organ came with the owner's manual and a service manual with complete schematics. It's been quite helpful in identifying the circuits. The service manual was also very interesting to read because it provides fairly detailed description of the various theories of operation.

Tony, I should have added something I just remembered: some people have configured jOrgan to use program change MIDI messages to control stops. That is different from Miditzer. If you go the program change route, then the momentary switch approach is probably the one to take.

Tony, on the stop tab question, I don't think the non-momentary aspect is a big deal. Looking at the documentation on the midio128.ini file, it looks like control change signals contemplate on/off--just like keys. I know that those signals have been used to control stop tabs in Miditzer, and I think so in jOrgan too, but I haven't dealved into it. From the midio128.ini intro: So the example codes given later, like "65 = B0 10 7F B0 10 00 @OnOff" can be used to control stops. I agree that using pistons would mess up the stop tabs after they are cancelled, but on the Miditzer forum the simple work around is to just flip the tabs up and back down again (or rig up some sort of reset switch that tricks the computer into thinking the tabs have been set up and down). It seems a lot easier using the existing tabs. That's the route I'm following, but I've only now gotten to the point to try out the idea. If you go for momentary switches for the stops, you probably are going to have to figure out how to tell the computer that the stop is remaining on. I understand that pistons use "program change" signals, but stops don't. The other alternative is some sort of latching switch or feedback loop to keep the LEDs on and the stop active--but that is already there with the toggling tab switches. As I said, I'm a bit behind you in progress on my Baldwin, but from my reading it looks like you have a few basic choices with physical stops: use existing tabs and control change messages, or make your own stops that send control change messages. Pistons can be used with the knowledge that when they are used, the physical stop settings are not necessarily valid unless reset. Otherwise, people just use a touch screen monitor and pistons.

Thanks, Tony. I lost my internet connection last night so I didn't see your latest note. But at your suggestion to locate another application I found Serge's Sysex Loader from the ucapps website: Sysex Loader It worked like a dream. I've got both my cores loaded with my edited .ini files.

I’m working with the Midio128. Have a Midibox Core and 4 DINS working. Right now I can see through Midi-Ox that it sends note on/off signals when I ground the various data terminals on the DIN. My problem is that I cannot get an edited midio128.ini file to work. I run the perl script to get the appropriate .syx file, it seems to load fine using midi-ox, but the changes do not "take." For example, right now, if I ground D0, the signal is to turn on note 30 (C below middle C). I wanted to see if I could assign a different note to that pin (in this case, hex note 24) so that it would turn on the C an octave lower. I edited the .ini file to make pins 1 through 3 turn on different notes. I ran the perl script and derived a .syx file. It loaded into midi-ox fine. I confirmed the edited changes were present when I look at the 2-digit codes displayed in the SysEx View window. I click “send sysex file†and it seemed to be sent to the midibox. The midi-ox output monitor displayed the 2-digit codes as they loaded. They corresponded to the edited changes I made to the .ini file. So I go back to grounding pins 1, 2, and 3, and midi-ox tells me that notes 30, 31, and 32 are being sent. Sure enough, fire up my organ emulator (Miditzer), and C below middle C plays, then C#, then D. Midi-ox shows that notes 30, 31, 32 are being sent, not the ones I put in the edited .ini file. It's as if I uploaded a .syx file from an unedited sample midio128.ini all over again. But, after thinking about it last night, I'm wondering if a boneheaded move on my part messed up the PIC. Initially, I followed the procedures in the "Midio Mysteries Revealed" and the documentation at ucapps exactly, going all the way to running the perl mk_midio128_syx.pl midio128.ini script. There were no error messages and I was starting to get excited. So I started Midi-Ox, configured everything as directed and then followed the "load the generated .syx file and transfer it to MIDIbox " step. Except that when I clicked the send sysex button, the only file shown to send was "mk_midio128_syx." Without even a second thought, I sent that file to the midibox. It looked like a file was transfering but no data seemed to be showing. Immediately I realized the stupid mistake. I tried loading the midio128.syx file (it was in a subdirectory) and it loaded fine. Grounding the pins played notes, and Midi-Ox indicated that signals were being generated just fine. I figured my stupid move was harmless. Now I'm not so sure because I cannot seem to get the .syx file generated from an edited .ini file to assign pins as I want. Do you suppose I fried my PIC so that the default configuration is permanent?

Maybe you are thinking about "velocity?" Most piano-type keyboards have some way of measuring how fast the keys are depressed to regulate the loudness of the sound played. This mimics a standard piano: the faster and harder the key is played, the louder the note. This is different from second touch on a theatre organ. Velocity is fine for keyboard playing, especially if you want the response to be like a piano, but is not typical for an organ. Second touch is for activating a different set of stops when you push harder on the keys. From Wiki: Electronic keyboard

Tony, I notice you are flying through the keyboards and talking about second touch. I don't have any specs, but I do know that second touch usually requires an extra spring beneath the keys to provide a tactile resistance point. The idea is that normal playing with normal pressure will push the key down to a first stopping point. Second touch requires extra pressure to push beyond that point to activate the second touch contacts. You might want to keep this in mind as you progress. Without the extra spring (or some other form of resistance--maybe padding of some kind), it will be too easy to hit the second touch notes inadvertently.

Hey, Tony, I think I found this thread too late, but I wanted to ask you if your organ had percussion. The reason I ask is that I own a Baldwin 214DR that has similar key contacts to yours. Wherever the contacts control stops, there is an elastomer pad with resistance. But, for the percussion controls, there is a silver rail that the wire touches. On my organ, there are two silver rails, the top one and the one beneath it. Beneath those are the elastomers. If there is the silver rail, there is no need to strip out the elastomer and put in a new wire. Just use the silver rail--it has zero resistance. On mine, I didn't even have to remove the contact boards. I just bypassed the resistors and used the existing wiring (it's color-coded by note for each octave). You are farther along than I am, but I thought I'd try to bring this up in case other people are working on Baldwins.