Per S

Jim, The MIDIO128 doesn’t send anything during power on. It does capture the switch status though. Thorsten explained this in another post. I can live with these restrictions. After all it is a DIY project and as such there are some shortcomings. If I paid $$$ for commercial stuff such a behavior would be unacceptable. Question to Thorsten: How complicated would it be to send out the initial DIN status upon power on? Comment on the crescendo function. There is a function in the MIDIO128 called the Meta Handler (midio_meta.inc). It’s triggered by an 0xF0 instead of Note On or similar. There you can send out as many MIDI events as you like with one DIN. Per S

Jim, Interesting information about your swell function. I have done some experiments with the MIDIO128 and the AIN function and the MIOS_AIN_DeadbandSet. Below is one example that works fine. However it doesn’t quite line up with your information but it doesn’t seem to matter. MIOS_AIN_DeadbandSet = D’42’ (There is no science at all behind this figure) 22130060 9 -- 176 11 5 1 --- CC: Expression 22131132 9 -- 176 11 10 1 --- CC: Expression 22131549 9 -- 176 11 16 1 --- CC: Expression 22131649 9 -- 176 11 21 1 --- CC: Expression 22131718 9 -- 176 11 26 1 --- CC: Expression 22131786 9 -- 176 11 32 1 --- CC: Expression 22131860 9 -- 176 11 37 1 --- CC: Expression 22131930 9 -- 176 11 42 1 --- CC: Expression What I don’t quite understand is this. The MIDO128 when powered up doesn’t send anything. This means that regardless of the swell shoe position, Miditzer is loaded with swells shades fully open. A light touch on the swell shoe will line up the shades with the shoe position. I can fire a 0xB0 0x0B 0x07 in the USER_Init with the only difference that the shades will be closed. I have not found a way to “read†the swell shoe during USER_Init which would be the correct operation. But I can live with this minor imperfection. Per S

This thread started towards the end here: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1088260784 Short recap: The standard MIDIO128 can have 128 inputs but there is no provision for an analog input which maybe needed in organ applications for controlling the volume. Thorsten had the solution, of course. I first hesitated to add some code since the MIOS looked awfully complicated but Thorsten served the solution on a silver platter so I had a go at it. To my surprise it was quite easy to include the “analog in†function even for a non programmer like me. The hardware was a pot which was wired directly to pin RA0 of the PIC, no AIN module necessary. Thanks Thorsten, great stuff this MIOS! Jim Henry wrote: I don’t know if the flood of commands will be a problem, future will tell. I have the feeling though that we don’t need the resolution of one. Maybe sending only every 5. I think that we might need “somethingâ€-127. This is also depending on the type of virtual organ used. I don’t have Hauptwerk up and running just now, but I have the impression that the MIDI volume control represents the swell shoe position rather than the volume directly. This makes a setting of 0 valid. Anyway, in the MIOS analog handling there is a parameter called “deadband†and is defined as: DESCRIPTION: sets the difference between last and current pot value which has to be achieved to trigger the "NotifyChange" function This looks promising and I will look into that later. Now I will be off for a week. Per S

Johnc, Jim, Thorsten said you only have to enhance the USER_AIN_NotifyChange hook in main.asm. Well, after looking at what was made in the example and compare that with the MIDIO128 application I decided to have a go at it. And would you believe, it works! Minimal effort actually. Here is what I did: 1. Connect a potentiometer between 5V and ground and connected the variable to directly to pin 2 (RA0) on the PIC via connector J5 A0. Somewhere in the documentation it says that no AIN module is required when only one pot is used. 2. Added some code as suggested by Thorsten from his example, assembled, and made a sysex. I have not found a way to include this in the .ini file so presently the MIDI events are those hardcoded in the application. Below is a print from MIDI-OX: 00C9F186 9 -- 90 30 7F 1 C 3 Note On 00C9F187 9 -- 90 31 7F 1 C# 3 Note On 00C9F188 9 -- 90 32 7F 1 D 3 Note On 00C9F189 9 -- 90 33 7F 1 Eb 3 Note On 00C9F4E8 9 -- 90 30 00 1 C 3 Note Off 00C9F4E9 9 -- 90 31 00 1 C# 3 Note Off 00C9F4EA 9 -- 90 32 00 1 D 3 Note Off 00C9F4EB 9 -- 90 33 00 1 Eb 3 Note Off 00CA00F6 9 -- B0 07 04 1 --- CC: Volume 00CA0119 9 -- B0 07 03 1 --- CC: Volume 00CA012F 9 -- B0 07 02 1 --- CC: Volume 00CA0141 9 -- B0 07 01 1 --- CC: Volume 00CA0150 9 -- B0 07 00 1 --- CC: Volume I think the volume function has to be improved a little to suit our needs. There is a danger that the MIDI volume event will flood the system. One way is to take down the sending rate. I will be happy to send you a MAIN.Hex file to try out. What I need is what channel you need. Maybe we should continue this thread in the Midification section. Per S

