Unexpected effect of a setting in Stop assignments.

I have obtained the Activity Log, which covers the loading of the St Eucaire, and its replacement by the St. Annes.

These are the references to Switch/LED LtJamb Note 035 in St. Eucaire:
2024-02-01-11-31-27: INF:2561 Diag: OUT: MIDI note on: port: Console MIDI OUT 03 'MIDI-HUB-OUT2-RtJamb' [=> MIDIOUT2 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 90 23 7F.)
2024-02-01-11-31-27: INF:2561 Diag: OUT: MIDI note on: port: Console MIDI OUT 04 'MIDI-HIUB-OUT3-LtJamb' [=> MIDIOUT3 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 90 23 7F.)
2024-02-01-11-31-27: INF:2562 Diag: OUT: MIDI note off: port: Console MIDI OUT 03 'MIDI-HUB-OUT2-RtJamb' [=> MIDIOUT2 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 80 23 7F.)
2024-02-01-11-31-27: INF:2562 Diag: OUT: MIDI note off: port: Console MIDI OUT 04 'MIDI-HIUB-OUT3-LtJamb' [=> MIDIOUT3 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 80 23 7F.)
2024-02-01-11-31-27: INF:2561 Diag: OUT: MIDI note on: port: Console MIDI OUT 03 'MIDI-HUB-OUT2-RtJamb' [=> MIDIOUT2 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 90 23 7F.)
2024-02-01-11-31-27: INF:2561 Diag: OUT: MIDI note on: port: Console MIDI OUT 04 'MIDI-HIUB-OUT3-LtJamb' [=> MIDIOUT3 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 90 23 7F.)
2024-02-01-11-31-27: INF:2562 Diag: OUT: MIDI note off: port: Console MIDI OUT 03 'MIDI-HUB-OUT2-RtJamb' [=> MIDIOUT2 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 80 23 7F.)
2024-02-01-11-31-27: INF:2562 Diag: OUT: MIDI note off: port: Console MIDI OUT 04 'MIDI-HIUB-OUT3-LtJamb' [=> MIDIOUT3 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 035, velocity (0-127): 127. (Raw hex bytes: 80 23 7F.)

I cannot say why the RtJamb is also involved, although I could check - it may be legitimate.

I doubt that this information is of much use, except in that there is no corresponding MIDI activity reported in St. Anne's.

There are NO references to Switch/LED LtJamb Note 035 in St. Anne's even though the LED illuminates.
If it would help, I can send to the full Activity Log. I could also repeat the exercise with MIDI NI re-enabled.

Thanks & best wishes,

Ken
--
Kenneth A. Spencer
==============

Thanks, Martin.

Your most recent message came in while I was running the Activy Log examination, so I didn't get it until just now.
I'll try to get time later to send the backup to Francois.
It's intersting that Iain can replicate the issue, but reassurng to me that I'm not dreaming it up!

Thanks

Ken
--
Kenneth A. Spencer
==============

[mdyde]

Thanks, Ken.

If convenient, please do the test I mentioned last above, ideally in a 'spare' configuration (desktop shortcut), with all of its settings reverted to factory defaults, and then with just the smallest necessary number of relevant stops detected in the two organs, and then reproduce the problem using just the mouse with MIDI logging enabled (and without touching anything else), and then create and send the backup file.

I need to be able to see everything that is logged during the test (with as few irrelevant MIDI messages as possible), so that I can compare it to your MIDI settings. In particular, I need to see the specific MIDI output message which is (presumably) being sent incorrectly, which is triggering the problem. If there is indeed a bug in Hauptwerk then there must be such a MIDI OUT message, and the log would show it (every MIDI message sent is logged).

Edit: P.S. We both replied at the same. Thanks for the update. Yes -- please try the test above (in the 'spare'/all-default configuration, with minimal settings configured, etc.).

[mdyde]

Hello Ken and Iain,

- Iain: am I right in thinking that pressing your MIDI stop tabs whilst Hauptwerk isn't running still results in them changing their illumination states? (I think that must be so from the test you last performed, in which you mentioned that in the second organ you were able to turn off the stop tab that had been defaulted to on by the first organ, even though the tab wasn't mapped to any virtual controls in the second.) I.e. presumably your MIDI encoder/decoder has logic in it for changing the illumination states of its tabs even if it hasn't been told to change them by Hauptwerk.

