Unexpected effect of a setting in Stop assignments.

[mdyde]

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, Ken. No rush at all. Hope you have an enjoyable day today.

A correction to my previous posts: when creating the file to send us, please simply use "Help | Create a diagnostic file ...", rather than "File | Backup ...". (I had forgotten that diagnostics files do in fact contain the settings files for all organs, which is sufficient for what we'd need to see, so there's no need for a full backup file after all. My apologies for any confusion.)

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.

Thanks, Iain. In that case, your Wyvern console's internal logic must be performing that toggling.

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.

Yes -- that would be expected. When MIDI starts, Hauptwerk sends a special 'Launchpad reset sys-ex message' to (only) any connected Launchpads, which causes each Launchpad (amongst other things) to turn all of its internal LEDs off.

In my tests yesterday, I temporarily disabled sending of that sys-ex message yesterday, so that my Launchpad would be sent exactly (and only) the same MIDI messages that a standard MIDI note-on/off organ console would be sent. Without the special 'Launchpad reset sys-ex message' the Launchpad does indeed leave any defaulted-to-on lamps/stops on/lit after unloading the organ, as would be normal and expected for a MIDI organ console.

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.

It's very strange that any MIDI/state information from a previous organ/session could persist even after Hauptwerk has been exited and relaunched. (It certainly couldn't still be in Hauptwerk's memory.)

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.

I do have the Hauptwerk v2 versions of the Prib and Ott organs here, and they were probably simple organs internally, so I could try with those if needed.

To confirm and test the persistence of the problem across Hauptwerk relaunches, would you mind trying the following?:

1. Launch Hauptwerk confg 3.

2. Load the Prib (which has its Flute 4 defaulting to on).

3. Exit Hauptwerk.

4. Verify that the Flute 4's MIDI stop tab is still on upon your Wyvern. Turn it off.

5. Relaunch Hauptwerk confg 3.

6. Load the Ott.

7. Operate the Wyvern's stop tab that's auto-detected to an Ott stop. Verify that the Wyvern tab that was auto-detected to the Prib Flue 4 also lights incorrectly as before, i.e. that the problem has been reproduced.

Assuming, so:

