mumblecake

Hi Thorsten, Just as an update: I have now changed the configuration and decided to run the same "waiting test" to check for glitches with debug on. Sure enough the glitches occured eventually but they are not any longer causing the keys on the next keyboard to get stuck. In case no event fires when those DIN Matrix inputs actuate. Thank you very much again. That had been bugging me for months and I don't think I would have ever found the reason without your help. It still means that there is an electrical problem which induces those glitches but at least they aren't having such a big effect anymore (one step at a time). Best Regards Mathis

Hi Thorsten, just quickly: If I interpret this correctly this supports your theory. I will change the configuration asap. Scanning for MIDI Inputs... [1] MIDIbox NG (*) MIDI Monitor ready. [ 203.819] f0 00 00 7e 32 00 0f 4d 49 4f 53 33 32 f7 [ 204.015] f0 00 00 7e 32 00 0f 4d 49 4f 53 33 32 f7 [ 204.019] f0 00 00 7e 32 00 0f 4d 42 48 50 5f 43 4f 52 45 5f 53 54 4d 33 32 46 34 f7 [ 204.022] f0 00 00 7e 32 00 0f 53 54 4d 33 32 46 34 78 78 f7 [ 204.030] f0 00 00 7e 32 00 0f 31 30 30 31 36 34 31 33 f7 [ 204.032] f0 00 00 7e 32 00 0f 33 35 30 30 33 37 30 30 30 31 34 37 33 33 33 32 33 31 33 37 33 37 33 38 f7 [ 204.034] f0 00 00 7e 32 00 0f 31 30 34 38 35 37 36 f7 [ 204.037] f0 00 00 7e 32 00 0f 31 39 36 36 30 38 f7 [ 204.041] f0 00 00 7e 32 00 0f 4d 49 44 49 62 6f 78 20 4e 47 20 56 31 2e 30 33 33 f7 [ 204.043] f0 00 00 7e 32 00 0f 28 43 29 20 32 30 31 35 20 54 2e 4b 6c 6f 73 65 f7 [ 217.381] f0 00 00 7e 32 00 0f 00 f7 [ 407.607] 91 33 00 Chn# 2 Note Off D#2 (optimized) [ 407.609] 91 24 00 Chn# 2 Note Off C-1 (optimized) [ 407.613] 91 32 00 Chn# 2 Note Off D-2 (optimized) [ 407.616] 91 25 00 Chn# 2 Note Off C#1 (optimized) [ 407.618] 91 31 7f Chn# 2 Note On C#2 Vel:127 [ 407.621] 91 26 7f Chn# 2 Note On D-1 Vel:127 [ 407.623] 91 30 7f Chn# 2 Note On C-2 Vel:127 [ 407.626] 91 27 7f Chn# 2 Note On D#1 Vel:127 [ 407.627] 91 2f 7f Chn# 2 Note On B-1 Vel:127 [ 407.629] 91 28 7f Chn# 2 Note On E-1 Vel:127 [ 407.630] 91 2e 7f Chn# 2 Note On A#1 Vel:127 [ 407.630] 91 29 7f Chn# 2 Note On F-1 Vel:127 [ 407.631] 91 2d 7f Chn# 2 Note On A-1 Vel:127 [ 407.631] 91 2a 7f Chn# 2 Note On F#1 Vel:127 [ 407.633] 91 2c 7f Chn# 2 Note On G#1 Vel:127 [ 407.635] 91 2b 7f Chn# 2 Note On G-1 Vel:127 [ 407.635] 91 33 7f Chn# 2 Note On D#2 Vel:127 [ 407.635] 91 24 7f Chn# 2 Note On C-1 Vel:127 [ 407.636] 91 32 7f Chn# 2 Note On D-2 Vel:127 [ 407.636] 91 25 7f Chn# 2 Note On C#1 Vel:127 [ 217.149] set debug on [ 217.381] Debug mode turned on [ 407.605] MBNG_MATRIX_NotifyToggle(1, 33, 1) [ 407.605] MBNG_DIN_NotifyToggle(1033, 1) [ 407.607] [EVENT] id=BUTTON:1033 hw_id=BUTTON:1033 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.608] MBNG_MATRIX_NotifyToggle(1, 34, 1) [ 407.608] MBNG_DIN_NotifyToggle(1034, 1) [ 407.608] [EVENT] id=BUTTON:1034 hw_id=BUTTON:1034 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.609] MBNG_MATRIX_NotifyToggle(1, 35, 1) [ 407.610] MBNG_DIN_NotifyToggle(1035, 1) [ 407.613] [EVENT] id=BUTTON:1035 hw_id=BUTTON:1035 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.613] MBNG_MATRIX_NotifyToggle(1, 36, 1) [ 407.614] MBNG_DIN_NotifyToggle(1036, 1) [ 407.614] [EVENT] id=BUTTON:1036 hw_id=BUTTON:1036 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.616] MBNG_MATRIX_NotifyToggle(1, 37, 0) [ 407.617] MBNG_DIN_NotifyToggle(1037, 0) [ 407.618] [EVENT] id=BUTTON:1037 hw_id=BUTTON:1037 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.619] MBNG_MATRIX_NotifyToggle(1, 38, 0) [ 407.619] MBNG_DIN_NotifyToggle(1038, 0) [ 407.620] [EVENT] id=BUTTON:1038 hw_id=BUTTON:1038 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.621] MBNG_MATRIX_NotifyToggle(1, 39, 0) [ 407.621] MBNG_DIN_NotifyToggle(1039, 0) [ 407.622] [EVENT] id=BUTTON:1039 hw_id=BUTTON:1039 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.623] MBNG_MATRIX_NotifyToggle(1, 40, 0) [ 407.624] MBNG_DIN_NotifyToggle(1040, 0) [ 407.625] [EVENT] id=BUTTON:1040 hw_id=BUTTON:1040 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.626] MBNG_MATRIX_NotifyToggle(1, 41, 0) [ 407.626] MBNG_DIN_NotifyToggle(1041, 0) [ 407.627] [EVENT] id=BUTTON:1041 hw_id=BUTTON:1041 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.628] MBNG_MATRIX_NotifyToggle(1, 42, 0) [ 407.628] MBNG_DIN_NotifyToggle(1042, 0) [ 407.629] [EVENT] id=BUTTON:1042 hw_id=BUTTON:1042 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.629] MBNG_MATRIX_NotifyToggle(1, 43, 0) [ 407.629] MBNG_DIN_NotifyToggle(1043, 0) [ 407.630] [EVENT] id=BUTTON:1043 hw_id=BUTTON:1043 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.630] MBNG_MATRIX_NotifyToggle(1, 44, 0) [ 407.630] MBNG_DIN_NotifyToggle(1044, 0) [ 407.630] [EVENT] id=BUTTON:1044 hw_id=BUTTON:1044 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.630] MBNG_MATRIX_NotifyToggle(1, 45, 0) [ 407.630] MBNG_DIN_NotifyToggle(1045, 0) [ 407.631] [EVENT] id=BUTTON:1045 hw_id=BUTTON:1045 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.631] MBNG_MATRIX_NotifyToggle(1, 46, 0) [ 407.631] MBNG_DIN_NotifyToggle(1046, 0) [ 407.631] [EVENT] id=BUTTON:1046 hw_id=BUTTON:1046 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.631] MBNG_MATRIX_NotifyToggle(1, 47, 0) [ 407.631] MBNG_DIN_NotifyToggle(1047, 0) [ 407.631] [EVENT] id=BUTTON:1047 hw_id=BUTTON:1047 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.633] MBNG_MATRIX_NotifyToggle(1, 48, 0) [ 407.634] MBNG_DIN_NotifyToggle(1048, 0) [ 407.635] [EVENT] id=BUTTON:1048 hw_id=BUTTON:1048 bank=0 fwd_id=DISABLED:0 type=NoteOn value=127 label= [ 407.635] MBNG_MATRIX_NotifyToggle(1, 33, 0) [ 407.635] MBNG_DIN_NotifyToggle(1033, 0) [ 407.635] [EVENT] id=BUTTON:1033 hw_id=BUTTON:1033 bank=0 fwd_id=DISABLED:0 type=NoteOn value=0 label= [ 407.635] MBNG_MATRIX_NotifyToggle(1, 34, 0) [ 407.635] MBNG_DIN_NotifyToggle(1034, 0) [ 407.635] [EVENT] id=BUTTON:1034 hw_id=BUTTON:1034 bank=0 fwd_id=DISABLED:0 type=NoteOn value=0 label= [ 407.635] MBNG_MATRIX_NotifyToggle(1, 35, 0) [ 407.636] MBNG_DIN_NotifyToggle(1035, 0) [ 407.636] [EVENT] id=BUTTON:1035 hw_id=BUTTON:1035 bank=0 fwd_id=DISABLED:0 type=NoteOn value=0 label= [ 407.636] MBNG_MATRIX_NotifyToggle(1, 36, 0) [ 407.636] MBNG_DIN_NotifyToggle(1036, 0) [ 407.636] [EVENT] id=BUTTON:1036 hw_id=BUTTON:1036 bank=0 fwd_id=DISABLED:0 type=NoteOn value=0 label= [ 407.636] MBNG_MATRIX_NotifyToggle(1, 37, 0) [ 407.636] MBNG_DIN_NotifyToggle(1037, 0)