- Ken: same question: do pressing your MIDI stop tabs whilst Hauptwerk isn't running still results in them changing their illumination states?

I also have an idea for what might be going wrong:

When you unload an organ, all stops will get defaulted back to their default states (which will be 'on' if their default-to-on option is set), and MIDI OUT messages will be sent for them accordingly. However, almost immediately afterwards, Hauptwerk will stop the MIDI devices.

It occurred to me that maybe in your cases those MIDI messages remained in a MIDI buffer somewhere, due to the MIDI driver being stopped before that buffer had processed them, and then that they finally got sent when the MIDI driver restarted and any other MIDI message was sent to the buffer.

The MIDI OUT events that Hauptwerk logs are logged at the point at which it adds them to its own MIDI OUT port buffers. However, I've verified carefully that Hauptwerk's MIDI OUT port buffers are definitely fully flushed after the MIDI driver has been stopped, and before that MIDI driver is next started. Hence there are definitely no MIDI messages remaining in Hauptwerk's MIDI OUT buffers from the previously-loaded organ when the next organ is loaded. (All MIDI drivers are stopped and restarted during that process.) Also, as further a sanity check, I temporarily made Hauptwerk log each MIDI message at the point that it sends it from its MIDI OUT buffers. As expected, no MIDI messages are sent from the previous organ.

However, if the MIDI events from the previous organ had already reached a MIDI buffer within the MIDI interface hardware or within its driver, then perhaps the driver isn't actually flushing its own buffer(s) when the MIDI driver is stopped and subsequently restarted, resulting in it sending those events to your console at a later and unexpected point in time. That doesn't appear to be happening in my case (at least not with a Novation Launchpad), but maybe it is in within your MIDI interface's driver/hardware.

In summary, perhaps the problem might be that your MIDI interface's driver isn't flushing its own buffers after it stops, and/or before it starts.

[mdyde]

P.S.

- Iain: am I right in thinking you're using a MOTU Microlite as the MIDI interface for your console's stops?

- Ken: based on your previous log excerpt, am I right in thinking you're using a "Tapco Link Midi 4x4" MIDI interface (which appears to have been introduced around 2005 and subsequently discontinued) for your stops?
https://www.audiomasterclass.com/blog/t ... interfaces
https://www.gak.co.uk/en/tapco-link-midi-4x4/6899

If it is indeed an issue with MIDI buffers not being flushed in the interface/driver, conceivably for a future Hauptwerk version we could make Hauptwerk wait for a short while immediately prior to stopping a MIDI driver, to try to give the driver more time to finish sending any remaining events in its buffers.

[mdyde]

P.P.S. It might worth trying turning off the "General settings | General preferences | Advanced ...: Limit MIDI OUT port send rate to MIDI 1.0 baud? option (it's on by default), just as a test to see whether it avoids the problem. (E.g. maybe if there's a driver/hardware buffering problem then the relevant events might get fully sent sooner, with more time to spare before the driver stops.)

[mdyde]

P.P.P.S For whatever it's worth (not much!), I altered my test settings to send their MIDI output as MIDI note-on/offs via my MOTU Microlite (instead of to my Launchpad), and I can confirm that everything is still fine from Hauptwerk's side, i.e. the correct MIDI messages are being sent to and from Hauptwerk's own MIDI OUT buffers (and to the MIDI driver) at the correct points in time, with no spurious MIDI messages.

However, I can't easily test whether those MIDI messages are being sent *from* the Microlite at the appropriate times, since I don't have any solenoid-actuated/illuminated MIDI draw-knobs/tabs to attach to it. Hence even with the Microlite everything appears fine within Hauptwerk, but it's still possible that the messages are 'loitering' in the Microlite's driver/hardware buffers until the subsequent organ, and thus causing the problem that you're seeing.