- Exit Hauptwerk and repeat all of steps 1-7 again, but between steps 4 and 5 (i.e. when Hauptwerk isn't running), switch your Wyvern off, wait 30 seconds, then turn it back on again. Does the problem then still occur after steps 5-7? That should help to determine whether something is being cached within the Wyvern.

If the problem does still occur:

- Exit Hauptwerk and repeat all of steps 1-7 again, but between steps 4 and 5 (i.e. when Hauptwerk isn't running), switch your Wyvern off, shut the PC down, switch off all power to the PC and hardware from the mains (especially so that power is cut to the MOTU Microlite, to ensure any internal buffers are cleared), wait 30 seconds, then turn everything back on again. Does the problem then still occur after steps 5-7? That should help to determine whether something is being cached within the MOTU driver, Windows' MIDI system, or MOTU hardware.

Thanks again.

[mdyde]

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.

Hello Ken,

P.S. I've just noticed this reply from this morning -- my apologies. I think we must both have replied at the same time. In that case, no need for any further testing or files for now. I'll have a look at your backup file once I have it from Francois-- probably tomorrow, or maybe Monday.

Good evening, Martin.

I sent the file to Francois at Zendesk just before my friend arrived for the day at 11:30am. Therefore I hadn't realised that the Backup File had been returned as being too large for the Zendesk system. So Francois didn't receive it. I am sorry about that - I have only just returned to find that therefore you will not have had it.
Is there an alternative mechanism to send it? If not I'll have a look at placing it in a password protected directory on one of my servers.
Therefore, apologies for the delay. [PS: I have now read your suggestion of sending a diagnostic file rather than a Backup File. So: I am about to generate the latter and send it to Francois .....

Best wishes,

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

[mdyde]

Thanks again, Ken.

If you haven't already done it, you could just launch the relevant Hauptwerk configuration then create a diagnostic file and send that -- no need to repeat any of the tests prior to doing so. (The log within the diagnostic file would show when the previous backup file was created, so I can just look at the events leading up to that.)

Thanks, Martin - I managed to generate the Diagnostic File last evening on my return. I sent it off to Francois, and I have received notification that it arrived. So I imagine you'll have it soon.

I have also bought a new 4x4 MIDI Hub. I won't be able to install it and test for the "feature" immediately because everything in my instrument is hidden from view unless it needs to touched. But if it is found to be an issue with the MIDI Hub I will try it.

Continuing thanks for your attention ...

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

[mdyde]

Thanks, Ken.

I've just received the diagnostic file from Francois. Whilst I would be able to see your MIDI settings from it, you didn't have MIDI logging turned on, so I can't see what was being sent or received.

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.

Might it be possible to repeat that test in config 3, but this time with the MIDI logging general preference turned throughout the whole of the test, then create and send a new diagnostic file to Francois? (As before it would be important not to click on any other virtual controls or touch any other MIDI controls during the test, so that just the relevant MIDI events get logged.) Thanks in advance.

Good evening, Martin.

I have generated a new file as requested and passed it onto Francois. No doubt he'll be sending on to you.
I am pretty sure that line 309840:
<P>2024-02-03-16-44-36: INF:2561 Diag: OUT: MIDI note on: port: Console MIDI OUT 04 'TapCo-MIDI02-OUT' [=&gt; MIDIOUT2 (Tapco Link MIDI USB V], channel (1-16): 01, note (0-127): 020, velocity (0-127): 127. (Raw hex bytes: 90 14 7F.)</P>
is an example of the problem: it is in the St. Eucaire data, when the Eucaire is loaded AFTER the St Anne's has had its Sw>Gt Coupler set to always on.

Sorry it's taken us so long to get this far, but it does seem to me that there is a MIDI OUT Note On message coming from Hauptwerk - don't you agree? Feel free to correct me if I'm wrong!

Best wishes & thanks,

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

[mdyde]

Thanks, Ken. I'll have a look once I have it, and will let you know what I find.

[mdyde]

Hello Ken,

I've received your second diagnostic file -- thanks:

Hauptwerk Diagnostic File KSPENCER-2 20240202-MinimalHW-AC3.Diagnostic_Hauptwerk_gz

The filename is different (...KSPENCER-2...), but it seems to be byte-for-byte identical to the first, and the last timestamp in its log is 2024-02-02-22-52-13 (from Friday), with no logged MIDI messages in it.

Did you perhaps send the first file again by mistake (just renamed)?

Thankyou, Martin,and I apologise for sending the incorrect file.
I have now sent the correct file to Francois, so I hope it arrives to you safely.

I am having difficulty sending this reply to you as the forum is very unstable at the moment and disconnects when I attempt to send. I shall hope for third time lucky, and that the messages are not duplicated..

You will definitely see in the latest (correct) file that Hauptwerk does indeed send a MIDI OUT note on message to the St. Eustace Switch/LED assigned to Note Number 020 in the St Eucaire organ. This the Note Number of the "Always ON" control set up on the St. Anne's instrument loaded before the St. Eustace.

I'll be interested reading your judgement.

Best wishes,

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

[mdyde]

Thanks, Ken.

[mdyde]

Hello Ken,

I've had a look at your diagnostic file properly now:

In those two organs, you have (only) the following MIDI settings configured (all MIDI note-on/offs on MIDI channel 1, with 'matching MIDI output' to MIDI OUT port 2 on your Tapco interface):

- St. Annes Great Open Diapason Large 8: Note: 001 (which MIDI-OX lists as "C#-1"), default=off.
- St. Annes Swell to Great: Note: 020 (which MIDI-OX lists as "G#-0"), default=on.
- St. Eucaire Montre 8: Note: 001 (which MIDI-OX lists as "C#-1"), default=off.

Your logs show that the MIDI output messages being sent by Hauptwerk are definitely correct for those MIDI settings, e.g.:

- As St. Anne's unloads, note 001 is correctly set to its default state (off).
- As St. Anne's unloads, note 020 is correctly set to its default state (on).
- Once St. Eucaire is loaded, only note number 001 is sent.
- With St. Eucaire loaded, note number 020 is never sent,
- With St. Eucaire the state of note number is 001 is always correct: it turns on when you click on the Montre 8 to turn if on, and turns off when you click on it again to turn it off.
- No spurious or incorrect note-on/off messages are sent, and, in particular, only MIDI settings/events for St. Eucaire are sent with St. Eucaire loaded (no settings/events from St. Anne's).

I also loaded Hauptwerk here using your MIDI settings (general, plus for both organs), remapping your Tapco MIDI OUT 2 to my MOTU Microlite MIDI OUT 2, and repeated your test, and I get exactly the same results that you do, i.e. all MIDI output from Hauptwerk is absolutely correct, and my logged events correspond to yours.

To see whether something might be happening to those messages within my MOTU Microlite, I connected a MIDI cable from its MIDI OUT 2 port back to a spare MIDI IN port enabled in MIDI-OX (but not enabled in Hauptwerk). Here are the results:

1. Load St. Anne's. The two St. Anne's stops default correctly to their default states (Gt Op D L 8=off, Sw to Gt=on):

2. Unload St. Anne's. As the organ unloads, the two St. Anne's stops again default correctly to their default states (GtOpDL8=off, SwToGt=on):

3. Load St. Eucaire. The (only) St. Eucaire stop (note 001) defaults correctly to off, and no other MIDI note-on or note-off events are sent:

4. Click on the St. Eucaire Montre 8 (note 001). It correctly gets turned on, and no other MIDI note-on or note-off events are sent:

Hence in all of these tests Hauptwerk is indeed working correctly for you and for me, and so is my MOTU Microlite.

You report that two further things are happening on your MIDI console:

1. With St. Anne's loaded, the MIDI stop mapped to the St. Anne's SwToGt (note 020) is getting turned off as St. Anne's unloads.
2. With St. Eucaire loaded, the MIDI stop that was mapped to the St. Anne's SwToGt (note 020) is getting turned on whenever any other MIDI event is sent.

Hauptwerk definitely isn't telling your MIDI console to do either of those things, so whatever is doing it must be downstream of Hauptwerk, i.e. either in:

a) Windows 10's MIDI libraries: unlikely, since it doesn't happen with the Windows 10 version that I have.
b) Your MIDI console's firmware: pretty unlikely, since note 020 is getting turned off when the MIDI driver stops, and the console probably wouldn't know it was getting stopped.
c) Your Tapco interface's driver or firmware: I think that's by far the most likely. Probably the driver/firmware is automatically sending note-off messages for any MIDI note numbers that are still on when its driver is stopped, but then is somehow accidentally turning them back on again later whenever it next sends any other MIDI event.

If your set-up *was* doing what Hauptwerk tells it to do, note 020 would remain on when St. Anne's unloads and subsequently in St. Eucaire (because it was set to default to on in St. Anne's, and you don't have that MIDI stop mapped to anything in St. Eucaire). However, my understanding is that you'd prefer that didn't happen anyway.

Hence although Hauptwerk is working perfectly in your tests and mine, and as designed, your MIDI console is doing something it isn't being told to do, but you actually don't want it to do what Hauptwerk is telling it to do anyway, so troubleshooting the problem further would be largely pointless.

Here's what I suggest:

As I understand, you would prefer that Hauptwerk always defaults all mapped MIDI stops to off when unloading an organ (instead of to their user-specified default states), especially so that those MIDI stops are off if they aren't mapped to anything in subsequently-loaded organs. I will change Hauptwerk to do that for the next major Hauptwerk version.

In the meantime, I think a workaround for you would be simply to ensure that any such 'surplus' MIDI stops are always mapped to some virtual control in each organ. For example, you could map them to unused master reversible pistons, to ensure that they always get defaulted to off.

I was wondering why it would be useful to turn a MIDI control on when the organ is unloaded, if the "default to on" setting was for this organ and not for all organs. Or was that a global MIDI assignment and I missed it? I'll confess I haven't read every post in this topic, since there are a lot of them! Thanks.

Thanks for that, Martin.

I was really surprised by your result, because in line 351315 of the file I find:

P2024-02-03-16-38-01 INF2561 Diag OUT MIDI note on port Console MIDI OUT 04 'TapCo-MIDI02-OUT' [=&gt; MIDIOUT2 (Tapco Link MIDI USB V], channel (1-16) 01, note (0-127) 020, velocity (0-127) 127. (Raw hex bytes 90 14 7F.)P

which is exactly what I would have thought we need: in the Eucaire area of the log, we find note 020 being sent from Hauptwerk to the stop switch. I don't think I'm imagining it, but maybe I have failed to understand what we're looking for.
Maybe I failed to send the correct file (again!). Or is that line completely insignificant?

I'll be enormously interested in what you say!

Best wsihes,

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

[mdyde]

Hello Ken,

If you search the log to for that message by its timestamp (2024-02-03-16-38-01) you will see that St. Anne's is loaded at that time, not St. Eucaire. (E.g. scroll up a little from that timestamp; St. Anne's finished loading at 2024-02-03-16-37-36 and you don't then start to load St. Eucaire until 2024-02-03-16-38-41.)

Hence Hauptwerk is correctly sending that message from the St. Anne's Swell to Great coupler, because you configured that coupler to default to on within St. Anne's. At no point is note 020 sent with St. Eucaire loaded, so all is well.

I was wondering why it would be useful to turn a MIDI control on when the organ is unloaded, if the "default to on" setting was for this organ and not for all organs. Or was that a global MIDI assignment and I missed it? I'll confess I haven't read every post in this topic, since there are a lot of them! Thanks.

Hello Mark,

The defaulting behaviour hasn't changed since Hauptwerk v4.0, whereas the ability to auto-detect master/menu functions 'for all organs' wasn't added until v7. At the time it was introduced in v4 I think I probably decided it was slightly better for it to be left in its user-specified default state to avoid solenoid-actuated stops clicking off and on again spuriously, especially if the MIDI stop was assigned to the same/equivalent function in every organ. However, now that v7+ has the ability to assign master/menu functions 'for all organs' that's less of a consideration, so on balance now I think it would probably be better to change it always to defaulting them to 'off' whenever stopping MIDI. Also, that may help to avoid problems regarding hardware/drivers that maintain states of their own.