Per S

Here’s some more information: I pressed the Receive button first, so what you see in the attachment is what came out from a correct INI file (converted to SYX) and loaded by Midi-Ox. I can also see that CC’s are correct. PC’s have Disabled in the Off Event and are coded OnOnly so I presume this is correct. I only have NoteOn/off, PC and CC in my application so I don’t know about other status bytes. I run 2.2b as I saw no need for upgrading to 2.2c. Have not made any changes or updates for years, everything runs fine. System is Win7 64bit.

Yesterday I needed to update my Midio128V2. I tried the MIOS Studio for the first time but the result was more or less a disaster. Here's the INI file: ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = 90 30 01 80 30 01 @OnOff # Spare 2 = 90 31 02 80 31 02 @OnOff # Spare 3 = 90 32 03 80 32 03 @OnOff # Spare 4 = 90 33 04 80 33 04 @OnOff # Spare 5 = 90 34 05 80 34 05 @OnOff # Spare 6 = 90 35 06 80 35 06 @OnOff # Spare The MIOS Studio looks like this: The problem seems to be that the Note Off in the Off Event is replaced by Disabled. If pressing Send all of the Note Off's are effectively removed. I had to use the old fashioned way of using Midi-Ox to send the syx file to restore the function.

MIDIO128 recent release and Change log The change log shows the latest release to be V2.2a. However, both V2.2b and V2.2c have been released. I have not succeeded in finding what has been updated in these last two releases. The change log delivered with V2.2c ends with V2.2a. Could it have something to do with MIOS V1.9g?

I did a few things along what you outlined. First a “sh –version†without any manipulation, followed by the revised Path statement (I cheated a little with the typing). The result below: D:\>sh --version AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 erro r 6 D:\>set path=d:\posix_bin;%path% D:\>sh --version GNU bash, version 2.04.0(1)-release (i686-pc-msys) Copyright 1999 Free Software Foundation, Inc. D:\>sh --version GNU bash, version 2.04.0(1)-release (i686-pc-msys) Copyright 1999 Free Software Foundation, Inc. D:\> This works now. I also tried to assemble with the “make†command and everything is OK. I then did a few other things, first a reboot, no revised “path†statement, result: D:\>sh --version GNU bash, version 2.04.0(1)-release (i686-pc-msys) Copyright 1999 Free Software Foundation, Inc. D:\>sh --version AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 err r 6 D:\>sh --version AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 err r 6 D:\> The interesting thing is that it worked the first time and the first time only. All subsequent “sh –version†turned out with error. I compared the "sh.exe" in both folders but there is no apparent difference apart from the date, one carries the date from my download this morning. Byte count is the same. To me it looks like the MSYS version leaves something in storage that prevents subsequent executions to run properly. I won’t speculate more, I’ll leave it with the revised “path†statement and make that permanent. Later, when I have some spare time, I might clear the whole thing and start from scratch. But for now, I'm OK. Thanks a lot for your assistance.

To answer your questions: Windows_Tool_chain_quickstart. Yes, that was my first try. Although installations went fine, trying to assemble using the “make†command produced the error in question. I then went on to remove everything and started down the Detailed Guide. I did select “Candidate†version as per instructions. I have AVG free 8.0. I did disable this but no change. No other development tools installed, not even SDCC. In the meantime while I doing a complete reinstall, please take a look at this. While fooling around I did enter a couple of “make†and one of them produced a perfect result. D:\MIDI_Stuff\midio128_v2_2b_min>make rm -rf *.cod *.lst *.err AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 erro r 6 make: *** [clean] Error 1 D:\MIDI_Stuff\midio128_v2_2b_min>make rm -rf *.cod *.lst *.err rm -rf *.hex gpasm -p p18f452 -I./src -I ./include/asm -I ./include/share -I ./modules/app_ lcd/dummy main_2_2b.asm D:\MIDI_Stuff\midio128_v2_2b_min>make rm -rf *.cod *.lst *.err AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 erro r 6 make: *** [clean] Error 1 D:\MIDI_Stuff\midio128_v2_2b_min> The middle “make†worked !!! I have not been able to reproduce this so far. Here’s the result of the versions: D:\>make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32 D:\>sed --version GNU sed version 3.02 Copyright (C) 1998 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, to the extent permitted by law. D:\>sh --version AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 erro r 6 D:\>path PATH=d:\msys\1.0\bin;D:\Perl\site\bin;D:\Perl\bin;C:\WINDOWS\;C:\WINDOWS\SYSTEM3 2;C:\WINDOWS\System32\Wbem;C:\Program\ATI Technologies\ATI Control Panel;C:\Prog ram\QuickTime\QTSystem\;C:\Program\Delade filer\Teleca Shared;D:\posix_bin;D:\Pr ogram\gputils\bin D:\> Apparently the "sh" version is suspect Finally, I will redo the whole thing using the quick guide, as requested, later today and will post the results including the version information.