Johnc, File is on its way. I was fortunate to have an extra known working DIN module with 128 inputs which made it easier to exclude the DIN module being at fault. Regarding switching current I don’t have any experience with the 5V switching. My analog organ has 12V and I took it down to 5V after the switch. Having 12V will easier overcome some resistance due to dirty contacts. I don’t think the 12V by itself will keep contacts cleaner. Future will tell. Up to now I didn’t have any volume control over my MIDI ranks. These were percussion type, and I just pretended I was in a Pizza Parlor where these things are unenclosed anyway. I made some code addition in the 16F core to read the swell pot with the A/D converter and send appropriate MIDI commands. This is not yet tried in real life but is working on my test bed. It requires some tuning since it has a tendency to send a lot of MIDI commands. I have no idea how to do that in MIOS. That is too complicated for me. Maybe Thorsten has a comment on the analog input? Per S

John, One crucial step was left out. After saving the changed .inc file you need to build a new main.hex file. This is done with MPLAB IDE (from www.microchip.com). After that convert to .syx and reload the MIDIO128 (not the MIOS). I can send you an updated "main.hex" file if you want, just send me a mail. Per S

John, I believe you are experiencing the same problem as I did. Please refer to Thorsten's explanation and fix in the following post: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1088260784 Per S

Great! Now it works like a charm. Thanks for the offer but the MIDIO128 does exactly what I need, sending various MIDI messages in response to flipping a switch or pressing a key. 00013076 9 -- B4 24 7F 5 --- Control Change Pin 85 00013077 9 -- B4 25 7F 5 --- Control Change Pin 86 00013078 9 -- B4 26 7F 5 --- CC: Data Entry LSB Pin 87 00013079 9 -- B4 27 7F 5 --- Control Change Pin 88 000130F0 9 -- B4 24 00 5 --- Control Change 000130F1 9 -- B4 25 00 5 --- Control Change <---- No more problem! 000130F2 9 -- B4 26 00 5 --- CC: Data Entry LSB 000130F3 9 -- B4 27 00 5 --- Control Change Thanks for an excellent product and outstanding support. Per S

Jim, I don’t think your requirements are unique. I find the flexibility of assigning various MIDI messages to keys, stops, toe studs, push buttons invaluable. My plans are to use the Miditzer and Hauptwerk with various organs (theatre and classical) with one, two, or three manuals, pedal, one or more swell shoes, and a lot of stop keys, combination buttons, toe studs and buttons for effects like door bells, train whistles and what have you. The ability to load a different MIDI configuration with just a few keystrokes is worth a lot to me. The keyboards and the pedals use more or less standard MIDI assignments but when you come to the other keys it’s a different story. Some of the Virtual Organs can be configured some can’t. The use of a diode matrix saves a lot of hardware and cabling effort, but there might be a price to pay by having configuration limitations. I started using the MIDO128 with 128 inputs some years ago and have recently built some more DIN modules, I now have 384 inputs which should keep me busy (with cabling!) for the next few years. Per S

A possibility is that the default setting in the INI file doesn't match your requirement. In my organ I use +5V to set a stop on and I had to change the setting as follows: ######################################################################## # Inverse Inputs # If Disabled: Inputs are high active # If Enabled: Inputs are low actvive # Default: enabled (for MBHP DIN modules) ######################################################################## [iNVERSE_INPUTS] disabled Per S