Ahhhhhh, I wouldn't have spotted that in a million years! You are absolutely right that I ignore rows 3 & 4 (to my knowledge you can only define DIN matrix starting from 4 rows) I ran the MIOS Studio over night with debugging on but no glitches occured this time. Will try again later! I will also modify the configuration as proposed and will report back. Thank you very much for your help! Best Regards Mathis

Hi Thorsten, thanks for your reply and frohes neues Jahr! It is really weird. I left the MIOS studio running overnight to see what exact events occur (is there a way to stream the output directly to a file?). Btw i was wrong, the SRs in question are actually the first ones (not number 3 & 4): this is what i get you see sudden midi off events sent before on events (timestamp 6041.075 following). I can imagine that an electrical problem causes the events but it is weird that they are swapped. Any ideas? Best regards Mathis Scanning for MIDI Inputs... [1] MIDIbox NG (*) MIDI Monitor ready. [ 240.973] f0 00 00 7e 32 00 0f 4d 49 4f 53 33 32 f7 [ 241.170] f0 00 00 7e 32 00 0f 4d 49 4f 53 33 32 f7 [ 241.173] f0 00 00 7e 32 00 0f 4d 42 48 50 5f 43 4f 52 45 5f 53 54 4d 33 32 46 34 f7 [ 241.176] f0 00 00 7e 32 00 0f 53 54 4d 33 32 46 34 78 78 f7 [ 241.179] f0 00 00 7e 32 00 0f 31 30 30 31 36 34 31 33 f7 [ 241.182] f0 00 00 7e 32 00 0f 33 35 30 30 33 37 30 30 30 31 34 37 33 33 33 32 33 31 33 37 33 37 33 38 f7 [ 241.185] f0 00 00 7e 32 00 0f 31 30 34 38 35 37 36 f7 [ 241.188] f0 00 00 7e 32 00 0f 31 39 36 36 30 38 f7 [ 241.192] f0 00 00 7e 32 00 0f 4d 49 44 49 62 6f 78 20 4e 47 20 56 31 2e 30 33 33 f7 [ 241.195] f0 00 00 7e 32 00 0f 28 43 29 20 32 30 31 35 20 54 2e 4b 6c 6f 73 65 f7 [6041.075] 91 33 00 Chn# 2 Note Off D#2 (optimized) [6041.075] 91 24 00 Chn# 2 Note Off C-1 (optimized) [6041.075] 91 32 00 Chn# 2 Note Off D-2 (optimized) [6041.075] 91 25 00 Chn# 2 Note Off C#1 (optimized) [6041.075] 91 31 00 Chn# 2 Note Off C#2 (optimized) [6041.075] 91 26 00 Chn# 2 Note Off D-1 (optimized) [6041.075] 91 30 00 Chn# 2 Note Off C-2 (optimized) [6041.075] 91 27 00 Chn# 2 Note Off D#1 (optimized) [6041.076] 91 2f 00 Chn# 2 Note Off B-1 (optimized) [6041.076] 91 28 00 Chn# 2 Note Off E-1 (optimized) [6041.076] 91 2e 00 Chn# 2 Note Off A#1 (optimized) [6041.076] 91 29 00 Chn# 2 Note Off F-1 (optimized) [6041.076] 91 2d 00 Chn# 2 Note Off A-1 (optimized) [6041.076] 91 2a 00 Chn# 2 Note Off F#1 (optimized) [6041.076] 91 2c 00 Chn# 2 Note Off G#1 (optimized) [6041.076] 91 2b 00 Chn# 2 Note Off G-1 (optimized) [6041.078] 91 33 7f Chn# 2 Note On D#2 Vel:127 [6041.078] 91 24 7f Chn# 2 Note On C-1 Vel:127 [6041.078] 91 32 7f Chn# 2 Note On D-2 Vel:127 [6041.078] 91 25 7f Chn# 2 Note On C#1 Vel:127 [6041.078] 91 31 7f Chn# 2 Note On C#2 Vel:127 [6041.078] 91 26 7f Chn# 2 Note On D-1 Vel:127 [6041.078] 91 30 7f Chn# 2 Note On C-2 Vel:127 [6041.078] 91 27 7f Chn# 2 Note On D#1 Vel:127 [6041.078] 91 2f 7f Chn# 2 Note On B-1 Vel:127 [6041.078] 91 28 7f Chn# 2 Note On E-1 Vel:127 [6041.078] 91 2e 7f Chn# 2 Note On A#1 Vel:127 [6041.079] 91 29 7f Chn# 2 Note On F-1 Vel:127 [6041.080] 91 2d 7f Chn# 2 Note On A-1 Vel:127 [6041.080] 91 2a 7f Chn# 2 Note On F#1 Vel:127 [6041.080] 91 2c 7f Chn# 2 Note On G#1 Vel:127 [6041.080] 91 2b 7f Chn# 2 Note On G-1 Vel:127 [39930.538] 93 00 00 Chn# 4 Note Off c-2 (optimized) [39930.538] 93 01 00 Chn# 4 Note Off c#2 (optimized) [39930.538] 93 02 00 Chn# 4 Note Off d-2 (optimized) [39930.539] 93 03 00 Chn# 4 Note Off d#2 (optimized) [39930.539] 93 04 00 Chn# 4 Note Off e-2 (optimized) [39930.539] 93 05 00 Chn# 4 Note Off f-2 (optimized) [39930.539] 93 06 00 Chn# 4 Note Off f#2 (optimized) [39930.539] 93 07 00 Chn# 4 Note Off g-2 (optimized) [39930.539] 90 2c 7f Chn# 1 Note On G#1 Vel:127 [39930.539] 90 2d 7f Chn# 1 Note On A-1 Vel:127 [39930.539] 90 2e 7f Chn# 1 Note On A#1 Vel:127 [39930.539] 90 2f 7f Chn# 1 Note On B-1 Vel:127 [39930.540] 90 30 7f Chn# 1 Note On C-2 Vel:127 [39930.541] 90 31 7f Chn# 1 Note On C#2 Vel:127 [39930.541] 90 32 7f Chn# 1 Note On D-2 Vel:127 [39930.541] 90 33 7f Chn# 1 Note On D#2 Vel:127 [39930.541] 90 2c 00 Chn# 1 Note Off G#1 (optimized) [39930.541] 90 2d 00 Chn# 1 Note Off A-1 (optimized) [39930.541] 90 2e 00 Chn# 1 Note Off A#1 (optimized) [39930.541] 90 2f 00 Chn# 1 Note Off B-1 (optimized) [39930.541] 90 30 00 Chn# 1 Note Off C-2 (optimized) [39930.541] 90 31 00 Chn# 1 Note Off C#2 (optimized) [39930.541] 90 32 00 Chn# 1 Note Off D-2 (optimized) [39930.541] 90 33 00 Chn# 1 Note Off D#2 (optimized) [39930.543] 93 08 00 Chn# 4 Note Off g#2 (optimized) [39930.543] 93 0b 00 Chn# 4 Note Off b-2 (optimized) [39930.543] 94 00 00 Chn# 5 Note Off c-2 (optimized) [39930.543] 94 01 00 Chn# 5 Note Off c#2 (optimized) [39930.543] 94 02 00 Chn# 5 Note Off d-2 (optimized) [39930.543] 94 03 00 Chn# 5 Note Off d#2 (optimized) [39930.543] 94 04 00 Chn# 5 Note Off e-2 (optimized) [39930.551] 94 08 00 Chn# 5 Note Off g#2 (optimized) [39930.551] 94 09 00 Chn# 5 Note Off a-2 (optimized) [39930.551] 94 0a 00 Chn# 5 Note Off a#2 (optimized) [39930.551] 94 0b 00 Chn# 5 Note Off b-2 (optimized) [39930.551] 94 0c 00 Chn# 5 Note Off c-1 (optimized) [39930.551] 94 0d 00 Chn# 5 Note Off c#1 (optimized) [39930.551] 94 0e 00 Chn# 5 Note Off d-1 (optimized) [39930.551] 94 0f 00 Chn# 5 Note Off d#1 (optimized) [39930.557] 94 15 00 Chn# 5 Note Off a-1 (optimized) [39930.557] 94 16 00 Chn# 5 Note Off a#1 (optimized) [39930.557] 94 17 00 Chn# 5 Note Off b-1 (optimized) [39930.563] 94 1d 00 Chn# 5 Note Off F-0 (optimized) [39930.563] 94 1e 00 Chn# 5 Note Off F#0 (optimized)