I have inherited a computer which I have updated to suit my needs. It has XP Prof, 3 GHz, 2.5 GB and two drives. I did run into problems when installing the Windows_Toolchain_core. I followed the instructions on the setup. When installing the MSYS the following happens when answering “y†as directed by the instructions: This is a post install process that will try to normalize between your MinGW install if any as well as your previous MSYS installs if any. I don't have any traps as aborts will not hurt anything. Do you wish to continue with the post install? [yn ] y m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4E0000, m.State 0x10000 D:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap (0x715B0000 <0xC30000>) in child, Win32 error 6 0 [main] sh 840 sync_with_child: child 420(0x720) died before initialization with status code 0x1 78 [main] sh 840 sync_with_child: *** child state waiting for longjmp pi.sh: fork: Resource temporarily unavailable D:\msys\1.0\postinstall>pause Pressing “Any key†will complete the installation without any further errors. I decided to do the rest of the steps anyway. I also updated the PATH statements and checked the “make –versionâ€. I tried a test run which produces similar results as above D:\MIDI_Stuff\midio128_v2_2b>make rm -rf *.cod *.lst *.err rm -rf *.hex AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x4E0000, State 0x10000 d:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 6 make: *** [cleanall] Error 1 D:\MIDI_Stuff\midio128_v2_2b> I have installed this on my laptop some time ago without any problems. I checked the forum and eventually found something similar in the German section. It was recommended to download the posix_bin and update the path (that's the way I understood it) which I did, but to no avail. Well, here I'm stuck

The MIDIO128 generates what's in the INI file. Here's an output from my MIDIO128. TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT 0000E72D 9 -- 90 3C 7F 1 C 4 Note On 0000E7FD 9 -- 80 3C 00 1 C 4 Note Off 0000E892 9 -- 90 3D 7F 1 C# 4 Note On 0000E8F8 9 -- 80 3D 00 1 C# 4 Note Off 0000E9D9 9 -- 90 3E 7F 1 D 4 Note On 0000EA7E 9 -- 80 3E 00 1 D 4 Note Off 0000EB12 9 -- 90 3F 7F 1 Eb 4 Note On 0000EB90 9 -- 80 3F 00 1 Eb 4 Note Off Here's the corresponding INI file ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 33 = 90 3F 7F 80 3F 00 @OnOff # D#4 Great 34 = 90 3E 7F 80 3E 00 @OnOff # D4 Great 35 = 90 3D 7F 80 3D 00 @OnOff # C#4 Great 36 = 90 3C 7F 80 3C 00 @OnOff # C4 Great I'm using MIDIO128 2.2B and MIOS 1.9. I have not updated the MIOS to the latest level. Have not seen any problems at all.

True I have three cores chained with Midi Merge enabled. It looks like this: ID00-->ID02-->ID01-->MIDI In on the PC. Here's the INI file for ID02 ######################################### # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = 93 2F 7F 83 2F 00 @OnOff # B2 Solo 2 = 93 2E 7F 83 2E 00 @OnOff # A#2 Solo 3 = 93 2D 7F 83 2D 00 @OnOff # A2 Solo The result after merging in core ID01 and sent to the PC 00047088 9 -- 93 2F 7F 4 B 2 Note On 0004712C 9 -- 83 2F 00 4 B 2 Note Off 0004756F 9 -- 93 2E 7F 4 Bb 2 Note On 00047630 9 -- 83 2E 00 4 Bb 2 Note Off 000478DC 9 -- 93 2D 7F 4 A 2 Note On 0004795E 9 -- 83 2D 00 4 A 2 Note Off The Core Midi Merge function is happily forwarding the Note Off (8X). In my opinion this is the correct way, a merge function shouldn't change anything, it should just forward what's received. It was not my intention to start an animated discussion but merely point out that the Note Off (8X) Status Byte is still, according to the latest MIDI Spec, a valid Status Byte, and is not (yet) obsolete.

