Unexpected effect of a setting in Stop assignments.

Thanks, Martin!

Thank you, Martin, for the reply, and for your patience and attentive investigation.

It looks as though I shall have to adopt an alternative solution/workaround and put this rather odd behaviour of something in my system down to experience!
.
I think I will try my new MIDI Hub as soon as I can get time to swap them around. Do you have any hints on the most painless method of exchanging a MIDI Hub? I'm hoping that I can just swap the newly identified Hub over to the Aliases previously allocated to the Tapco Hub and its four IN/OUT ports, hopefully even though I will have disconnected the Tapco Hub first?

Best wishes,

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

[mdyde]

Thanks, Ken.

I think I will try my new MIDI Hub as soon as I can get time to swap them around. Do you have any hints on the most painless method of exchanging a MIDI Hub? I'm hoping that I can just swap the newly identified Hub over to the Aliases previously allocated to the Tapco Hub and its four IN/OUT ports, hopefully even though I will have disconnected the Tapco Hub first?

Yes -- I would recommend:

- Do a backup in Hauptwerk for good measure.

- Exit Hauptwerk.

- Disconnect the Tapco MID interface.

- Connect your new MIDI interface.

- Launch Hauptwerk. It will prompt you about missing devices. Select the option to mark the missing devices as temporarily offline.

- The "General settings | MIDI ports" screen will open. In the relevant four rows, change the ticked columns from your Tapco's MIDI IN ports to the new interface's equivalent ports. Do likewise for the MIDI OUT ports on the MIDI OUT tab.

Your existing MIDI settings should all then be retained and remapped to the new interface.

Do bear in mind, though, that even if changing the interface solves the underlying problem, it still wouldn't be doing what you're hoping for in terms of turning off unmapped but illuminated stops. I.e. those stops would remain lit if everything was working correctly.

To avoid that you could either use the work-around I mentioned:

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.

... or you could avoid having any stops set to default to on.

Martin: Sorry not to reply sooner.
I’ve been carrying out the tests you noted and failing to get a consistency in the results. However, I decided to go back to basics and look at the midi in and out of the Phoenix console which is supported by HW as a Wyvern / Phoenix console type (stops on are program change and stop off are program change on the next midi channel up).

I used MidiMedic to drive the console through the MOTU microlite interface. After observing the stop tab midi stream and lamps, I think I now can explain the apparently bizarre behaviour noted in my replies earlier in this thread.

First turning the console off for a few minutes, then turning it on to ensure it is reset to a normal starting state.

I sent the midi command to turn on one stop, stop A: the stop lamp light. I then physically turned stop A off at the console and the lamp went out: on the midi monitor I could see the stop off midi command being sent from the console.

I then sent midi command to turn on a different stop, stop B: the stop lamp for that stop B lit and so did the stop lamp for the stop A (that I had physically turned off). The one command I sent to turn on stop B could be seen in the midi monitor but there was no midi output from the console from turning on the lamp for stop A.

The Phoenix console seems to remember which stops were turned on and off via midi commands and restores these when it next receives a midi command affecting the stops ignoring any changes made physically.

This behaviour does not cause a problem in normal working with HW as HW sends back to the console the stop on and stop off commands it receives from the console. This works well for HW’s combination system too. It only causes a problem when a “default on” stop is turned on by HW when the organ with this setting is unloaded – turning it off physically at the console does not clear the Phoenix console’s “memory” that this stop has been turned on by a midi command. When a new organ is loaded that uses the tabs (but not the tab previously used for the “default on” stop), when other stops are changed the Phoenix console restores this stop to the state last set by a midi command affecting it (stop on, lamp on, in this case).

All of this would not be visible with the Phoenix console if Hauptwerk turned off all the stops for all the stops configured in a virtual organ including those with “default on”.

Iain

[mdyde]

Thanks very much, Iain.

How bizarre! Anyway, at least the change I've implemented for Ken for the next major version should solve it for your console too.

Iain, many thanks for that last post!

You really do seem to be experiencing exactly the same sequence of anomalous behaviour as do I. Of course, you say "... my Phoenix console then [does this and that], but what is happening in your console does seem to be the same as in my MIDI Hub.

I have fitted a replacement MIDI Hub into my console in the hope it might cure the issue, but it didn't! And, as you have said, there is no external sign of any signal, be it MIDI or otherwise that causes the behaviour. Maybe its the MIDI standard itself that's at fault?

I'd be really interested to find a Hauptwerk User who uses our kind of setup with a MIDI Hub and illuminated switches or moving drawstops that doesn't suffer from this little issue!

MARTIN: I'd be interested in any comments you may have about how you might resolve an issue that appears to be caused outwith Hauptwerk by making changes within Hauptwerk? I suppose that you might clear the "Default to On" component of the stop/coupler data set before an organ is unloaded, or something similar.

Anyway best wishes, both,

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

[mdyde]

MARTIN: I'd be interested in any comments you may have about how you might resolve an issue that appears to be caused outwith Hauptwerk by making changes within Hauptwerk? I suppose that you might clear the "Default to On" component of the stop/coupler data set before an organ is unloaded, or something similar.

Hello Ken,

I was referring to this change that I suggested previously, which presumably and hopefully would help with both your system and Iain's:

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.

[mdyde]

P.S. Re. your other points:

I have fitted a replacement MIDI Hub into my console in the hope it might cure the issue, but it didn't! And, as you have said, there is no external sign of any signal, be it MIDI or otherwise that causes the behaviour. Maybe its the MIDI standard itself that's at fault?