Perhaps I'll also try feeding the Microlite's MIDI output via a MIDI cable back into a different MIDI IN with MIDI-OX monitoring it, so as to try to see whether the Microlite is indeed sending those messages from its buffers later than it should. (However, that might not be conclusive, since it may depend upon timing/speed, which may be different for your MIDI system.)

Thanks for the recent messages & suggestions Martin. I haven't yet been able to deal with the processes that take a rather longer time but I can answer two of the quicker questions.

1. Yes I still use the TapCo. If I can be persuaded that replacing it with a newer model I would readily buy a newer model. But that could be an uncertain question could it not - unless another HW user can supply a confirmation of a MIDI Hub that doesn't experience the issue? If so, I would replace it.
I have had quite a number of other MIDI hubs and several have failed after 2-5 years. I had to send one back to its manufacturer in Germany for repairs. I abandoned it when I discovered further faults. The Tapco labours on!
HOWEVER: I have ordered a new 4i4o USB MIDI HUB but it'll be a few days into next week before it arrives.

2. I tried the Advanced Preferences MIDI baud rate adjustment and that didn't seem to resolve the issue. However I have left it set thus.

3. All of my Switch/LED MIDI controls immediately switch off (including those involved in this issue) as soon as I unload an organ, or close Hauptwerk, and show no further response to button presses. So unlike Iain's MOTU that's not a feature of my MIDI Hub.

I will repeat my previous exercise with the St. Eucaire and the St. Anne's with a little used alternative configuration, and send it to Francois just as soon as I can. Maybe it might lead to a workaround on the issue.

Best wishes, (and sorry to be occupying your time with all this!).

Ken
--
Kenneth A. Spencer
==============

[mdyde]

Thanks, Ken.

[mdyde]

3. All of my Switch/LED MIDI controls immediately switch off (including those involved in this issue) as soon as I unload an organ, or close Hauptwerk, and show no further response to button presses. So unlike Iain's MOTU that's not a feature of my MIDI Hub.