Hi, as part of my organ conversion I'm reading in the manuals with a DIO matrix module. Because of the weird pin layout of the keyboards and there also otherwise being no reason to use the keyboard drivers, I am using a simple DIN matrix (NGC file is attached). There are actually two DIN matrices. One for the pedalboard which is a 2*16 matrix and the two manuals which is a 8*16 matrix for both. All are inverted due to "wrong" diode directions. There is also loads of other stuff further down in the config file like buttons as well as switches and solenoids + some logic connecting the two. The problem that I'm having is that on the second DIO Matrix I occasionally get a glitch that on the first multiplexer all 16 keys fire a NoteOn event but never a NoteOff event (the lowest 16 keys on the first manual: IDs: 1033 - 1048). The glitch happens irregularly, at the moment maybe once every 4-5 hours (about every 15 million iterations of the midibox). Earlier in the year it was something like every few minutes though I was running a different firmware back then. I first suspected an electrical problem as I employed a different technique at the beginning of my project (crimping) which I later found to be unreliable and changed it (using ribbon cable + IDC connectors and soldering the wires with heat shrink over the solder joints. I re-did all the connections with IDC connectors. That didn't change the problem. I then remembered that the first time I powered up that DIO matrix module I had the DIs and the DOs swapped and thought I might have damaged the chips, so I exchanged the whole board: No change. I have now basically run out of ideas and wondered if any of you had any ideas: electrical/configuration/operating system/could it be software? What is surprising me is that even if the SRs return xFF for a tick and cause 16 NoteOn messages to get fired, wouldn't a reading of x00 the following tick cause NoteOff events to get fired? It seems weird that the NoteOff events simply never seem to get sent. I'd be very grateful for any suggestions as the only thing I can now think of is to go on a wild goose chase and trying to figure out if the special case of my configuration with inverted DIN matrix and the number of shift registers being limited can very rarely cause some kind of exception in the software. Best Regards Mathis ORGAN.NGC

That's really cool! How long did it take you to build this. It looks like a lot of effort has gone into this. I love the portable design. I'm curious about the speakers. Have you put much effort/moddeling into getting the design of the box right? If so, how did you go on about this? I'm asking as this is something that is on my to do list. Best Regards Mathis

Awesome! I will install the version the weekend Thanks Mathis

Glad you still keep going :) Obviously help with wiring will be difficult but I'm sure we can gather some ideas about configuration to make your keys play the right midi notes :) What are they doing and what should they doing? Are you using midibox NG?