I have just finished building another DIN with 128 inputs. I tested this using a connector to fire four inputs simultaneously. Then I noticed the following firing pins 85, 86, 87, 88. MIOS_v1_7 MIDIO128_v2_1 00198322  9  --   90   24   40   1  C  2 Note On   Pin 85 00198323  9  --   90   25   40   1  C# 2 Note On   Pin 86 00198323  9  --   90   26   40   1  D  2 Note On   Pin 87 00198324  9  --   90   27   40   1  Eb 2 Note On   Pin 88  0019847A  9  --   80   24   40   1  C  2 Note Off  0019847A  9  --   80   10   5B   1  E  0 Note Off <----Pin 86 NOTE!!  0019847B  9  --   80   26   40   1  D  2 Note Off  0019847C  9  --   80   27   40   1  Eb 2 Note Off  First idea was that the ini file is wrong, but it isn't, looks like this: 86 =  90 25 40  80 25 40  @OnOff Is there something wrong with the hardware I just built? Tested with another known working DIN which I have used for years. Same problem! On second thought the DIN module only informs whether a pin has changed, there is no MIDI information. I have been using the old MIDO128 with 16F in my project. Took my old core and hooked up the new DIN module. It works. Similar ini file is used.  86 =  90 25 40  80 25 40   (Interestingly the 16F version puts out the MIDI information in a different sequence) MIDIO128_V1004 (16F) 00249EC3  9  --   90   27   40   1  Eb 2 Note On  Pin 88 00249EC4  9  --   90   26   40   1  D  2 Note On  Pin 87 00249EC5  9  --   90   25   40   1  C# 2 Note On  Pin 86 00249EC6  9  --   90   24   40   1  C  2 Note On  Pin 85 00249FC7  9  --   80   27   40   1  Eb 2 Note Off  00249FC7  9  --   80   26   40   1  D  2 Note Off  00249FC8  9  --   80   25   40   1  C# 2 Note Off  Pin 86 No problem  00249FC9  9  --   80   24   40   1  C  2 Note Off  It seem the only pin 86 has a problem when using a core with 18F. Could there be a problem in the PIC itself. Per S Additional information, another ini file: 0036A4DB 9 -- B4 24 7F 5 --- Control Change Pin 85 0036A4DC 9 -- B4 25 7F 5 --- Control Change Pin 86 0036A4DD 9 -- B4 26 7F 5 --- CC: Data Entry LSB Pin 87 0036A4DE 9 -- B4 27 7F 5 --- Control Change Pin 88 0036A575 9 -- B4 24 00 5 --- Control Change 0036A576 9 -- 80 10 5B 1 E 0 Note Off Pin 86 <---- Note!!! 0036A577 9 -- B4 26 00 5 --- CC: Data Entry LSB 0036A578 9 -- B4 27 00 5 --- Control Change Core with 18F and MIOS It seems that the "off" response is always "80 10 5B". In this case the ini file looked as follows for Pin 86: 86 = B4 25 7F B4 25 00 @OnOff

OK, that explains it. I did as you suggested (set the MIDO128 device id to 0x01) and at first I thought I saw some strange behavior like the example below, a ping ( F0 00 00 7E 44 <d>F F7) appeared to respond to any <d> device: 00027FCF 9 -- F0 Buffer: 7 Bytes System Exclusive SYSX: F0 00 00 7E 44 0F F7 0002A529 9 -- F0 Buffer: 7 Bytes System Exclusive SYSX: F0 00 00 7E 44 1F F7 0002C1D8 9 -- F0 Buffer: 7 Bytes System Exclusive SYSX: F0 00 00 7E 44 2F F7 00031FD6 9 -- F0 Buffer: 7 Bytes System Exclusive SYSX: F0 00 00 7E 44 6F F7 00033E77 9 -- F0 Buffer: 7 Bytes System Exclusive SYSX: F0 00 00 7E 44 7F F7 The explanation is that I had the MIDI Merger enabled. Trying another SysEx requesting data worked OK, data showed up only when the correct <d> was used. Many thanks, Per S

I have now made two new Core modules to add to my previous MIDIO128 with the 16F version. The first one was loaded with MIOS and MIDIO128 with device 0x00. No problems there. The second unit was loaded the same way but with device 0x01. I then was trying some SysEx commands listed in the document "midio128_sysex_implementation.txt" quoted below: MIDIO128 SysEx Implementation ============================= Which Actions are implemented ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Example: c) F0 00 00 7E 44 <d>3 <b> F7 Request a block of 256 bytes <d> = device number (0-7) <b> = block number (00-05) I tried the above command and it works but only if I have <d> = device number 0. Same result with other commands. Next was to do something more radical. New boot with device id 0x26, MIOS and MIDIO128 with device 0x26. Everything loaded OK. It looks like this: 000676D6 9 -- F0 Buffer: 8 Bytes System Exclusive SYSX: F0 00 00 7E 40 26 01 F7 The result with the command above (F0 00 00 7E 44 <d>3 <b> F7 ) yielded the same result, works only if <d> = 0 (zero). Actual command sent: SYSX: F0 00 00 7E 44 03 01 F7 Now the question: What is the meaning of the device <d> in these commands? I'm just curious.

Johnc The "90 30" you refer to [MIDI_IN] is only for MIDI events coming FROM the PC into the MIDIO128. This function is not used so don't change anything here. Further down in the ini file you will find this: [MIDI_OUT] ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = 90 47 40 80 47 40 @OnOff 2 = 90 46 40 80 46 40 @OnOff 3 = 90 45 40 80 45 40 @OnOff 4 = 90 44 40 80 44 40 @OnOff 5 = 90 3C 40 80 3C 40 @OnOff Above is an example of the first few entries I have. All 128 have to be configured to the desired function. Regarding your questions about the midio64 (MIDIbox64E ?). I'm not familiar with these devices so I can't comment. In my application all that's needed is to send a MIDI event when a key is pressed or a stop is switched on. The MIDIO128 does a good job doing just that. I have sent you a msg with my private address so we can exchange items that are not of general interest. Per S

