It is currently Fri Mar 29, 2024 11:41 pm


specific auto-detect problem

Hauptwerk software technical support only. Please make sure you have read the manual, tutorials and FAQ pages before requesting support.
  • Author
  • Message
Offline

Thob3769

Member

  • Posts: 24
  • Joined: Thu Dec 12, 2019 11:52 am

specific auto-detect problem

PostSat Apr 09, 2022 3:16 pm

Using V7 adv HW, I am unable to auto-detect the combination stepper's up-one-step virtual control. Ditto any of the stepper frames I programmed. Nor was I able to turn on the new V7 all pistons stepper +1 and get it to function as described. I have run out of ideas having done the following: rebooted the program and my Mac; successfully set up virtual combinations then auto detected them with the same piston I want for the +1 function -NOT the "all pistons stepper +1 - after which I reset all midi/key trigger settings and tried again to auto-detect the up one control; tried to auto detected +1 on a different virtual organ. Not to mention reading User Guide registration section starting on page 91 and paying particular attention to the section starting on 105 re: combination stepper. Finally I checked out any postings in this Tech Support forum related to Auto-detect issues with H7.

Help will be most appreciated!

Tom
Offline

mnailor

Member

  • Posts: 1602
  • Joined: Sat Nov 30, 2013 5:57 pm
  • Location: Atlanta, GA

Re: specific auto-detect problem

PostSat Apr 09, 2022 3:44 pm

(deleted)
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostSat Apr 09, 2022 4:00 pm

Hello Tom,

