Hello all.Each time you push the "Mem+" piston, the console of a Viscount organ sends 8 different SysEx messages. Hauptwerk does not recognize this action in auto-detect but can be configured to receive one of the eight messages. Unfortunately, the other 7 messages saturate the system and make the "next combination" button not in use (in Hauptwerk) after the first operation. I then have to restart the audio hardware midi. Curiously, this blockage occurs with the organ of Esztergom but not with a Willis organ of Octopus. It is therefore impossible to operate "next combination" from a console Viscount to certain instruments. Am I the only one to encounter this problem?

I put my configuration in my signature. It'll be easier for the future questions. I don't use any wireless connection, only a normal cable between my Midi interface (integrated in the sound card) and my console. No virtual Midi cable software AFAIK... Thank you for your interest in my problem.

What is the 'Mem+' piston on your Viscount designed to do normally, when using the Viscount on its own, without Hauptwerk? Is it a 'next' piston that's used in real-time during a performance to advance through the Viscount stepper frames, similar to Hauptwerk's right-arrow button to the right of its stepper frame number display?:

Or does it have some kind of non-performance combination editing or bank-selection function?

Does it send exactly the same (byte-for-byte) string of MIDI sys-ex messages it's pressed, or can they vary? Does pressing it cause any other controls on the Viscount to transmit MIDI messages, or change the way they behave subsequently, or change the MIDI messages they send subsequently?

You could check by temporarily turning on MIDI logging in Hauptwerk ('General settings | General preferences | Advanced ...' screen tab), pressing the piston and other controls a few times, then looking in the log to see what Hauptwerk received ('Help | View activity log'). If you leave a few seconds between operating each control/piston, then it should be easier to tell their messages apart in the log, by their timestamps.

Unfortunately, the other 7 messages saturate the system and make the "next combination" button not in use (in Hauptwerk) after the first operation. I then have to restart the audio hardware midi. Curiously, this blockage occurs with the organ of Esztergom but not with a Willis organ of Octopus.

Are you trying to use the Esztergom sample set's native combination stepper (the one in its virtual console), or Hauptwerk's (the one on Hauptwerk's Registration large control panel)?

Exactly which virtual control have you configured to respond to the sys-ex message with the Esztergom? One on the sample set's virtual console (which one, and on which screen tab if so)?

Or the stepper frame right-arrow on the Registration large control panel? Or the corresponding control on another control panel or piston toolbar?

Do you have it configured to trigger multiple virtual controls simultaneously?

Can you clarify what goes wrong in the Esztergom sample set after the first piston operation? What happens on Hauptwerk's Registration large control panel?

Does the same thing happen if you instead click on exactly the same virtual piston/button that you configured to be triggered with the sys-ex message?

Have you definitely entered the sys-ex message correctly in Hauptwerk (you can verify by looking at the results from MIDI logging), including the 'sys-ex start' (F0) and 'sys-ex end' (F7) bytes? If the message isn't being terminated properly then that would explain why subsequent piston presses aren't working.

If you temporarily instead re-configure the virtual 'next' function that you're using to be triggered by a MIDI key (use auto-detection), rather the the Viscount's mem+ sys-ex function, does everything then work properly?

It is therefore impossible to operate "next combination" from a console Viscount to certain instruments. Am I the only one to encounter this problem?

Can you reproduce the problem with the St. Anne's sample set? Is it only the IA Esztergom sample set that has the problem? Do any non-IA sets exhibit it too?

I've also emailed a test build for you to try.

Best regards,Martin.

[Please use email or the Contact page if you need to contact us privately, rather than private forum messages.]

2) Your question about which combination stepper I use is very interesting. I was using Esztergom's system but after tesing Hauptwerk's system I discovered that it works. I took the first message (F0 31 28 5C 00 F7) and programmed it manualy as an 'On' message. Your reaction gave me the opportunity to resolve my problem in this way. However, I must regret not being able to use the interface of Esztergom for two reasons: the display of the combination is greater, and I must add a window Hauptwerk, which shrinks the window of Esztergom.

3) When Esztergom's stepper has been used one time in this way, it doesn't work at all, neither by the Midi nor the manual control on the touch screen. This is therefore a question for Inspired Acoustics.

Please let us know whether the build I sent you to try resolves the issue (although I think it's fairly unlikely). If not then please see if instead temporarily auto-detecting the Esztergom's piston to respond to a MIDI keyboard key (note-on/off) works (to try to eliminate the possibility of anything relating to MIDI interface/driver buffers flooding due to the large amount of sys-ex data). (Make sure you clear the MIDI settings for Hauptwerk's own stepper, so that you aren't trying to use both steppers at the same time, which might result in them 'fighting over' the states of the virtual stops.)

If not, then I think it's probably something you'll need to raise with Inspired Acoustics, since it sounds like it might be some sort of issue within the sample set itself.

Best regards,Martin.

[Please use email or the Contact page if you need to contact us privately, rather than private forum messages.]