The Midibox, at least the MIDIO128, does send Note Off. Here's a clip of my INI file. ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 1 = 90 2F 7F 80 2F 00 @OnOff # B2 Great 2 = 90 2E 7F 80 2E 00 @OnOff # A#2 Great 3 = 90 2D 7F 80 2D 00 @OnOff # A2 Great And here's the response from MIDI-OX 0000658A 9 -- 90 2F 7F 1 B 2 Note On 000065FA 9 -- 80 2F 00 1 B 2 Note Off 00007977 9 -- 90 2E 7F 1 Bb 2 Note On 000079E7 9 -- 80 2E 00 1 Bb 2 Note Off 00007C2E 9 -- 90 2D 7F 1 A 2 Note On 00007CCB 9 -- 80 2D 00 1 A 2 Note Off MIDIO128 version 2.2b

I would be interested to know when the Note Off Status Byte (8X) was made obsolete. I haven’t seen anything about that in various documentations but I admit I don’t have access to the very latest official Midi Specification. I’m always using the Note Off Status Byte since to me it looks better and is easier to spot.

########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 86 = CF 7C 56 80 25 56 @OnOnly # General Cancel 87 = CF 00 57 80 26 57 @OnOnly # P Solo 88 = CF 01 58 80 27 58 @OnOnly # MF Solo 89 = CF 02 08 80 28 59 @OnOnly # F Solo 90 = CF 03 06 80 29 5A @OnOnly # FF Solo 91 = CF 04 07 80 2A 5B @OnOnly # FFF Solo 92 = CF 05 05 80 2B 5C @OnOnly # 1 Solo 93 = CF 06 5D 80 2C 5D @OnOnly # 2 Solo This should give you a general idea. The "Off Evnt" is don't care since it's "@OnOnly". Also the third byte is don't care since this is a "Program Change" command which is only two bytes long. See Miditzer settings under Pistons.

I'm not quite sure what you are looking for but here is an excerpt from one of my INI files. The Great (middle) manual is on Channel 1 and the Pedal is on Channel 3. I'm a Miditzer user and have midified my three manual Rodgers with MIDIO128, including stop keys and pistons (35 of them). To midify my instrument it took three cores with 128 DIN's each. There are a few spares left but they will be used up sooner or later. 42 = 90 3A 7F 80 3A 00 @OnOff # A#3 Great 43 = 90 39 7F 80 39 00 @OnOff # A3 Great 44 = 90 38 7F 80 38 00 @OnOff # G#3 Great 45 = 90 30 7F 80 30 00 @OnOff # C3 Great 46 = 90 31 7F 80 31 00 @OnOff # C#3 Great 47 = 90 32 7F 80 32 00 @OnOff # D3 Great 48 = 90 33 7F 80 33 00 @OnOff # D#3 Great ########################################## # Pin # On Evnt # Off Evnt # Behaviour # ########################################## 49 = 92 2F 7F 82 2F 00 @OnOff # B2 Pedal 50 = 92 2E 7F 82 2E 00 @OnOff # A#2 Pedal 51 = 92 2D 7F 82 2D 00 @OnOff # A2 Pedal 52 = 92 2C 7F 82 2C 00 @OnOff # G#2 Pedal 53 = 92 34 7F 82 34 00 @OnOff # E3 Pedal 54 = 92 35 7F 82 35 00 @OnOff # F3 Pedal

I see what the problem is. You are indeed correct, the "find" is interpreted as the DOS one. D:\>find --version FIND: Parameter format not correct Doing this instead D:\>\posix_bin\find --version GNU find version 4.1 Here is the "path" PATH=D:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Pro gram Files\QuickTime\QTSystem\;d:\Program Files\FastSum;d:\posix_bin;d:\Program Files\gputils\bin;D:\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system3 2\WBEM;C:\Program Files\QuickTime\QTSystem\;d:\Program Files\FastSum Moving up the "posix_bin" in the path took care of the problem. D:\MIDI_stuff\midio128_v2_2b\tools\mk_midio128_syx>make rm -f *.syx find *.ini -type f -exec perl mk_midio128_syx.pl -device_id 0 {} \; Converting midio128.ini -> midio128.syx Converting relay.ini -> relay.syx Thanks a lot.

I followed your advise with the following result (no difference) I should point out that this is not code but a copy from the Command window. I have changed from "code" to "quote". Sorry for that confusion.

