Hi;
I've been dealing with a problem for the last few years with the HW system at the church I play for.
It happened very infrequently at first but progressively got worse. It finally got so bad, I went to the church 4 hours ahead of when a memorial service was scheduled and fought with the system for 2 hours until it decided to work.
The symptoms:
-HW unable to detect presence of MIDI resources despite all being reported by the Windows Device Manager as present and functioning properly. Closing HW and unplugging and plugging in the USB cable to the interface appeared to help with this. Swapping out the USB cable did not change the behavior.
-If HW was able to detect the presence of the MIDI resources, more and more frequently the computer would freeze when attempting to load a sampleset. Even things like Stopping/Restarting MIDI or File/Exit within HW would cause a freeze. There were no indications of a problem in the log file. At this point the only recourse was to restart the computer. I should also add that the main HW window would persist in a greyed out form if I used the task manager to terminate HW and the only way to get rid of it was to restart the computer.
-Once the system succeeded in loading a sampleset, it would work flawlessly for the entire playing session.
This last symptom really threw me off the path to solving the problem. How could the interface be bad if it would operate for hours without any issues? I thought there must be some esoteric thing was wrong with the PC. Well, it was the interface, a MOTU Express 128. I have installed my personal MOTU Microlite into the system and it's been working perfectly for the last couple of months. Swapping the Express 128 back in results in an immediate recurrence of the problem. I waited to share this with the forum until I was sure the problem was resolved and hope others will be spared much grief should their MIDI Interface fail.
MIDI Interface Problem
-
- Member
- Posts: 185
- Joined: Fri Apr 10, 2009 10:38 am
MIDI Interface Problem
Brooke Benfield
Organist, Gethsemane Lutheran Church
Portland OR
Organist, Gethsemane Lutheran Church
Portland OR
Re: MIDI Interface Problem
Thanks, Brooke.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: MIDI Interface Problem
Hello Brooke - in our church organ, we're running Windows 10, HW8, MOTU 24Ao & OPUS 2 controlling the console. The MOTU is connected via USB. We're seeing similar behavior to what you posted in July. Once everything loads, it seems stable. But it's a new installation and I am very concerned about long term stability.
At this point, we keep the MOTU & computer on with the HW organ loaded. We power cycle the console as it controls the speakers.
I assume the MOTU micro lite is what you use to control your console...??... Nevertheless, we see issues where the MOTU is visible through MOTU Discovery, but sound won't play. When MOTU is not available when HW loads, it give us the screen to cancel or mark the device as temporarily unavailable.
Most recently this occurred after backing up HW, then exiting HW and backing up the entire system. After system back up completed (to a USB connected solid state drive) I restarted HW and it loaded, including recognizing that the MOTU ASIO was on-line and then got no sound. After power cycling everything and restarting the computer multiple times, we had to restore the system backup to get everything working. Since that point (last Saturday), we've kept the system on as described.
I don't know enough about how you're using the micro lite to know, if this was inserted into the data path that we'd have a more stable interface. The OPUS is a stable interface to HW. It doesn't matter what state the console or HW is in. When both systems are up, it simply re-establishes MIDI and works flawlessly. So, I would not change that interface.
In the process of last Saturday's recovery, we did re-load the ASIO driver more than once (including uninstalling); but it took restoring to a previous version to get everything working.
Any thoughts would be appreciated.
At this point, we keep the MOTU & computer on with the HW organ loaded. We power cycle the console as it controls the speakers.
I assume the MOTU micro lite is what you use to control your console...??... Nevertheless, we see issues where the MOTU is visible through MOTU Discovery, but sound won't play. When MOTU is not available when HW loads, it give us the screen to cancel or mark the device as temporarily unavailable.
Most recently this occurred after backing up HW, then exiting HW and backing up the entire system. After system back up completed (to a USB connected solid state drive) I restarted HW and it loaded, including recognizing that the MOTU ASIO was on-line and then got no sound. After power cycling everything and restarting the computer multiple times, we had to restore the system backup to get everything working. Since that point (last Saturday), we've kept the system on as described.
I don't know enough about how you're using the micro lite to know, if this was inserted into the data path that we'd have a more stable interface. The OPUS is a stable interface to HW. It doesn't matter what state the console or HW is in. When both systems are up, it simply re-establishes MIDI and works flawlessly. So, I would not change that interface.
In the process of last Saturday's recovery, we did re-load the ASIO driver more than once (including uninstalling); but it took restoring to a previous version to get everything working.
Any thoughts would be appreciated.
Re: MIDI Interface Problem
Hello vrnback,
Some quick thoughts, in case they're relevant:
- Hauptwerk queries the audio and MIDI interfaces when it launches, and it expects them to remain present until it exits. It doesn't support 'hot-plugging' devices. If a connection is lost temporarily while Hauptwerk is running (e.g. due to a device going to sleep, or a USB connection getting dropped for some reason) then the device will stop working in Hauptwerk, and might cause a crash or freeze, until Hauptwerk has been restarted. Even if it has stopped working in Hauptwerk since it was launched (due to a lost connection), a device could potentially still appear to be present/working in Windows, or in the device's driver control panel, if they have since established a new connection to the device.
- If possible, make sure any USB audio or MIDI devices are connected to USB ports directly on the PC (not via a USB hub). If that isn't possible, make sure it's a good-quality 'powered' (not 'bus-powered') USB hub.
- Make sure that all relevant power-saving options are turned off in Windows and the PC's BIOS. In particular, make sure that 'USB selective suspend' is disabled:
Some quick thoughts, in case they're relevant:
- Hauptwerk queries the audio and MIDI interfaces when it launches, and it expects them to remain present until it exits. It doesn't support 'hot-plugging' devices. If a connection is lost temporarily while Hauptwerk is running (e.g. due to a device going to sleep, or a USB connection getting dropped for some reason) then the device will stop working in Hauptwerk, and might cause a crash or freeze, until Hauptwerk has been restarted. Even if it has stopped working in Hauptwerk since it was launched (due to a lost connection), a device could potentially still appear to be present/working in Windows, or in the device's driver control panel, if they have since established a new connection to the device.
- If possible, make sure any USB audio or MIDI devices are connected to USB ports directly on the PC (not via a USB hub). If that isn't possible, make sure it's a good-quality 'powered' (not 'bus-powered') USB hub.
- Make sure that all relevant power-saving options are turned off in Windows and the PC's BIOS. In particular, make sure that 'USB selective suspend' is disabled:
Disable all Windows power-saving functions, including the options for putting USB ports/devices to sleep. For example, on Windows 10 you would use 'Windows Control Panel | System | Power and sleep | Additional power settings', select the 'High performance' power plan, then click its 'Change plan settings | Change advanced power settings', then make sure that the settings are set as follows:
Sleep: Hibernate after = Never (for 'plugged in' if present)
USB settings: USB selective suspend setting = Disabled (for 'plugged in' if present)
PCI Express: Link state power management = Off (for 'plugged in' if present)
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: MIDI Interface Problem
Hi guys,
there is an issue with the firmware for the 128. If it doesn't get updated for a year or so it sulks, expecting an update and not always woking as expected. Re-installing the (faulty!) firmware fixes the unit until it expects its next update. MOTU issued an update that fixes the firmware on the XT version, but not the normal version. The XT behaves flawlessly with the newer firmware (it used to do the same thing). Either get the XT if you need the inputs, or re-flash the firmware once a year or so on the non-xt 128.
Tony
there is an issue with the firmware for the 128. If it doesn't get updated for a year or so it sulks, expecting an update and not always woking as expected. Re-installing the (faulty!) firmware fixes the unit until it expects its next update. MOTU issued an update that fixes the firmware on the XT version, but not the normal version. The XT behaves flawlessly with the newer firmware (it used to do the same thing). Either get the XT if you need the inputs, or re-flash the firmware once a year or so on the non-xt 128.
Tony
Re: MIDI Interface Problem
In addition to Martin's comments, please note that the MOTU 24Ao is an audio interface with no MIDI, while the original post's MOTU 128 is a MIDI interface with no audio. The only likely commonality is USB ports going to sleep because of incorrect Windows settings, or maybe that a (different) MOTU device is failing.