Unexpected effect of a setting in Stop assignments.

For a very long time I had noticed an odd effect whereby an assignment of one of my illuminated stop switches to a stop or coupler on one of my organ sample sets, seemed sometimes to be retained and passed to the next successively loaded sample set.

When I installed the Caen set a little time ago, I soon noted that part of the MIDI assignments of four of the Caen Anches Combs seemed to affect the corresponding same four stop switches of subsequently loaded [but not every one] organs.

Anyone without illuminated stop switches or solenoid driven drawstops would probably never notice this occurence because it seems that the feature only has an effect on the MIDI OUT destination: thus causing the LED to light, or the solenoid to pop out, even though it serves no function. Note that if said illuminated switch or draw stop has been assigned to a stop in that newly loaded organ the fault/effect does not occur.

I believe that I have now discovered where the fault/feature/buggette seems to lie: somehow, if a stop or coupler is assigned as ON by default (which we are entitled to do, are we not?) that setting is passed to the same stop or coupler of many, but not all, organs which might be loaded subsequently in the same HW session.

Here is a setting which provokes the effect:


I will look forward to receiving any opinions.

Many thanks, and belated seasons greetings to all!

Kenneth A. Spencer
==============

[mdyde]

Hello Kenneth,

Seasons greetings to you too.

Do I understand correctly that you mean that if you load an organ which has MIDI output configured from its virtual stops, and some of those virtual stops default to engaged, and you then load another organ which has no MIDI output at all configured from its stops (such as an organ loaded for the very first time, for which no MIDI settings have been configured yet), your MIDI stops may still default to engaged for those stops when the (new) organ finishes loading?

Thanks, Martin.