Hi Thorsten, A quick question. If the signal inversion occurs again (which I still find highly likely to be a windows driver problem). What would you like me to do to gather data which might be useful to get to the bottom of this? Are there still plans to get the GM5 driver compatible with the stm32f4? BR Mathis

Hi Thorsten, I have changed the single_port flag and the start up issues have vanished (also upgraded to 1.33pre6 though the change log doesn't indicate any changes of interest to me). Thank you very much .. I wasn't aware that that would be connected. As for the inverted signals, I wasn't able to replicate it. I hope that it was a freak interaction of the failing driver and the midibox in which case the single_usb flag might get rid of that as well. If it happens again I will try to gather some more intel and post here again. Fingers crossed and it is sorted as well :) Thank you very much again! BR Mathis

Hi Thorsten, thanks for the reply. I will update the firmware this weekend and give it a try with the single usb option. I use my midibox (NG 1.033pre5) under Win7 64Bit. If I remember correctly the GM5 driver wasn't working with the STM32 yet, otherwise I would give that a go as well. The signal inversion problem did happen again this week, this time after I had used my midibox and then rebooted the computer (which didn't power cycle the midibox). I noticed then when I opened MIOS studio that when I pressed a button for the first time a hex message displayed rather than the note on. On release the note on message displayed. I will check if it is repeatable and also check if it goes away with the single usb option ... sounds like it might be related after all. BR Mathis

