SysEx Problem with Kisselbach/Optimus 2.31

Hello, I'll help a german user with a sys-ex problem.
He wrote
"I have an Optimus 2.31 from Kisselbach, the manufacturer is actually Viscount.
Viscount is also found in the MIDI hardware detection in HW.
The integration of the stops and manuals worked immediately with the automatic detection.
But the pistons (first planned was "Gen Cancel") do not work."

Below is his Screenshot from Midi-OX and HW-Input-Field Viscount Stop: Viscount 6-byte constant sys-ex msgs

https://1drv.ms/i/s!Arwur74FVGgLhAktNJ7 ... -?e=4J91pN

Why are the first 2 lines disabled?
How do you enter the 6 bytes correctly?

Distributing a Sys-Ex command across the 2 columns seems a bit strange and inconclusive.

Best regards
Wolfgang

[mdyde]

Hello Woflgang,

Thanks for helping him.

As far as I know, that particular message type ("Stop: Viscount 6-byte constant sys-ex msgs") is sent/received by some Viscount organs for their stops, but not from their pistons.

On that Hauptwerk settings screen (with that event type selected), the "Momentary piston ('on' toggles/pulses/triggers virtual switch)" option is disabled, since stops need to know the 'on' message as well as the 'off' message. The left-hand column is for the 'on' message, and the right-hand column for the 'off' message. In each of those two, bytes 1, 2 and 6 (1-based numbering) are disabled because they are fixed and predetermined by the message type ("Stop: Viscount 6-byte constant sys-ex msgs").

Hence if, for example, that MIDI-OX screenshot (F0 31 2F 6C 00 F7) shows the Viscount's stop being turned on, and if he were to auto-detect that stop (first turning it on, and then off again, as prompted during auto-detection), he should see that the bytes in the left-hand column would have been configured/detected as follows:

- Byte 1 = [disabled, since it would always be F0]
- Byte 2 = [disabled, since it would always be 31]
- Byte 3 = 2F
- Byte 4 = 6C
- Byte 5 = 00
- Byte 6 = [disabled, since it would always be F7]

He should also see that the right-hand column had become populated as a result of the auto-detected stop (with the corresponding parameters for the 'stop-off' event).

The integration of the stops and manuals worked immediately with the automatic detection.
But the pistons (first planned was "Gen Cancel") do not work."

If auto-detection is succeeding when detecting the stops then there should be no need to change any of the settings for the stop on that screen -- auto-detection should have configured them all based on the MIDI messages it heard.

Some digital organs don't send any MIDI messages at all from their pistons (or only do so if a firmware option is set), and other digital organs simply (re-)send the states of all of their stops as a result of their own internal combination system having acted upon the piston press. In order for pistons to be usable with Hauptwerk the pistons would need to send unique, constant MIDI messages from each piston.

Also, it's important to be aware that one mustn't have both the digital organ's MIDI stops and its MIDI pistons auto-detected to Hauptwerk, otherwise the two combination systems will inevitably 'fight over' the states of the stops (see the "Playing Hauptwerk live from a digital organ" section in the main Hauptwerk user guide -- pages 272-273 in the current v8.0 version -- for more details).

If intending to use both the digital organ's stops with Hauptwerk, as well as its pistons to control Hauptwerk's own combination system, the digital organ's internal combination system would need to be disabled within its firmware. Unfortunately, most (maybe all) digital organs don't have that capability, to my knowledge.

Hence with a digital organ one normally needs to decide whether to use its stops with Hauptwerk, or its pistons, but one can't normally use both (to avoid the two combination systems fighting over the states of the stops).

[Edit: corrected byte 6 value in the example above.]

Many thanks, Martin.