Do you mean that even the ones that are set to default to on turn off when you unload the organ (within which they're set to default to on)? If so, how are they getting turned off? (Hauptwerk would leave them turned on, as Iain mentioned.)

Thanks, Martin,

Yes indeed: if I have a control set to "Default to ON", it is on as soon as the organ loads (as I'd expect).
But as soon as I unload that organ, the LED goes off. Somehow I expected that to be normal behaviour, but I admit that I hadn't given it a thought! Any further comment on that would be gratefully received.

Ken
--
Kenneth A. Spencer
===============

[mdyde]

Thanks, Ken.

I'll await your backup file (which automatically includes all logs and settings files) once you've carried out the test discussed.

By the way, to clarify: when carrying out the test, note that you can safely use "File | Revert all settings to factory defaults" first within your 'spare' configuration -- it will only revert settings within the configuration in which you use it (and won't affect any other configurations). The ideal would be to revert all settings within that configuration, then just to auto-detect absolutely the minimum possible number of stops necessary to reproduce the problem (e.g. just one or two stops, and nothing else) in each of the two organs. That should greatly help by keeping the logged MIDI messages relevant, to make it easy to see whether the MIDI messages being sent are correct or not, with any anomalies easy to spot.

When sending the backup file, please tell us which configuration you used for the test, as well as the specific MIDI messages (MIDI port, channel, note number) that the misbehaving MIDI stop would respond to, so that we can look for any MIDI OUT messages in the log that might affect that MIDI stop.

Thanks for that, Martin ... I'll do my best to do it all exactly as you have described.

I hope that you won't, mind if I do it on Saturday, and send it then, because I have a "social organ day2 tomorrow with an organist (and also long time HW user) friend: he'll be here until mid afternoon and then Lynne & I will go over to his home and enjoy a second set of organs, before going off for an evening meal. All very nice! But then I have a Sunday am communion service to play for, and on Monday a funeral service. Once, I thought I'd retired!! But I will do my very best to get that data to Francois on Saturday!

Thanks again, and best wishes,

Ken
--
Kenneth A. Spencer
===============

Martin:

Yes the lamps on my console operate when HW is not running. The console sends the stop on message (and turns the lamp on) and sends the stop off message (and turns the lamp on). If it receives the on midi code it turns the lamp on and if it receives the off midi code it turns the lamp off. I’ve verified this with MidiMedic.

I am using a MOTU Microlite as the MIDI interface. My console is configured as a Phoenix/Wyvern.
I checked the general preferences, and my midi out is limited to Midi 1.0 speed.

St Anne’s is configured with Grt&Ped Combs coupled defaulting to ON and autodetected to one of the tabs on the console (labelled G&PCC). Some of the other couplers are also assigned to tabs on the console.

Prib is configured with only one stop (Bourdon) is autodetected to a different tab on the console: the only other Prib element autodetected is the keyboard.

If St Anne is loaded, the tab for G&PCC is lit. When St Anne is unloaded the tab for the G&PCC remains lit. If I turn the tab off its lamp goes out (I assume that at that stage HW’s midi is not active so the “off” midi code is not seen by HW.)

When I then load Prib, the G&PCC tab lights without my doing anything. If I turn the G&PCC tab off, the lamp goes out. If I then turn the tab for the Bourdon the stop on, the tab for the G&PCC lights. If I turn the G&PCC tab off, (the Bourdon is still on), play for a short while, the turn off the Bourdon tab, the G&PCC tab lights.

As a “sanity” check, I loaded a different organ (Bethesda) which has no midi tabs set. On loading the organ no tabs lit. I autodetected one stop to a tab. As soon as the autodetect completed the G&PCC tab lit. This instrument seems to behave the same as the Prib organ.

Also for “sanity”, I restarted HW and loaded the Prib organ the G&PCC tab illuminate! St Anne had not been run since starting HW.

This gets more bizarre….

I started HW afresh.
(I started to use the OTT organ so as not to pick up any problems from the Prib.)

Loaded OTT organ. Reset its midi. Auto detected its keyboard. Turned stops on via the touchscreen. It played. G&PCC tab did not light. I exited HW.

I started HW again. OTT organ autoloaded (last organ loaded). It played fine. G&PCC tab did not light.

I auto detected one OTT stop to a tab on the console. At the end of autodetect the G&PCC tab lit. I turned it off. I operating the tab assigned to the stop, the stop came on and the G&PCC tab lit.
.
It seems that the use of the Default ON in St Anne’s has left the installation in such a state that when a tab is detected for another stop on another organ, this default behaviour infects the other organ.

I then loaded St Anne again. I turned off the default to ON for the G&PCC stop. I reloaded St Anne and indeed the G&PCC did not default to ON. I loaded the OTT organ without changing anything for that instrument and this time the G&PCC did not light. (The problem for the Prib and Bethesda organs was also “cured”.)

I then repeated this activity on an unused configuration (3).

I started HW configuration 3. I configured only the console as midi in and out.

I loaded (building the cache) Prib. Autodetected the Flute 4 to one of the console tabs and set the stop to default to ON. This worked as expected.

I loaded (building the cache) OTT. Autodetect a stop to a console tab. At the end of the autodetect the tab autodetected to the Prib Flue 4 lit. This is then the same behaviour seen before (in config 0) for the G&PCC.

The “problem went away” when the default ON was removed.

I tried using the Launchpad as the console input. Configured it as the only midi in and midi out.
I tried to repeat the problem described above but could not recreate it.

When the organ with the default on stop was unloaded its Launchpad light went out. For the console the tab did not turn off. Whilst this could be due to buffering or timing, it does not appear to explain the other incidents.

I fear my tests might not be helping clarify the incident… Let me know if you want me do try anything.

Iain

Good morning, Martin ...
I have just managed to send the Backup of a minimal configuration of HW with the St Annes and St Eustace to Fransois..
The fault is exhibited.
Load St. Annes ... note the always ON Sw>Gt coupler
Load St Eustace ... pull the 8' Montre >>> The Switch/Led corrersponding to your Sw>Gt of the St. Anne's will illuminate.

I do hope tnat helps - this is short & sweet because I must now rush.

Many thanks as always ....

Ken.