I am seeing a strange effect every time I switch on my computer and with it my STM32 midi controller. After windows has booted up and I start using the midi controller I can squeeze out exactly 16 midi messages (8 note on followed by an off). Afterwards the midi messages seize to arrive for another 48 midi messages (24 note on + off). Afterwards the midi controller is working without fault. This is happening every time the midibox starts up at the same time as the computer/before the computer is fully booted up. If I don't start the midibox together with windows but plug it in once windows is already booted up I don't get this behaviour and the midibox works immediately without flaw. Another interesting thing is that if I start up MIOS Studio before I have fired 64 midi events, MIOS Studio does not recognise/fails to properly communicate with the midi controller. If I start up MIOS Studio after I have triggered the right number of events it connects fine. Is that some kind of weird windows driver problem? Has anyone else seen a similar behaviour? It's not a big problem as I know that it is going to come back to life but it is odd. Another strange thing and this one is extremly rare (has happened twice to me over the last 3 months): On these occasions the midibox has inverted all note on/off events. All keyboard scanning was working properly except that it send note off events on a press and note on on a de-press. Same went for buttons which were not on a scan matrix. A power cycle of the midibox solves that problem. Again, not a big issue but odd.

After exactly 8 months and 1 day I have finally managed to get my virtual pipe organ into a playable state: This is the organ console with attached touch screen monitor This is the console Here you can see the side of the console and a bit of the pedalboard and touch screen The pedalboard Here you can see the stop action magnets in action which are controlled via the touch screen: http://youtu.be/_HQcKWEX9Hc The sense of achievement is phenomenal after all this time. Thanks to everyone who helped me on the way. Thank you very much in particular to TK without whom this project would not have lifted off. I will try to compile some documentation for others who might be interested to do a similar project. Best Regards Mathis