It figures. Years ago I made changes to the Midi_out.inc to allow for multiple Note on msg's with one key depression I also hardcoded the debounce value to zero. I didn't use the INI-SYX procedure since it involved additional steps during the testing. This is the explanation for not seeing a latency problem despite the dubious debouncing function, zero debounce. Here's my planned configuration: MIDIO128 #1 (16F), Swell, Pedal, Stops---> MIDIO128 #2 (16F), Accompaniment, Stops---> MIDIO128 #3 (18F New) Great, Solo, Stops---> MIDI to PC running Miditzer and later HW2 All will run the original code except #1 where there is a small change to allow for Swell potentiometer AD conversion. Sunrise today 03:40 Sunset 21:56 Per S

Johnc I don't really have any recommendations regarding speakers. I have seen that some are using Logitech high end speakers with good results. My present setup is SB Live! and Creative 5.1 speakers, don't know offhand which part number but it's low power version but it gives decent quality but certainly not enough for an organ application. At this moment I'm doing some extensive rework on my Rodgers. I have to reassign the MIDIO128 configuration. Right now I have two MIDIO128 to take care of three manuals and the pedal. I need to build a new to be able to handle all the stop keys. I intend to use Jim's Miditzer for now. Fortunately it is very easy to configure the MIDO128. The big job is to disable all the present electronic. Now a question to the MIDIBox community. Since I plan to have three MIDIO128 chained what latency can be expected. With two there is no noticeable latency. Is it better to feed them into a midimerger (3 to 1)? If the MIDIO128 can keep up with the MIDI baudrate then there should be no problem. Account must be taken to the debounce function. Today I run the standard, 25 ms I believe (or is it 32 ms). I have the older version 16F. The really big problem now is the weather, summer has arrived in Stockholm, +25C and sunshine, so I rather be outside than cutting cables. Per S

I suggest that you look at http://www.hauptwerk.co.uk/forum/ . There you will find all the details. To my knowledge no theatre samples exist yet but there are two sets being worked at. Don't know when they will be available, maybe after the summer. Regarding the MIDIO128, I'm thinking how a suitable combination system can be created. In principle it's quite easy, read some switches and send information to magnets. No MIDI involved at all. Per S

Johnc Here are my comments Why not use an analog in... It's not necessary. I have 5V on one side of pot, the other goes straight to the PIC16F to one of the analog in pins. Then I added some code to read and convert the analog signal to a MIDI command. Specification for the PC... I don't know that yet. Since I will use the Wurlitzer which is rather small (8 ranks) it's not so demanding. On the other hand it requires Hauptwerk2 which is very demanding. I have to wait until the new Hauptwerk 2 and Brett's Wurlitzer are released. A Pentium4, 2 Gb and 3 GHz should do the trick I assume. Other Soundfont based solutions... I can honestly say that I have looked at many ideas and solutions in great detail. One very important thing for me is that I, when playing, can control everything from the console, absolutely no fiddling with a PC or an attached synthesizer. Most solutions today require that. The main problem with Soundfont solutions is the limited polyphony, only 64 notes. There may be ways around that but not without problems. To me the Hauptwerk has everything I need. It uses large samples of every pipe, not just a few, polyphony of 1000 or more and I can control everything from the organ console. I should mention that I have a registred copy and have tried several HW organs. Truly amazing in my opinion. Yes, I'm using MIDIO128 for the keyboards, pedal, and the stop switches To clarify, my organ doesn't have any pipes. It's a pure analog electronic organ. I can understand your concern about tuning but I have no idea how that problem is tackled. Is it a problem? How do the commercial companies overcome that? There are lots of installations with both. Per S

Hello, I’m a newcomer to this forum although not to the MIDIO128 and MIDI conversions. My organ is a Rodgers Trio, 3 manual theatre type from 1975. Some years ago I was looking for a suitable MIDI kit and that’s when I found Thorsten’s excellent MIDIO128. My idea at that time was to augment the existing ranks with some sampled ones using a sampler. This required modifications to the MIDIO128 code to provide functions similar to Jim Henry’s Miditzer. For example, if more than one stop was on you had to send several “Note on†with just one key depression. Presently I’m using 2 x 128 (the old 16F version) inputs which is enough for the three manuals, the pedal and a few stop keys. The recent developments in the virtual organ scene has made it possible to take the next step. My plan now is to use the Hauptwerk driver and Brett Milan’s Virginia Wurlitzer, http://www.milandigitalaudio.com/wurlitzer.htm . Then I can junk the entire electronics and replace that with a dedicated PC. I can also use that standard MIDIO128 code since Hauptwerk is doing the handling of stops, couplers and all the rest. The only change I made was to include a small analog to digital routine to read the swell pedal potentiometer and convert that to a MIDI Volume command. The next logical step is to find a function for the combination action, similar to the one Johnc recently described. I will keep my eyes open. Per S