I'd be really interested to find a Hauptwerk User who uses our kind of setup with a MIDI Hub and illuminated switches or moving drawstops that doesn't suffer from this little issue!

N.B. Also, as I mentioned:

Do bear in mind, though, that even if changing the interface solves the underlying problem, it still wouldn't be doing what you're hoping for in terms of turning off unmapped but illuminated stops. I.e. those stops would remain lit if everything was working correctly.

I.e. If all the parts of of your system were working correctly in terms of putting the MIDI stops in the states that Hauptwerk's MIDI OUT messages are instructing them to be put, the MIDI stops would then stay illuminated when you unloaded the organ and loaded a different one in which those MIDI stops aren't mapped to anything. Since that isn't the behaviour that you actually want (as I understand) there probably isn't really much value in trying to get to that position. I.e. trying to solve the underlying hardware/firmware/driver issue (whichever it turns out to be) would be pointless anyway.

For now I'd recommend:

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.

Ken:
As I carried out my tests directly with the console (through the midi interface) and the monitor program, I’m sure the behaviour is due to the midi implementation in the console alone. For midi playback, the primary purpose of the console’s midi interface when I bought the console around 2003, this behaviour had the advantage trying to ensure the recorded registration was used. Having Hauptwerk turn off all the stops with configured midi stop controls would avoid any problems this behaviour could cause.

Iain

Thanks, Martin and Iain, for the latest replies.

As you suggest, we can possibly put this down to a difference in expectation: I would expect that the configuration of any organ sample set should not be affected by the configuration of any organ sample set which had been prevously loaded in the same session. Therefore I would expect that before loading the second organ, all consequences of the loading of the first organ would be obliterated - surely this is the case with all settings except the "Defaults to ON".

(Just to clarify one small point: In my case, and slightly different from Iain's case, my "Defaulted to ON" stops do actually extinguish when the organ containing the "Default to ON" setting unloads, rather than staying on. They only come back on after the second organ is loaded, and an assigned stop switch is pressed.)

It seems that Martin's proposal will reset any "Defaults to ON" effects on subsequently loaded organs, and that'll certainly suit me!

Best wishes,

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

[mdyde]

Thanks, Ken.

I would expect that the configuration of any organ sample set should not be affected by the configuration of any organ sample set which had been prevously loaded in the same session. Therefore I would expect that before loading the second organ, all consequences of the loading of the first organ would be obliterated - surely this is the case with all settings except the "Defaults to ON".

Just to be clear, nothing within Hauptwerk is directly setting the state of any given MIDI stop within any given organ unless you've mapped that MIDI stop to something within that particular organ (in which case Hauptwerk sets it to the default you specify). If a MIDI stop is mapped to a virtual stop in one organ, Hauptwerk simply leaves the MIDI stop in whatever state you specify for that organ when you unload it. If that particular MIDI stop isn't mapped to anything in a subsequent organ then it would still be in the state that Hauptwerk left it in from the previous organ (except that your MIDI hardware is turning it off and then on again later for some reason). It isn't the case that the 'configuration' of one sample set is affecting the configuration of another -- simply that one sample set is setting the state of the relevant MIDI stop (because you told it to), but another sample set isn't (because you didn't tell it to).

Strictly speaking, it wouldn't technically be possible in general that "all consequences of the loading of the first organ would be obliterated", because for that to be true Hauptwerk would need to put all of the MIDI stops back into the states in which they were before MIDI was started (e.g. when Hauptwerk was launched). I.e. it would need to be able to query the initial states of all of your MIDI stops. In general there's no way within the MIDI standard that Hauptwerk could do that (digital organ bit-field MIDI implementations, such as Rodgers', conceivably excepted). For example, you might have had a registration drawn on a digital organ, or you might have certain couplers on a digital organ which you would almost always want to remain on (e.g. ventils, combination couplers, or a bass coupler).

Simply assuming that all of the console's MIDI stops were initially off, and thus explicitly setting them to off whenever stopping MIDI is something that one may not conceivably not want (e.g. for some digital organ couplers/stops as above, or for solenoid-actuated MIDI stops), but overall I think think it would be an acceptable compromise given that in Hauptwerk v6+ master combinations and functions can optionally be auto-detected 'for all organs'. Hence that's the change I made, which should give the behaviour that you'd personally prefer (assuming that your MIDI hardware abides by those 'off' messages as MIDI stops).

One last clarification:

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.

Since in v6+ master combinations can be auto-detected 'for all organs', currently you could probably simply auto-detect each relevant one of your MIDI stops to 'surplus'/unused master reversibles on a 'for all organs' basis. Then in theory (assuming your MIDI hardware doesn't do anything unintended with the MIDI messages) any MIDI stop that isn't mapped to any per-organ control in any organ you load would default (back) to the default 'for all organs' state of the reversible, which would be 'off' by default. That would potentially avoid the need to map that MIDI stop to anything for any given organ if you wanted it to default to off but didn't need it use it for any virtual stops for that particular organ.

Alternatively, you could just wait for the next major Hauptwerk version, for the change (always default to off) that I implemented for you. Either way, since I've already implemented the change to make Hauptwerk do what you'd prefer, let's move on from this topic for now, please.

Thank you Martin.

Whilst waiting for the next relaesa I shall indeed try your suggestions, especially the "all organs" suggestion.

I completely accept that the issue can be closed, and of course I am pleased that what seems to be an acceptable solution has been implemented.

I must also say that I appreciate the time and effort which you have taken in explaining and investigating this matter.

Many thanks indeed, and best wishes,

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

[mdyde]

Thanks, Ken. You're very welcome.