A little demo of the stop tabs in action. I'm controlling them via the touch screen http://youtu.be/_HQcKWEX9Hc

Hi Pete, Having the inputs and outputs on different controllers would definitely work ... though here comes a big BUT. If input and output aren't on the same midiport+channel+signal you will have to set up the output manually. Normally it is just right clicking the stop jamb, click on automatic detection, switch the physical stop tab on and off and Hauptwerk will ask you if you want to configure the output with the same settings. If the in and output settings aren't exactly matching this automatic procedure will still work for the inputs, the outputs you will however have to set up fully manually. Now that's ok for a couple of stops ... but if you are talking about an 80 rank theatre organ I'm afraid you might lose the will to live. I have the best intentions to create a thread with detailed documentation of what I have done once the job IS done, what worked, what didn't, what were the lessons learned ... just anything which might make the learning curve a little bit less steep for someone who would like to start a similar project. BR Mathis

I'm also using Hauptwerk for my organ. At the moment I only have the free edition and only St Anne's. The key part of my solution is the way NG is using the script file. When the script file gets called it gets loaded from the SD card which takes about 5ms. When in the mean time another request to use the script file gets launched that means that the previous iteration gets abortet and a new instance gets launched. For a general cancel e.g. on the St Anne's which has around 40 stop/combination jambs that means that Hauptwerk sends out 40 commands which will take less than 1ms (isn't high speed usb midi transfer a nice thing ... 50 times faster than standard midi ... otherwise 40 commands would take several ms). In this time the script gets launched 40 times, the first 39 iterations don't even manage to load the file from disk before they get aborted. Nevertheless all correct solenoids are now switched on and the 40th iteration starts to run. All the script is now doing is to deactivate the sending of the midi signal on change of any stop, wait 100ms, deactivate all solenoids and re-activate the midi signal broadcast. After I had all my stop tabs wired in and written the configuration a general cancel of 40 stop tabs was the first thing I tried. It's funny how emotional 40 switches switching can get you ;) As I said I modded the original DOUT R5 board. It does support the footprint of the ULN2803 but the ULN specific pins are not connected to anything so I did the following: for each SR/ULN I had a ground line which I wired to the power supply and a wire with the contact of the flyback diodes which I connected to the common positive. So overall 11 wires to the PSU ground and 11 wires to the PSU positive (+1 wire which connects to the common plus rail of the SAMs). You are obviously right that this means that for 100ms you get a current of potentially 1.6A (I use a 12V PSU rather than 15V reducing the current from 0.5A per solenoid to 0.4A) through a single ground wire of a ribbon cable which is everything but optimal but I hope that I don't suffer any weird behaviour as a result of this. I guess you could probably mod the board in some way to use the MIC (can it be used for common negative SAMs?) but I guess that your board is better for that. Redesigning the board was simply out of scope for me both time wise and money wise. I think John was mainly struggling with weird behaviour coming from using the ULNs for his common negative SAMs as theyare designed for common positive SAMs. While it still works in principle you apparently get weird cross talk problems by occasionally actuating neighbouring SAMs, etc. If you would get a solution for common negative SAMs up and running I think he would be very interested though I read between the lines that he now got a commercial solution. Finally I'm not sure if you put any thought into whether to use NRPNs or CCs for your SAMs/Pistons. If you want to use CCs I just wanted to make you aware of a caveat which I found out about from Hauptwerk support. Hauptwerk supports NRPN which really is a meta-protocol based on CCs. The CC messages which are used for NRPN are CC=6,38,98,99,100,101: http://www.philrees.co.uk/nrpnq.htm That means that these CC signals are reserved in Hauptwerk and have to be skipped when assigning signals. I only collided with CC=6 and 38 before I found out. 38 simply doesn't work (Hauptwerk can send it but won't react to it on receiving it) while I attribute using cc=6 to corrupting the organ cache which means that I had the joy of having to wait 5 minutes for it to get rebuild. Hauptwerk recommends using NRPN. You have to decide if it gives you any advantages over the down turn of increased bandwith usage. edit: I totally appreciate that my solution seems a bit of an overkill ... after all my configuration is now longer than 700 lines (config + script file attached). edit2: my DOUTs are 10-12'' next to the Core and all DOUTs are directly next to each other. ORGAN.zip

