Hi Martin,
Thank you very much for your reply. Your expert insight is always most appreciated.
The pistons that have got stuck so far have been the second combination switch ("2") on the Swell as well as the second combination switch ("2") on the Great. What I don't understand is that the piston doesn't get unstuck even when I unregister the midi event. It seems to be "software" stuck. I can't see anything hardware related forcing the virtual piston to remain on in particular as I can still see the midi activity when pressing and depressing the physical switch. That said it can obviously be something hardware related that "confuses" Hauptwerk.
I am using a midibox controller which is using the windows usb midi legacy drivers. The midibox is forced to one midi port (normally it uses four ports but the driver is known to cause problems and I'm only using one port anyway).
During the build of my console I was using CC messages but following an email conversation that you and me had some time ago (added to the end of this message as it might be relevant) I changed that over to note on/off messages (to increase throughput compared to NRPN). Are there some known issues with note on/off events in combination with pistons?
original email exchange:
I wrote:I'm currently working on a Hauptwerk conversion project using midibox. I have 43 stop action magnets from an old Rodgers organ. The midibox controller is configured to send out the SAM information on midi channel 5 cc=0-42 with conventional off=0 and on=127. I have tested those with the St Anne's default organ. All Sams are working except for the one on cc=38. When I manually switch the SAM I can see the midi signal coming into Hauptwerk but the virtual stop jamb which is configured for this signal is not moving. When I click the virtual stop jamb my SAM gets actuated. I have now changed the configuration so that the same SAM is now transmitting/receiving on CC=39, skipping CC=38. With this configuration the SAM gets properly read by Hauptwerk and everything works fine. My question is: What is wrong with chn=5 CC=38 (I haven't tested changing the channels so I don't know if that really has an impact). Is this reserved for some reason? I would also be grateful if you have any documentation about potentially reserved signals and also recommended signal ranges.
Martin wrote:The only MIDI controller numbers that are reserved (have special meaning) within Hauptwerk are those that are defined within the MIDI standard to be parts of NRPN/RPN MIDI messages:
http://www.philrees.co.uk/nrpnq.htm... i.e.: 6, 38, 98, 99, 100, 101.
(Those need to be reserved because Hauptwerk supports NRPNs and RPNs.)
Apart from that, there are general recommendations for MIDI implementations for DIY projects in the corresponding sub-sections of the 'Reference: MIDI implementation' section in the main Hauptwerk user guide (pages 217-225 in the current v4.1.1 version).
The most important note there is probably that any given MIDI switch should receive exactly the same MIDI message as it sends (same event type, channel, event number, etc.), so that Hauptwerk can configure MIDI output to it automatically by auto-detection. That's especially important since MIDI settings are per-organ, so configuring them all by hand for all organs could be very time-consuming.
Although the user guide mentions using NRPNs or note-on/offs for switches, MIDI CC-on/offs (value=0 for off, 127 for on) should be fine too, provided that you avoid the NRPN/RPN controller numbers mentioned above.
I wrote:Is there any advantage of using NRPN over CC? If I understand it correctly it is a protocol which is build on CC which means that a boolean switch which would be expressed over CC as a single message would as NRPN be encoded as 3-4 CC messages thus unnecessarily clogging up the midi bus. My usb midi controller uses a driver which is around 50 times quicker than standard midi but on standard midi wouldn't this overhead significantly slow down communication? I think e.g. of a general cancel which on the St Anne could actuate a maximum of around 40 stop jambs/combination jambs. Wouldn't NRPN significantly slow things down here.
I can imagine that for swell shoes the 14Bit resolution could make sense though from what I read most organ manufacturers only implement 12-40 step rollers for those which means that the resolution is less than 6Bit.
For now I have reconfigured my controller to skip cc=6 and cc=38 (not getting close to 98, 99, 100 & 101). If there is a tangible advantage of using NRPN I might be persuaded to reconfigure my controller.
Martin wrote:The main reasons that the user guide recommends NRPNs are:
- There are lots more of them than there are CCs. (Theatre organ consoles often have more than 128 stops/pistons/switches, for example.)
- Although Hauptwerk only has six 'reserved' CCs, most other MIDI applications (sequencers, etc.) have special functionality for lots of the other CC numbers (
http://www.indiana.edu/~emusic/cntrlnumb.html ).
- (Minor:) NRPNs support high-resolution continuous controls. That's largely irrelevant for expression/crescendo pedals, but might occasionally be useful for providing precise automated control of pitch, or MIDI file playback speed, for example.
The disadvantage of NRPNs is the extra bandwidth, as you mention.
If none of those NRPN advantages are relevant to your planned project then by all means use CCs.