What type of MIDI pistons/console are you trying to auto-detect to the virtual control panel buttons? (There is one, and only one, known bug in v7.0.0 above v6, whereby the two rows of round buttons on Novation Launchpads [which send MIDI control-change messages] won't currently auto-detect to control panel buttons, but auto-detection works properly for everything else.)

Please also:

- Load the St. Anne's organ (since we all have convenient access to that).

- Use "Organ settings | Organ configuration wizard" to reset all MIDI settings for the organ.

- Make sure that the "Audio, MIDI and Performance" large control panel is visible (e.g. via "View | Large floating control panels".

- Press the MIDI piston/button which you had been trying to auto-detect. As you do so you should see one (and only one) of the green 'Console MIDI IN' channel number virtual LEDs (1-16) flash on the control panel. (The non-numbered green virtual LED will flash too, which is fine, but only one of the numbered LEDs should flash, indicating the MIDI channel on which MIDI messages are being received.)

If one (and only one) of those numbered green virtual LEDs flashes then it indicates that your MIDI console is successfully sending MIDI messages on a single MIDI channel from your MIDI piston to the computer.

Does that happen for you?

If so:

- Make sure the "Combination stepper all" large control panel is open.

- Try to auto-detect your MIDI piston to its stepper current frame increment function (the right-arrow button to the right of the current frame number).

Does that work for you?
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

Thob3769

Member

  • Posts: 24
  • Joined: Thu Dec 12, 2019 11:52 am

Re: specific auto-detect problem

PostMon Apr 11, 2022 7:24 am

Thanks for your help, Martin.

I am using a 2002 Johannus Opus 30. I selected from it swell thumb piston #3 after resetting the Midi settings. Indeed I observed the green led # 3 and the non-numbered led light up when pushing that piston.

Next I auto-detected to connect both sw thumb #3 on St A and my Johannus. Subsequently I had control from the latter to the former.

Next I used auto-detect to clear all settings for St A thumb 3 and then tried to auto-detect “stepper cued 1s digit + “ First I double-checked that my Johannus sw #3 still showed green leds as before. It did but I was unable to auto-detect when I pushed that button. The only option was to cancel.

Then I tried to auto-detect “stepper trigger cued x00” and again was not able to detect it.
I tried to auto-detect St A great thumb #3 with my Johannus swell #3 and it worked perfectly.

Next I fussed around and did & observed the following:

reset using wizard, did NOT use auto-detect but just on a whim pushed Joh. General 1 and it moved stepper from 000 to 001…subsequent pushes did nothing

reset using wizard, auto-detected Joh Gen 1 to “stepper:trigger +1” , saw green leds 1-4 and non numbered, pushed “DONE” then tried Joh Gen 1 which did nothing whatsoever

reset w/ wizard, auto-detected Joh Gen 1, “Done” lit up but -on a whim again - pushed Joh Gen 1 and Cancel lit up

finally, reset w/ wizard, auto-detected Joh sw #1 to St A sw #1, done lit up and stayed lit when I repeatedly pushed my Joh sw 1.

I recognize that this is more than you asked me to do but I hope it is helpful.

Appreciatively,

Tom
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostMon Apr 11, 2022 9:04 am

Thanks, Tom.

From your description, I suspect that currently your Johannus isn't actually sending distinct, constant MIDI messages from its pistons, and is probably instead sending changes in the states of the Johannus' own stops resulting from pressing the Johannus combination pistons. I.e. probably it's sending its internal combination system's stop state changes, not piston messages directly. It might also be (re-)sending the positions of its expression pedals as you press its pistons.

To be usable reliably with Hauptwerk you really need it to be sending distinct, constant MIDI messages directly from its pistons themselves.

I managed to find a PDF copy of the manual for the Johannus Opus 30 on the Internet, and it says that it has two MIDI OUT ports: "MIDI MOD" and "MIDI SEQ". The MIDI implementation chart in the manual doesn't mention anything about its pistons sending MIDI directly:

JohannusOpus30MidiImplementation.jpg


However, I think I recall hearing from another Johannus use that some Johannus models do send MIDI directly from their pistons (maybe MIDI sys-ex messages) via the MIDI SEQ port.

I'd suggest:

- In Hauptwerk, on the "General settings | General preferences" screen, make sure that the "MIDI hardware/console type" is set to "Unmodified MIDI digital/electronic organ: Johannus".

- Make sure that the computer's MIDI IN port is connected to the Johannus' MIDI SEQ port (not MIDI MOD).

- For good measure, also make sure that its divisional "MIDI" stop switches are all off (although I think they might not be relevant via the MIDI SEQ port anyway).

- (After resetting MIDI settings in Hauptwerk again), see whether that allows its pistons now to be auto-detected reliably. If not:

- Turn on a few of the Joahnnus' own stops (so that its registration is not initially blank).

- In Hauptwerk, temporarily turn on the "Diagnostics: log all MIDI messages received and sent" option on the "General settings | General preferences | Advanced ..." screen tab and OK the screen (and OK the warning about performance).

- Without touching anything (in Hauptwerk, and on your Johannus), wait 30 seconds or so, so that the relevant MIDI messages can be identified by their timestamps.

- Still without touching anything else (so as to avoid other actions being logged to confuse the issue), press the Johannus piston Swell piston 1, then wait about 10 seconds, then press it again, the wait 10 seconds, then press the Johannus piston Swell piston 2, wait 10 seconds, press it again, and repeat for each of its other divisional and general combination pistons in turn [leaving about 10 seconds between each, and avoiding touching anything else].

- Use "Help | Create a diagnostic file" and save it somewhere for reference, in case you need us to look at it.

- Use "Help | View activity log", and have a look at the MIDI messages that Hauptwerk received from each of those piston presses.

If it's sending MIDI in a useful format, you should see just one MIDI message being sent as a result of any given piston press (e.g. a single MIDI sys-ex message), and that MIDI message should always be the same when that particular piston is pressed, regardless of the states of the Johannus stops, and the MIDI message from any given piston should be distinct from that from any other piston.

Is that the case? [If so and its pistons are sending control-change messages then you would fall foul of the known bug in v7.0.0, but I've never heard of a digital organ console that sends MIDI control changes from its pistons, so I think that's very unlikely to be applicable.]
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

Thob3769

Member

  • Posts: 24
  • Joined: Thu Dec 12, 2019 11:52 am

Re: specific auto-detect problem

PostMon Apr 11, 2022 7:37 pm

Thanks, Martin.

Before I try this, I want to clarify exactly what I am to do:

First that my M-Audio Midisport 2X2 which then connects to a Mac USB is actually the "computer's MIDI In port". Yes?

Side note: for years, my Midisport has been connected to Joh Mini Mod - the original installation by my son-in-law who assisted me. All seemed to work fine that way. Having said that, the connection currently is to Midi Seq port and I pretty certain that happened accidentally by me - I recall that I had reason to disconnect and reconnect all connections last fall. I suspect that because of the awkwardness of seeing the connection upside down, I connected it to Seq when I meant to pick Mod since that is what my son-in-law had done and even wrote down for my future reference. This would explain, I think, a curiosity that I came to discover by chance a few months ago: I no longer need to use the Joh midi stops to play a HW instrument. Your comment on this would be appreciated.

Please clarify "turning on a few stops" - should it be on each division? Finally, where you describe pressing SW piston 1 and the procedure following it then Sw #2 followed by repeating process for GT, CH & Ped, do you mean just #1 and #2 for each. How about Gen toe studs ?

Thanks -Tom
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostTue Apr 12, 2022 3:52 am

Thanks, Tom.

Thob3769 wrote:First that my M-Audio Midisport 2X2 which then connects to a Mac USB is actually the "computer's MIDI In port". Yes?


Yes -- I meant the MIDI IN port on your MIDI interface (i.e. whichever MIDI IN port you're currently using on your Midisport 2x2).

Thob3769 wrote:Side note: for years, my Midisport has been connected to Joh Mini Mod - the original installation by my son-in-law who assisted me. All seemed to work fine that way. Having said that, the connection currently is to Midi Seq port and I pretty certain that happened accidentally by me - I recall that I had reason to disconnect and reconnect all connections last fall. I suspect that because of the awkwardness of seeing the connection upside down, I connected it to Seq when I meant to pick Mod since that is what my son-in-law had done and even wrote down for my future reference. This would explain, I think, a curiosity that I came to discover by chance a few months ago: I no longer need to use the Joh midi stops to play a HW instrument. Your comment on this would be appreciated.


Indeed the MIDI implementations and behaviour will be different depending on whether you use the MIDI MOD or MIDI SEQ port, and the states of the Johannus division's 'MIDI' stops will only relevant if using the MIDI MOD port.

I believe Johannus users usually use the MIDI SEQ port with Hauptwerk, so for the test I suggested above check that you're using that port for now. (If it turns out that your Johannus doesn't send usable piston messages via that port then we could instead investigate the MIDI MOD port.)

Thob3769 wrote:Please clarify "turning on a few stops" - should it be on each division?


A few stops on each division should be ideal. (My reason for suggesting having some stops on is just to try to help to determine whether the Johannus is is also/instead sending stop-state-change messages as you press pistons.)

Thob3769 wrote:Finally, where you describe pressing SW piston 1 and the procedure following it then Sw #2 followed by repeating process for GT, CH & Ped, do you mean just #1 and #2 for each. How about Gen toe studs ?


Ideally press every Swell piston twice, then every Great divisional piston twice, then every Choir piston twice, then every Pedal piston twice, then every General piston twice, leaving about 10 seconds between each piston press.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

Thob3769

Member

  • Posts: 24
  • Joined: Thu Dec 12, 2019 11:52 am

Re: specific auto-detect problem

PostWed Apr 13, 2022 2:58 pm

Hello Martin,

I finally found time to follow your latest suggestions:
I verified that indeed Midi In is connected to Johannus MIDI SEQ and NOT Mini Mod. I made sure all Joh midi stops were off and reset Hauptwerk Midi settings and failed to auto-detect the first piston I tried - Sw thumb #1.

I proceeded the tedious process of turning on Diagnostics after selecting 2 stops for each Joh division
Waited 30 secs and went thru 2 presses (except maybe when I got distracted and couldn't remember if I had already done 2 and guessed)...started swell pistons then great, choir, generals, pedal, pedal general studs. Created the file and saved and viewed. Don't understand why the file starts with version 6 last year...scrolled down forever and found today's activity 4/13 around 14 28 which I interpret to mean 2:28 pm here...and I assume the 2 digit number attached means seconds - such that 2022-14-13-28-53 would mean April 13 at 2:28 and 53 seconds here. Anyhow, the bottom line is I can't correlate what the log shows with the piston pushing that I spent 20 some minutes doing. My fear is that many of the pushes did not register. Suspect I need to send you the log which I saved on my desktop. Kindly describe the best way to do this so I know it will receive your attention.

Continuing thanks...

Tom
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostThu Apr 14, 2022 3:41 am

Thanks, Tom.

You can send us the diagnostic file via:

https://www.hauptwerk.com/submit-ticket/

(I think you probably need to be logged into your account on MDA's on-line shop in order to be able to use that function.)

Please also mention this forum topic in the ticket, so that Francois (who handles support email) will know what it relates to.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostThu Apr 14, 2022 4:05 am

P.S. Just for reference:

Thob3769 wrote:Don't understand why the file starts with version 6 last year...


The log files go back for a while so that one can look back through them for previous events that might be relevant to current problems if needed, but the oldest historical data is automatically purged from them eventually, to avoid excessive drive space usage.

Thob3769 wrote:..scrolled down foreve


If you view the log using Hauptwerk's standard "Help | View activity log" menu function then it will automatically scroll to the end for you when it opens the log. Failing that, pressing the 'End' computer key makes most Web browsers scroll directly to the bottom/end.

Thob3769 wrote:found today's activity 4/13 around 14 28 which I interpret to mean 2:28 pm here...and I assume the 2 digit number attached means seconds - such that 2022-14-13-28-53 would mean April 13 at 2:28 and 53 seconds here.


Date/time-stamps in the log use 'international' date formats and 24-hour time, formatted like this: YYYY-MM-DD-HH-MM-SS, so that they can easily be sorted alphabetically into date/time order if needed.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

Thob3769

Member

  • Posts: 24
  • Joined: Thu Dec 12, 2019 11:52 am

Re: specific auto-detect problem

PostThu Apr 14, 2022 7:55 am

Hi Martin,

I just created & sent a ticket with attached diagnostic file and notations you suggested.

Thanks.

Tom
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostThu Apr 14, 2022 7:57 am

Thanks, Tom.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: specific auto-detect problem

PostThu Apr 14, 2022 2:08 pm

Hello Tom.

When you did that test (pressing every one of the Johnannus pistons twice, in turn), the only MIDI messages that the Johannus sent to the computer were these:

Code: Select all
2022-04-13-14-28-45: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 005. (Raw hex bytes: CB 04.)
2022-04-13-14-28-45: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 009. (Raw hex bytes: CB 08.)

2022-04-13-14-33-26: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 021. (Raw hex bytes: CB 14.)
2022-04-13-14-33-26: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 023. (Raw hex bytes: CB 16.)

2022-04-13-14-37-07: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 035. (Raw hex bytes: CB 22.)
2022-04-13-14-37-07: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 036. (Raw hex bytes: CB 23.)

2022-04-13-14-40-46: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 058. (Raw hex bytes: CB 39.)
2022-04-13-14-40-46: INF:2552 Diag: IN: MIDI program change: port: Console MIDI IN 01 [=> MIDISPORT 2x2 Anniv A ], channel (1-16): 12, program number (1-128): 060. (Raw hex bytes: CB 3B.)


Currently, your Johannus' pistons aren't themselves sending MIDI messages. Instead, the Johannus is only sending messages from its MIDI stops (=program changes on MIDI channel 12, as in the MIDI implementation chart from the Johannus' user manual), so the MIDI messages (if any) that it sends just depend upon whatever registration you happen to have drawn on the Johannus at the time, and on what registration your happen to have stored to the Johannus' internal combination system for the one of its pistons that you press.

Hence as it stands its pistons aren't really usable with Hauptwerk. Unless any other Johannus Opus owners (or your son-in-law, or Johannus themselves) know of some way to get your Johannus to send MIDI messages directly from its pistons, I think the only work-around that you might be able to do would be to programme a single different Johannus stop to each of the Johannus' combinations (pistons), then cancel the Johannus registration (turn all stops off) prior to auto-detecting the piston to Hauptwerk.

However, that could never really be satisfactory, since you would not be able to use any given Johannus piston more than once in a row (since the first press would put the Johannus registration into that Johannus piston's stored state, so no MIDI messages would be sent the second and subsequent presses). Hence it would never work for things like trying to increment Hauptwerk's stepper frame by pressing the same Joahnnus piston repeatedly.

Really I think the only satisfactory option would be not to use the Johannus pistons with Hauptwerk at all, and instead to buy something like a Novation Launchpad Mk2, so that you could use its buttons for triggering Hauptwerk pistons/buttons.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

Thob3769

Member

  • Posts: 24
  • Joined: Thu Dec 12, 2019 11:52 am

Re: specific auto-detect problem

PostThu Apr 14, 2022 11:05 pm

I truly appreciate your patience with this, Martin.

Let me give you one example of what I do not understand: on 4/09 you had me check one piston to see if only one numbered green led flashes which it did. If so, you said that my JOH is successfully sending Midi messages. Yet on 4/11 you described a procedure that said to make sure all JOH midi stops were off. That seem puzzling to me since I already knew that if the midi stop is off, no led lights would flash indicating no message had been sent. And when I looked at the diagnostic file I could tell that my 10 second intervals of pressing all thumb pistons sequentially were not all recorded. So was that because none of the midi stops were on?

A larger question is why is this problem seemingly caused by updating to Version VII? Although with Version VI there were a few registration glitches now and then, I was always able to auto-detect as desired. What do you think the explanation for this is?

Finally, I would be very receptive to getting a Novation Launchpad. Do you know where/how I will find support to figure out how to connect and use with my JOH ?

Thank you so much in advance for your assistance.

Tom
Offline
User avatar

IainStinson

Member

  • Posts: 1391
  • Joined: Tue Dec 29, 2009 6:08 pm
  • Location: NW England, UK

Re: specific auto-detect problem

PostFri Apr 15, 2022 4:57 am

I faced a similar problem with my Phoenix console some years ago - the pistons did not send midi data which was useful for Hauptwerk. My solution was to disconnect the piston switches from the Phoenix electronics, and connect them to a midi encoder. The midi encoder converted the press of each piston to midi note on / note off which Hauptwerk auto detected as a piston press. Hauptwerk then changed the stop selection to match the stored combination for that piston. I used a MidiBoutique encoder.

(I had an old Johannus and I found the access to the piston wiring was convenient as the keyboard stack was hinged.)

The pistons only work for Hauptwerk, but could readily be restored to work on the Phoenix by restoring the original connections.

The Phoenix stops (lighted tabs) work correctly with this arrangement because they respond to the midi sequence sent by Hauptwerk when it turns on a stop as a result of a piston combination change. Does your console have lighted tab stops? From the midi implementation chart, I think your stops should respond to Hauptwerk sending midi commands. You can readily test this by
- autodetect some stops on the console, checking they work, ie pressing them turns the virtual organ stop on and off.
- Turn on some stops
- then using the HW large registration panel, setting this to general pistons 1 on the control panel (set stops on console, press set on the control panel, press General 1 on the control panel, press set once more to turn setting mode off),
- clearing all the stops, then press General 1 on the control panel should restore the combination you saved. This should change the stops on the real console if it respond to Hauptwerk sending midi commands to control the stops.

The LaunchPad would, of course, work well, but the controls would not be in the key slips and less convenient to access whilst playing.

Best of luck.

Iain
Next

Return to Technical support

Who is online

Users browsing this forum: No registered users and 7 guests