I have downloaded the latest version of Midio128 2.2b. Compiling new hex load using the "make" command works fine but creating new syx load presents some problem. Using the "make" command results in the following: D:\MIDI stuff\midio128_v2_2b\tools\mk_midio128_syx>make rm -f *.syx find *.ini -type f -exec perl mk_midio128_syx.pl -device_id 0 {} \; FIND: Parameter format not correct make: *** [all] Error 2 Using the "perl" command works fine D:\MIDI stuff\midio128_v2_2b\tools\mk_midio128_syx>perl mk_midio128_syx.pl midio128.ini Converting midio128.ini -> midio128.syx D:\MIDI stuff\midio128_v2_2b\tools\mk_midio128_syx> I'm not stuck but it would be nice to know what's wrong.

Go to the Miditzer forum (www.virtualorgan.com Main menu on the left) and look under Midi Electronics and "Using 3 swell pedals with Midibox". You need to be registred in that forum to see it. It's all there.

Skip the AIN module, you won't be needing it. I would recommend ordering one more core (different ID) and one more DIN. This will take care of your manuals (61+61) with a few spares and the second core + one DIN will handle the pedals with a few spares and the swell. The second core can later be expanded with more DIN's for adding pistons. Finally, forget the Midibox64. The MIDIO128 is the only suitable application for our purpose. I recommend that you assemble one core and one DIN on a bench, try it out with the MIDI interface hooked up. If you haven't using the MIOS Studio and some of the other needed tools it's easier to do that before installing in the organ. It takes a little while to get used to.

As pointed out by nILS, no AIN is necessary. The standard MIDIO128 application has to be modified to include an analog to digital code section to handle the swell shoes. I have done this to support Solo, Main and Crescendo for the Miditzer. 10K linear pot's wired directly to the core. See the Miditzer forum under Midi Electronics for details. I have completely midified my Rodgers Trio, see http://www.midibox.org/forum/index.php/topic,3506.0.html. This was done with the standard stuff, no matrix. Good luck

This is an interesting comment. The vast majority of organs, theatre or classical, real or electronic don’t use momentary stop keys. My own organ, a theatre type, has stop keys that are either on or off, you flip it and it stays. I used the MIDIO128 application to midify the entire organ, ideal for this purpose. Personally I can’t see the advantage of modifying the setup as shown but I may be missing something here.

Obviously it has been a long time since I visited this site. It's hereby corrected.

First of all you have to make an important decision and that is: 1. Keep the all the analog stuff 2. Junk the analog stuff I own a Trio and after some serious thoughts I decided for item 2. One reason is that I have had the Trio for 30 years and got somewhat tired of the sound and the “innovative†disposition. The other reason was that a friend of mine who is an analog fan could make use of all the leftovers. If you decide for item 2 then you will find that the Midibox with the MIDIO128 application is the ideal thing. I have midified all the keyboards, pedal, all the stops and I have now 35 pistons, also midified. I have used three cores and DIN’s with 128 inputs each. If, on the other hand, you want to keep the analog stuff it is still possible to use the MIDIO128 but additional circuits are needed. I think you will be better off using applications specifically geared to the Rodgers Trio.

No, there are bit positions reserved for different applications. I recommend the following: 0000 0000 0000 0000 The first core 0000 0000 0000 0001 The second 0000 0000 0000 0002 The third See http://www.avishowtech.com/mbhp/buy.html under “Core kitâ€, where there is an ID calculator, for more information. You have a very interesting project, good luck.

Hi Jim, It’s not necessary to assemble the INI into the executable. From the very beginning you could upload the INI file via MIDI as often as you wanted without reassemble. The only thing needed is to convert the INI, which is a simple text file to a SYX file. In my opinion this is one of the best features of the MIDIO128, total flexibility and you can reconfigure with just a few mouseclicks.

I was running a Wurlitzer Chrysoglott just the other day. Here’s how I connected the magnets (in my case, bulbs should behave the same way). Look at J3. Apart from the D0-D7 there is the Vs and one unmarked (note: this is not another ground! It’s connected to ULN pin 10, which is the +Com). I have +12V connected to the unmarked (+Com) and to one side of the magnet (or bulb). The other en of the magnet goes to one of the D0-D7. Ground is connected to Vs. See http://www.ucapps.de/midio128/relay_example.pdf Also make sure that the orientation of the components are OK Note the Pin numbering. Pin 1 in the INI file corresponds to D7, Pin 2 to D6 and so on. I think this is how it is, I don’t have access to my setup right now. I don’t know how your INI file looks like but you can throw lots of Note On/Note off using MIDI-OX and its keyboard function.

I’m using the DOUT+ULN to test Wurlitzer devices. My 12V supply is a car battery charger. I connected the 12V ground and the +12V to connectors J3-J6 on the DOUT module. The battery charger ground is the ground reference in the system.