You almost have it but not quite: it's not something I've seen with a newly installed organ (though perhaps I should say I've never noticed it with such), but rather existing organs where those particular switches have not been assigned a role.

It isn't that the subsequently loaded organ has "no MIDI settings configured", but rather just none for the switches configured in the previously-loaded organ as defaulting to on. Also, I ought to clarify: the switches go off when the first organ ulnoads, and only come back on when the second organ is loaded, and selection of stops is made by piston or by hand.

If it helps, in my imagination, I am thinking that Hauptwerk reads the stop/coupler configuration when that first organ is loaded, and those settings go into memory. When that organ is unloaded, those stop/coupler settings might be unloaded, but I suspect that that only happens when the second organ's MIDI configuration is loaded or set up. But are all the parameters of the old configuration cleared? My guess is that they are not all cleared. Maybe the "Default to 'On'" option was an added feature and clearing that item was missed. That would also explain why, if there are no MIDI configurations for set as "Default to 'On'" this little feature never happens. Forgive me if my imagination is wrong - in programming there are so many ways of killing a cat!

I'll be interested to know what transpires!

Best wishes,

Ken

[mdyde]

Thanks, Ken.

It isn't that the subsequently loaded organ has "no MIDI settings configured", but rather just none for the switches configured in the previously-loaded organ as defaulting to on. Also, I ought to clarify: the switches go off when the first organ ulnoads, and only come back on when the second organ is loaded, and selection of stops is made by piston or by hand.

Regarding the quote excerpt that I've underlined above, do you mean that the relevant MIDI stops come on once the organ has finished loading, even if you don't touch any MIDI controls at all and don't click on anything on the screen or computer keyboard?

Also, please try:

- Use "File | Backup ..." so that we can get your MIDI settings back in case we need to clear some of them to narrow it down.

- Load the 'first' of your two organs (the one that intentionally defaults those stops to on).

- Temporarily turn on the "General settings | General preferences | Diagnostics: log all MIDI messages received and sent" setting and OK the screen and performance warning.

- Verify that the intended virtual and MIDI stops default to on.

- Now load the 'second' organ (the one for which those MIDI stops are getting turned on unintentionally).

- Without touching anything else (so that the relevant MIDI messages can be told apart in the log), use "Help | View diagnostic log".

- Look backwards from the end of the log until the last "INF:5098 Audio started" line. Straight after it, you should see any MIDI messages that Hauptwerk is sending as the new organ resets for the first time after being loaded. Here's an example for an organ which has only one virtual stop configured for MIDI output (MIDI note-on/off on channel 3, note number 60), with that virtual stop set to default to engaged:

...
2024-01-26-21-05-12: INF:5098 Audio started.

2024-01-26-21-05-12: INF:2561 Diag: OUT: MIDI note on: port: Console MIDI OUT 01 [=> micro lite: Port 1], channel (1-16): 03, note (0-127): 060, velocity (0-127): 127. (Raw hex bytes: 92 3C 7F.)

2024-01-26-21-05-12: INF:2505 Audio and MIDI started.
...

Please copy/paste all of those lines (including the INF:5098 and INF:2505 lines that surround them). Thanks.

Thanks again, Martin.

I will do the MIDI data collection over the weekend and let you have it as soon as I've done it.

Regarding the quote excerpt that I've underlined above, do you mean that the relevant MIDI stops come on once the organ has finished loading, even if you don't touch any MIDI controls at all and don't click on anything on the screen or computer keyboard?

The stops configured to be ON by default on the first organ only come on after the second organ has been loaded AND after a stop on that second organ has been drawn, or a thumb piston selecting some stops has been pressed. Thus, the troublesome stop switches don't reveal themselves until you've hit a configured thumb piston or stop.

Just now, I edited the stop configuration of the first organ (The Caen), negating the "Switch defaults to 'On'" option. And that resolved the issue in the second organ. Of course I will put back the option to default to ON before carrying out your test.

Of course it is always possible that the fault is in Caen data - I almost contacted Sonus Paradisi first, but as I had encountered the error going back a few years, I did consider that it would be more likely to be something in the software, and I think the resluts of the above test do suggest that.

One other factor is that my instrument is rather more complicated than the average, with 120 stop switches across the two stop jambs, 128 electronic textual stop labels (hardware designed and software written my myself), and with a complete central control console managing Organ Sample Sets, Combination Sets & Temperaments, Audio & MIDI Recording, Expression Pedal positions, and full Stepper/Sequencer control and setup (also all hardware designed and software written by me). Whenever any little issue like this arises its tempting to think it's my error!

Anyway thanks for your attention & help,

Ken

Kenneth Spencer

[mdyde]

Thanks, Ken.

The stops configured to be ON by default on the first organ only come on after the second organ has been loaded AND after a stop on that second organ has been drawn, or a thumb piston selecting some stops has been pressed. Thus, the troublesome stop switches don't reveal themselves until you've hit a configured thumb piston or stop.

In that case, when conducting the test, please use these modified steps instead (modified steps are highlighted in bold):

- Use "File | Backup ..." so that we can get your MIDI settings back in case we need to clear some of them to narrow it down.

- Load the 'first' of your two organs (the one that intentionally defaults those stops to on).

- Temporarily turn on the "General settings | General preferences | Diagnostics: log all MIDI messages received and sent" setting and OK the screen and performance warning.

- Verify that the intended virtual and MIDI stops default to on.

- Now load the 'second' organ (the one for which those MIDI stops are getting turned on unintentionally).

- Without touching anything (so that the relevant MIDI messages can be told apart in the log), wait about 15 seconds (so that logged messages can be told apart by their timestamps).

- Still without touching anything else, press (just once) a MIDI piston that would trigger the problem.

- Still without touching anything else, use "Help | Create a diagnostic file ..." and save it somewhere for reference (in case we need to look through your MIDI settings for the organ).

- Still without touching anything else, use "Help | View diagnostic log".

- Look backwards from the end of the log until the last "INF:5098 Audio started" line. Straight after it, you should see any MIDI messages that Hauptwerk is sending as the new organ resets for the first time after being loaded, then the "INF:2505 Audio and MIDI started ..." message, then after a few seconds (by timestamp) you should the MIDI messages that were sent and received as a result of your piston press. Please post the whole of that section (everything from "INF:5098 Audio started" until "INF:2507 Stopping audio and MIDI", including those two surrounding messages).

- Please also let us know which of those sent logged MIDI messages is causing your MIDI stop to turn on incorrectly.

Thanks Martin.

Sorry not to have replied yesterday, but in the middle of my investigations yesterday, I had a call asking me to play for a service this morning, when I wasn't expecting to play again until next Sunday! And there was some stuff that I hadn't played before so it took all my attention.
However, I have now had a careful look through the file from "INF:5098 Audio started" to "INF:2507 Stopping audio and MIDI", and I have found references to the Thumb Piston which I pressed to cause the illumination of the unconfigured stop switches, They do share a certain amount of configuration data:
- the Thumb piston (in the Moco-LUFA device) have note numbers of 43 IN and 42 OUT;
- the Stop Switch inthe Rt Jamb has the MIDI IN and MIDI OUT note numbers of 41-44 (both IN and OUT).
But their devices and channels differ and all are explicitly specified.
The firing of MocoLUFA note 043 IN and 43 OUT is noted in line 4591 of the MIDI report, but I can't really see any report of it's effecft on the MIDI Port for the RtJamb. This is the line:

20240127-14-29-42: INF:2562 Diag: OUT: MIDI note off: port: Console MIDI OUT 01 'KeyBdStack+ThumbPistonsOUT' [=> MocoLUFA], channel (1-16): 16, note (0-127): 043, velocity (0-127): 127. (Raw hex bytes: 8F 2B 7F.)

I couldn't quite see how I could send the MIDI data by file, and the log is too long for the forum interface. Perhaps there is an alternative by which I can send you the full LOG data.

Thanks so much for your help. I'll look forward to any comments!

Best wsihes,

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

[mdyde]

Thanks, Ken.

Just as a sanity check, I've been having a play with St. Anne's and the MDA Salisbury sample sets, with some stops and pistons configured in each for MIDI note-on/off input and output, and with some stops defaulting to 'on' in St. Anne's, then switching back and forth between the two sets. In all cases that I tried, states were correct in both sample sets. It should be impossible within Hauptwerk for organ MIDI settings (which include whether stops default to 'on'), or stored stop states, or combinations, from one organ (OrganID) to affect any other because all of those items are entirely organ-specific and fully unloaded and deleted from memory whenever any organ unloads (as will happen when loading a different organ, for example).

A quick thought: the OrganID within an organ's organ definition file is supposed to identify the organ uniquely globally. (Sample set producers request them from MDA from a centrally-allocated pool to ensure uniqueness.) All organ MIDI settings, stored stop states, and combinations, are stored relative to the OrganID. If two organ definitions accidentally had the same OrganID, then settings/states/combinations from one may well affect the other.

When an organ has finished loading (from sample set cache), if you use "Help | View activity log" the "INF:2157 The organ ... has been loaded ..." message will show you the OrganID.

Some questions:

- Do the OrganIDs of your two organs (Caen, and the other one that the Caen's settings seem to be affecting) match? (If so, that's the problem.)

- Also, you mentioned that the problem only occurs when you press a piston. Does the problem still occur if you load the organ and don't touch anything at all on your MIDI console, and instead click on the corresponding virtual piston?

- How about if you exit Hauptwerk, switch off your MIDI console entirely (and/or unplug all MIDI cables to/from it), and then relaunch Hauptwerk (if any MIDI devices are reported as missing, select the option to mark them as temporarily offline) and try loading the two organs in turn, and clicking on the relevant piston in the second? (That could help to eliminate any possibility of something being stored/fed-back from the MIDI console.)

[mdyde]

- How about if you exit Hauptwerk, switch off your MIDI console entirely (and/or unplug all MIDI cables to/from it), and then relaunch Hauptwerk (if any MIDI devices are reported as missing, select the option to mark them as temporarily offline) and try loading the two organs in turn, and clicking on the relevant piston in the second? (That could help to eliminate any possibility of something being stored/fed-back from the MIDI console.)

P.S. To clarify: since your MIDI console would be off/disconnected, you would need to look at the graphical virtual console's stop states to see whether the problem still occurred, and/or look at the logged MIDI-out events.

Thanks Martin, and I appreciate the time and effort on this one. Thus far, I can report:

1. The Caen and the Buckeburg have distinct OrganIDs according to the activity log.

2. The problem with removing the MIDI devices (which I have done) and looking at the virtual organ on the screen, is that the issue only occurs when the stop switches assigned as "ON" by default in the first organ, have no allocation in the second organ. Thus their state is not visible in the virtual image of the second organ, as they do not control any stops, pistons or couplers of the second organ (unless there is an approach which I have not thought of.)

I had wondered whether the MIDI decoder was getting a state somehow retained from the first organ, but the fact that the LEDs go off when the first organ is unloaded and only come on when a stop/coupler/piston selection is made in the second organ surely means that a rogue MIDI signal must be happening somehow?

Would it help if I could send you the MIDI Activity log somehow, in case you can see something in the data relating to the second organ's MIDI events that I cannot see?

(As an aside I was wondering whether this might be an unintended "feature" of the decoders - Christian Blanchard of France - which are currently in my stop jambs. But once again, the LEDs are extinguished correctly between organs.

I'll keep trying any other ideas that occur!

So many thanks, and best wsihes,

Ken
--
Kenneth A. Spencer

[mdyde]

Thanks, Ken.

2. The problem with removing the MIDI devices (which I have done) and looking at the virtual organ on the screen, is that the issue only occurs when the stop switches assigned as "ON" by default in the first organ, have no allocation in the second organ. Thus their state is not visible in the virtual image of the second organ, as they do not control any stops, pistons or couplers of the second organ (unless there is an approach which I have not thought of.)

I think you could still try it as follows:

- Exit Hauptwerk.

- Switch the MIDI console off and disconnect all MIDI cables.

- Launch Hauptwerk. If there are warnings about any missing MIDI devices, select the 'mark offline' option.

- Make sure the MIDI logging preference is still turned on.

- Using just the mouse, load the first organ (Caen, with the relevant virtual stop still defaulted to 'on').

- Without touching anything else, use the mouse to load the second organ.

- Without touching anything else, click on the virtual piston that would normally would trigger the problem.

- Use "Help | Create a diagnostic file ..." and save the file somewhere safe, in case you need to send it to us.

- Use "Help | View activity log".

Is the specific problematic MIDI OUT message (which would normally turn on the MIDI stop incorrectly) still logged as having been sent?

Thank you Martin ...

I am about to follow the instructions which you posted above (your most recent relative to this one), but I have one more comment to make:
I failed previously to mention what happened when I followed your instruction to operate a virtual stop or piston of the second organ, in order to see whether that, too, generated the error, and yes it does. That is loading the first organ, unloading it, loading the second organ (at this stage still with MIDI stop jambs connected) pressing a virtual stop: this produced the problem in exactly the same way as selecting a MIDI switch for a coupler, stop or piston does.

I am about to follow your instruction removing the stop jamb MIDI connection, and then your very latest instructions (Mon 29th Jan, 2024 4:25 pm - my time has it 15:56!) and I'll generate the diagnostic file and get back to you ...

Thanks again,

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

Good evening, Martin.

It is taking me quite a long time to "get my head around" the activity log. However, I now have an offline readable copy of the log showing HW activity & behaviour from the LOADing of the Caen to the UNLOADing of the Buckeburg. All that is bound to include my virtual organ drawstop actions amongst all the many other records.

I do wonder whether somehow there may be a retention of some previous configurations of MIDI devices as I have already found some MIDI OUT messages which address a Decoder using Note Numbers that not been used for several years, and that are sent, but as they are out of range for the current configuration of the present MIDI decoders they have no effect.

I am hoping that tomorrow I shall be able first to locate the MIDI messages which turn on a virtual stop in the Caen, and then in the Buckeburg, and then those which turn on the offending switch LEDs at the root of the issues.

In the meantime, thanks again for your help!

Ken
--
Kenneth A. Spencer

Greetings, again, Martin.

Having disconnected the MIDI Hub serving the stop jambs, I started Hauptwerk, and initiated the diagnostic data collection.
I loaded the Caen organ.
I selected a virtual stop which I knew would illuminate a switch, but of course at this stage I could not see any change to the illuminated switches of either jamb.
I deselected the stop, and unloaded the Caen organ.
I loaded the Buckeburg organ.
I tapped a virtual stop which I knew would illuminate a switch, but course was unable to see it.
I deselected the stop, and unloaded the Buckeburg organ.

I selected the activity file vewer from the help menu. As there is a lot of irrelevant data, I saved only the data from the starting of Hauptwerk today, to the unloading of the Buckeburg organ.

I could not quite see how to identify the operation of virtual stops, other than by their resultant MIDI messages. Having said that, nor could I find any evidence of spurious or incorrect MIDI OUT messages that would falsely turn on one of the affected stop switch LEDs.

It seems that I have these options:

1. Continue and take a more detailed review of the data;
2. Turn off all use of "Stop defaults to ON" for the offending switches, (probably for any switches, as I am fairly sure it
isn't an issue with specific switches or MIDI OUT lines);
3. Always allocate these switches to stops or couplers in other organs.

I wonder whether anyone else might have noted this behaviour? I must add that it isn't only the Caen (as the organ
with the use of "Switch defaults to ON" - there are others, nor is it only the Buckeburg which suffers the resultant rogue
illumination of the stop switches. I suspect that it is general. Of course it could also be my Decoders, but it can be made to affect the decoder in either jamb.

I would value any comments, and thanks for your help.

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

[mdyde]

Thanks, Ken.

I could not quite see how to identify the operation of virtual stops, other than by their resultant MIDI messages. Having said that, nor could I find any evidence of spurious or incorrect MIDI OUT messages that would falsely turn on one of the affected stop switch LEDs.

To confirm, do you mean that the particular (problematic) MIDI OUT message from Hauptwerk is present if the MIDI console is on/connected, but not if it's off/disconnected?

Do you know for certain which MIDI OUT message(s) could turn on the problematic stop on your MIDI console?

Here's another test you could try:

- Turn on and reconnect your MIDI console.

- Make sure you have a current backup from Hauptwerk.

- In Hauptwerk, on the "General settings | MIDI ports | MIDI IN ports" screen tab, untick all columns, so that no MIDI input at all (no MIDI IN ports) is enabled in Hauptwerk (no ticks at all in any row or column). Leave the MIDI OUT ports unchanged, so that MIDI output will still be sent, but no MIDI input will be received.

- See whether you can still reproduce the problem using just the mouse, and if so look in the log to try to determine which specific MIDI OUT message is triggering it.

That test should help to determine whether the problem is occurring as a result of your MIDI console unintentionally triggering something in Hauptwerk (which would be impossible if no MIDI IN ports are enabled in Hauptwerk).