Just looked at your board and I'm a bit puzzled, maybe you could explain. You say that your SAM grounds are decoupled from the SR grounds. How is that possible? In order for the ULN to get the signal from the SR it needs to have a signal which is referenced to the ground of the SR. The current of the Darlington also needs to go through the same ground. Am I missing something? edit: yes, clearly mssing something. If I understand correct: With the ULN the grounds are coupled which is not a problem as it is for common positive SAMs, while the Mic is decoupled as it seems to be for common negative SAMs? Do you have a schematic? edit2: no I take that back ... still don't understand it :(

Hi Pete, if the keyboards are not standard in any way I guess that you are definitely the best source of information for Jay. Regarding SAMs: As part of above linked forums thread I have now posted a complete solution for SAMs if you would upgrade to the STM32F4 and would use the NG firmware. My solution uses the standard DOUT boards. They need to get modded by connecting the ground pin of the ULN2803 to the board ground as well as connecting the flyback diode pin to the unconnected terminal of the header. I connected the ground of all boards to the 12V/25A PSU (SAMs were designed for 15V but work fine with 12V) and the flyback diode wires + the common positive to the positive output of the PSU. If you always wire the off and on solenoids for a SAM in succession you won't get into trouble with the current rating of the darlington array as only a maximum of 4 solenoids can get activated at the same time. Very important though, this set up only works for common positive SAMs. cheers Mathis