Crash!
Crash!
In addition to my audio routing issue I have a system that frequently crashes.
Processor: 11th Gen Intel Core i7-11700 @ 2.50 GHz
RAM: 64 GB
Windows 10 home
I'm using separate MIDI interfaces for input and output because I was hoping this would fix the problem (I thought I had a bad MIDI interface)
My console is self-built using MIDI Buotique HWCE2max for encoding and all MIDI Boutique decoder boards.
This is a full console configuration system with moving stops and a full piston compliment.
About 20 % of the time, when hitting a piston, there is a "grand" cipher and the computer shuts down. I recently unassigned the control to shut the computer down (I have a switch wired to a MIDI input and assigned to the menu function.) When I did that, i still get the grand cipher only now the computer doesn't shut down. It's as if when sending large blocks of data by pressing a piston, Hauptwerk is sending additional note ON messages, one of which was the signal to trigger the menu to shut down the computer.
What might cause this crash? It certainly seems to be a Hauptwerk problem.
Also this is in a Church installation so it is REALLY problematic!
Processor: 11th Gen Intel Core i7-11700 @ 2.50 GHz
RAM: 64 GB
Windows 10 home
I'm using separate MIDI interfaces for input and output because I was hoping this would fix the problem (I thought I had a bad MIDI interface)
My console is self-built using MIDI Buotique HWCE2max for encoding and all MIDI Boutique decoder boards.
This is a full console configuration system with moving stops and a full piston compliment.
About 20 % of the time, when hitting a piston, there is a "grand" cipher and the computer shuts down. I recently unassigned the control to shut the computer down (I have a switch wired to a MIDI input and assigned to the menu function.) When I did that, i still get the grand cipher only now the computer doesn't shut down. It's as if when sending large blocks of data by pressing a piston, Hauptwerk is sending additional note ON messages, one of which was the signal to trigger the menu to shut down the computer.
What might cause this crash? It certainly seems to be a Hauptwerk problem.
Also this is in a Church installation so it is REALLY problematic!
Re: Crash!
It sounds like some MIDI gear is faulty. Hauptwerk doesn't send out extra Note ON messages, it just receives them (and optionally echoes it back on the same port for a lighted/moving control if so configured).
(I don't see how it could work to use two different MIDI interfaces for input and output from and to the same MIDI controller. But maybe there are advanced options for that which I've never needed to look into.)
Could you explain what's connected to what by MIDI and MIDI/USB cables in this setup?
And have you done every step in the Windows tuning list in the Hauptwerk 7.0 Installation and User Guide under the Performance Tuning section? Including running HW in realtime priority as Admin. If not, that would be a good thing.
(I don't see how it could work to use two different MIDI interfaces for input and output from and to the same MIDI controller. But maybe there are advanced options for that which I've never needed to look into.)
Could you explain what's connected to what by MIDI and MIDI/USB cables in this setup?
And have you done every step in the Windows tuning list in the Hauptwerk 7.0 Installation and User Guide under the Performance Tuning section? Including running HW in realtime priority as Admin. If not, that would be a good thing.
Re: Crash!
Hello Mark Fischer,
To add to Mark Nailor's reply, you could try temporarily turning on the "General settings | General preferences | Advanced preferences | Diagnostics: log all MIDI messages received and sent" option in Hauptwerk and OK the screen. Then use "View | activity log" after pressing your piston (if it hasn't crashed, otherwise do it after restarting), to see the exact MIDI messages that the console sent to Hauptwerk what they triggered in Hauptwerk, and what MIDI messages (if any) Hauptwerk sent in response.
To add to Mark Nailor's reply, you could try temporarily turning on the "General settings | General preferences | Advanced preferences | Diagnostics: log all MIDI messages received and sent" option in Hauptwerk and OK the screen. Then use "View | activity log" after pressing your piston (if it hasn't crashed, otherwise do it after restarting), to see the exact MIDI messages that the console sent to Hauptwerk what they triggered in Hauptwerk, and what MIDI messages (if any) Hauptwerk sent in response.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: Crash!
Thank you both for the responses. All performance tuning items have been set and all unnecessary software uninstalled or disabled. I did omit running with priority as Admin so I will fix that.
I disabled the MIDI control to shut down the computer. When I did that and the issue occurred, the computer did not shut down.
This is very much looking like a MIDI encoder issue. It seems as though when certain controls are used, several other "phantom" Note ON messages are being sent. Since one of those note on messages initiated computer shut down, it seemed as though the computer was crashing when it was just shutting down.
The multiple MIDI interfaces were installed as an attempt to address this issue. I think we can go back to one interface!
Martin, I will log the MIDI messages and take a look at the results.
I disabled the MIDI control to shut down the computer. When I did that and the issue occurred, the computer did not shut down.
This is very much looking like a MIDI encoder issue. It seems as though when certain controls are used, several other "phantom" Note ON messages are being sent. Since one of those note on messages initiated computer shut down, it seemed as though the computer was crashing when it was just shutting down.
The multiple MIDI interfaces were installed as an attempt to address this issue. I think we can go back to one interface!
Martin, I will log the MIDI messages and take a look at the results.
Re: Crash!
Thanks, Mark. Hope you manage to resolve it easily.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: Crash!
Mark and Martin,
I'm still having trouble with this system and not yet 100% certain that the problem is with my MIDI hardware.
I am using a MIDI boutique HWCE2x encoder board. I understand that you do not support 3rd party hardware but I also want to be certain that this is not a software issue. There is also a decoder board that controls SAMs. Both the pistons and stop sense on the SAMs use hall sensors.
I had mentioned that Hauptwerk was sending MIDI NOTE ON messages. I should clarify that what happens is that when a piston is pressed, several stops and notes go on and off for about a second then several then remain on, causing a grand cipher. Originally, I had a piston configured to shut down the computer (this one is not hall sensor). Once I had unassigned the shut down menu function from the midi switch, the computer no longer shut down when the problem occurred.
When I enabled logging of all MIDI data, I was not able to experience the problem but the data was clearly slowed down as expected. When pistons were pressed, stops turned on and off more sequentially. When the log is disabled, the stops are nearly simultaneous.
I certainly appreciate the expertise from you both and hope that perhaps you could shed further light on the situation.
I'm still having trouble with this system and not yet 100% certain that the problem is with my MIDI hardware.
I am using a MIDI boutique HWCE2x encoder board. I understand that you do not support 3rd party hardware but I also want to be certain that this is not a software issue. There is also a decoder board that controls SAMs. Both the pistons and stop sense on the SAMs use hall sensors.
I had mentioned that Hauptwerk was sending MIDI NOTE ON messages. I should clarify that what happens is that when a piston is pressed, several stops and notes go on and off for about a second then several then remain on, causing a grand cipher. Originally, I had a piston configured to shut down the computer (this one is not hall sensor). Once I had unassigned the shut down menu function from the midi switch, the computer no longer shut down when the problem occurred.
When I enabled logging of all MIDI data, I was not able to experience the problem but the data was clearly slowed down as expected. When pistons were pressed, stops turned on and off more sequentially. When the log is disabled, the stops are nearly simultaneous.
I certainly appreciate the expertise from you both and hope that perhaps you could shed further light on the situation.
Re: Crash!
Hello Mark,
Another possibility is that a hardware MIDI buffer is getting flooded within the computer's MIDI interface, or within a MIDI encoder or MIDI decoder.
I'd suggest:
- Make sure you're using a good-quality well-buffered MIDI interface from a reputable music brand (e.g. MOTU Microlites are well-proven). (Cheap/unbranded ones sometimes lose or corrupt MIDI messages and/or flood.)
- Make sure your console's MIDI pistons never set the states of its MIDI stops directly. A MIDI stop should only ever change state if the user physically changes it, or if Hauptwerk specifically instructs it to. (If using both MIDI pistons and MIDI stops with Hauptwerk then the console must not have any kind of combination system of its own.)
- Make sure each of your console's MIDI stops sends 'stateful' MIDI messages, such as a MIDI note-on as it turns on, and a corresponding (same MIDI channel and MIDI note number) MIDI note-off message as it turns off (not 'toggling' messages whereby exactly the the same message is sent as it turns off to that sent as it turns on).
- Likewise, make sure each MIDI stop receives 'stateful' MIDI messages, such as a MIDI note-on to turn it on, and a corresponding MIDI note-off to turn it off. Ideally it should receive the same messages that it sends (e.g. MIDI note-on/off with the same MIDI note number and same MIDI channel), so that MIDI output can be configured automatically in Hauptwerk when auto-detecting.
- Make each of your console's MIDI stops doesn't send any MIDI messages at all if it changed state in response to a MIDI message from Hauptwerk. I.e. it shouldn't 'echo back' state changes.
- Make sure that no other part of the console directly feeds MIDI messages that it receives back to the computer (e.g. a 'MIDI Thru loop'), otherwise MIDI feedback is very likely.
- When auto-detecting each stop in Hauptwerk, make sure that you turn the MIDI stop on, and then off again, so that Hauptwerk hears both MIDI messages and knows that the MIDI stop is 'stateful' (not toggling).
- For those stops that you've already detected, check (e.g. via right-click "Adjust manually ..."), on the "Primary input" tab, that the detected MIDI message is a stateful event type, and what you expected it to be (e.g. the "Stop or hold piston: MIDI note-on/off" event type). Also make sure that the "Momentary piston ('on' toggles ...)" option is NOT ticked. On the "Primary output" tab, check that the event type is "Auto MIDI output (match to primary input settings" (assuming each MIDI stop receives the same MIDI message types/values that it sends) and, for good measure, that the "Always suppress output (echo) if direct response to input" option is ticked.
- On the "General preferences | Advanced ..." screen tab in Hauptwerk, check that the "Limit MIDI OUT port send rate to MIDI 1.0 baud" option is ticked (as it is by default).
For testing, you might find it easier to trouble-shoot using just a small number of stops, configured from all-default settings:
- Exit Hauptwerk if it's running.
- Launch Hauptwerk via a 'spare' 'Hauptwerk (alt confg N)' configuration (desktop shortcut) .
- Use 'File | Revert all settings to factory defaults' within that configuration to ensure that all of its settings are (still) at their defaults. (Hauptwerk will exit after you revert the settings.)
- Re-launch that same 'Hauptwerk (alt confg N)' configuration, and select your audio and MIDI devices when prompted but leave all other settings at their defaults.
- Load St. Anne's (since we all have access to it, and it's simple and very proven).
- Auto-detect a few MIDI pistons to the virtual pistons on the St. Anne's virtual console.
- Auto-detect just a few MIDI stops.
- See whether you can still reproduce the problem. If not, auto-detect the rest of the stops.
When a piston is pressed, if any given stop sometimes changes state more than once ('flickering' on/off) then I'd suspect that you have some kind of MIDI timing or feedback problem for which the console is sending one state for the stop at the same time that Hauptwerk is sending the opposite state, resulting in oscillation. That can occur if stops are sending 'toggling' MIDI messages, rather than 'stateful' ones, and/or if the console is 'echoing back' stop-state changes to Hauptwerk, and/or if Hauptwerk is configured to echo back stop-state changes to the console, and/or if there is MIDI feedback through the console, and/or if pressing the MIDI piston on the console directly causes the console to transmit or change any of its own stops. The latter is usually the cause if using a digital organ console, as a result of its internal combination system 'fighting over' the states of the stops with Hauptwerk's combination system.megafisc2 wrote:I had mentioned that Hauptwerk was sending MIDI NOTE ON messages. I should clarify that what happens is that when a piston is pressed, several stops and notes go on and off for about a second then several then remain on, causing a grand cipher.
Another possibility is that a hardware MIDI buffer is getting flooded within the computer's MIDI interface, or within a MIDI encoder or MIDI decoder.
I'd suggest:
- Make sure you're using a good-quality well-buffered MIDI interface from a reputable music brand (e.g. MOTU Microlites are well-proven). (Cheap/unbranded ones sometimes lose or corrupt MIDI messages and/or flood.)
- Make sure your console's MIDI pistons never set the states of its MIDI stops directly. A MIDI stop should only ever change state if the user physically changes it, or if Hauptwerk specifically instructs it to. (If using both MIDI pistons and MIDI stops with Hauptwerk then the console must not have any kind of combination system of its own.)
- Make sure each of your console's MIDI stops sends 'stateful' MIDI messages, such as a MIDI note-on as it turns on, and a corresponding (same MIDI channel and MIDI note number) MIDI note-off message as it turns off (not 'toggling' messages whereby exactly the the same message is sent as it turns off to that sent as it turns on).
- Likewise, make sure each MIDI stop receives 'stateful' MIDI messages, such as a MIDI note-on to turn it on, and a corresponding MIDI note-off to turn it off. Ideally it should receive the same messages that it sends (e.g. MIDI note-on/off with the same MIDI note number and same MIDI channel), so that MIDI output can be configured automatically in Hauptwerk when auto-detecting.
- Make each of your console's MIDI stops doesn't send any MIDI messages at all if it changed state in response to a MIDI message from Hauptwerk. I.e. it shouldn't 'echo back' state changes.
- Make sure that no other part of the console directly feeds MIDI messages that it receives back to the computer (e.g. a 'MIDI Thru loop'), otherwise MIDI feedback is very likely.
- When auto-detecting each stop in Hauptwerk, make sure that you turn the MIDI stop on, and then off again, so that Hauptwerk hears both MIDI messages and knows that the MIDI stop is 'stateful' (not toggling).
- For those stops that you've already detected, check (e.g. via right-click "Adjust manually ..."), on the "Primary input" tab, that the detected MIDI message is a stateful event type, and what you expected it to be (e.g. the "Stop or hold piston: MIDI note-on/off" event type). Also make sure that the "Momentary piston ('on' toggles ...)" option is NOT ticked. On the "Primary output" tab, check that the event type is "Auto MIDI output (match to primary input settings" (assuming each MIDI stop receives the same MIDI message types/values that it sends) and, for good measure, that the "Always suppress output (echo) if direct response to input" option is ticked.
- On the "General preferences | Advanced ..." screen tab in Hauptwerk, check that the "Limit MIDI OUT port send rate to MIDI 1.0 baud" option is ticked (as it is by default).
For testing, you might find it easier to trouble-shoot using just a small number of stops, configured from all-default settings:
- Exit Hauptwerk if it's running.
- Launch Hauptwerk via a 'spare' 'Hauptwerk (alt confg N)' configuration (desktop shortcut) .
- Use 'File | Revert all settings to factory defaults' within that configuration to ensure that all of its settings are (still) at their defaults. (Hauptwerk will exit after you revert the settings.)
- Re-launch that same 'Hauptwerk (alt confg N)' configuration, and select your audio and MIDI devices when prompted but leave all other settings at their defaults.
- Load St. Anne's (since we all have access to it, and it's simple and very proven).
- Auto-detect a few MIDI pistons to the virtual pistons on the St. Anne's virtual console.
- Auto-detect just a few MIDI stops.
- See whether you can still reproduce the problem. If not, auto-detect the rest of the stops.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: Crash!
Thank you so much Martin for your thorough response.
I had not had the box ticked for "Always suppress output (echo) if direct response to input" on the output pages ticked. I also had the "Limit MIDI out port send rate to MIDI 1.0 baud" unticked.
So far, the system works when it works. Meaning - at least twice when the organ is loaded (it is a CODM organ) the combination system does not work, including the on screen pistons. Keys and stops function as expected.
I had not had the box ticked for "Always suppress output (echo) if direct response to input" on the output pages ticked. I also had the "Limit MIDI out port send rate to MIDI 1.0 baud" unticked.
So far, the system works when it works. Meaning - at least twice when the organ is loaded (it is a CODM organ) the combination system does not work, including the on screen pistons. Keys and stops function as expected.
Re: Crash!
Thanks, Mark. You're very welcome.
Hope that's solved it.
Hope that's solved it.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: Crash!
We have had at least two instances when the computer was started and the combination system did not work. This included clicking on the on-screen pistons, including the General Cancel. Everything else worked as expected such as keys and stops.
Again, keep in mind that this is a CODM organ.
Here is the CODM file: https://drive.google.com/file/d/1XGPXjn ... sp=sharing
Thank you again for your continued support.
Mark
Again, keep in mind that this is a CODM organ.
Here is the CODM file: https://drive.google.com/file/d/1XGPXjn ... sp=sharing
Thank you again for your continued support.
Mark
Re: Crash!
Thanks, Mark.
The link to your CODM organ definition file is password-protected, but I doubt the CODM ODF is relevant anyway, since the CODM format is quite simple and robust. (Also I wouldn't be able to load it without the rest of your sample set, and I wouldn't really have enough time to study it in depth, I'm afraid.)
I would suggest:
- Make sure you're using a good-quality well-buffered MIDI interface from a reputable music brand (e.g. MOTU Microlites are well-proven). (Cheap/unbranded ones sometimes lose or corrupt MIDI messages and/or flood.)
- For good measure, test the PC's RAM for thoroughly for errors.
- Likewise test its drive for errors.
- Also for good measure, try re-installing the current (v7.0.0) version of Hauptwerk. You can leave all options in the installer at their defaults, so that your existing settings, combinations and organs won't be lost. Before running the installer, verify that the installer file that you're using has exactly the following size and MD5 checksum:
Windows:
InstallHauptwerk_v7.0.0.136.exe
MD5 checksum: f96fc0ad4f74392e594d528df4231dc2
3.00 GB (3,229,062,512 bytes)
(If not, try downloading it again.)
- Just in case the compiled ODF is actually partly corrupted, use "Design tools | Load custom organ ..." to re-load it (causing it to recompile). On the "Load Organ Design Options" screen that appears, make sure that the options are set exactly as follows (to ensure that the ODF gets fully validated and that the sample set cache gets regenerated, in case it's corrupted):
If that doesn't solve it, next time the problem with the combination system not working occurs, first check that the setter or Scope aren't on. Assuming that doesn't solve it, without touching anything else, try temporarily completely disconnecting all MIDI leads from the PC, being extremely careful not to disconnect the MIDI interface(s) from the PC (which would be very likely to cause a crash since Hauptwerk would be running and using them). Now, using just the mouse, see whether clicking on the virtual General Cancel turns the virtual stops off successfully. Also verify that stops can still be turned on/off by clicking on them and that they produce sound when you click on keys.
The link to your CODM organ definition file is password-protected, but I doubt the CODM ODF is relevant anyway, since the CODM format is quite simple and robust. (Also I wouldn't be able to load it without the rest of your sample set, and I wouldn't really have enough time to study it in depth, I'm afraid.)
I would suggest:
- Make sure you're using a good-quality well-buffered MIDI interface from a reputable music brand (e.g. MOTU Microlites are well-proven). (Cheap/unbranded ones sometimes lose or corrupt MIDI messages and/or flood.)
- For good measure, test the PC's RAM for thoroughly for errors.
- Likewise test its drive for errors.
- Also for good measure, try re-installing the current (v7.0.0) version of Hauptwerk. You can leave all options in the installer at their defaults, so that your existing settings, combinations and organs won't be lost. Before running the installer, verify that the installer file that you're using has exactly the following size and MD5 checksum:
Windows:
InstallHauptwerk_v7.0.0.136.exe
MD5 checksum: f96fc0ad4f74392e594d528df4231dc2
3.00 GB (3,229,062,512 bytes)
(If not, try downloading it again.)
- Just in case the compiled ODF is actually partly corrupted, use "Design tools | Load custom organ ..." to re-load it (causing it to recompile). On the "Load Organ Design Options" screen that appears, make sure that the options are set exactly as follows (to ensure that the ODF gets fully validated and that the sample set cache gets regenerated, in case it's corrupted):
If that doesn't solve it, next time the problem with the combination system not working occurs, first check that the setter or Scope aren't on. Assuming that doesn't solve it, without touching anything else, try temporarily completely disconnecting all MIDI leads from the PC, being extremely careful not to disconnect the MIDI interface(s) from the PC (which would be very likely to cause a crash since Hauptwerk would be running and using them). Now, using just the mouse, see whether clicking on the virtual General Cancel turns the virtual stops off successfully. Also verify that stops can still be turned on/off by clicking on them and that they produce sound when you click on keys.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: Crash!
Martin,
This installation is quite a distance from me so I have been unable to try the potential solutions listed in your last post. My customer is going to be putting the computer on line soon so I should be able to try most everything remotely.
The customer reports that every time Hauptwerk is started and the custom organ loaded the combination system does not work. I have mapped a button to trigger Engine: Audio/MIDI: Restart and Engine: Reset: Entire Organ. It is the same button for both functions so that probably is not good. When the customer presses that button, the combination system then works normally.
I'm wonder if this bit of additional information might be helpful in determining the problem.
Thanks so much for your help.
Mark
This installation is quite a distance from me so I have been unable to try the potential solutions listed in your last post. My customer is going to be putting the computer on line soon so I should be able to try most everything remotely.
The customer reports that every time Hauptwerk is started and the custom organ loaded the combination system does not work. I have mapped a button to trigger Engine: Audio/MIDI: Restart and Engine: Reset: Entire Organ. It is the same button for both functions so that probably is not good. When the customer presses that button, the combination system then works normally.
I'm wonder if this bit of additional information might be helpful in determining the problem.
Thanks so much for your help.
Mark
Re: Crash!
Thanks, Mark.
We'll wait until you've had a chance to try the tests I described, i.e.:
We'll wait until you've had a chance to try the tests I described, i.e.:
... as well as the ones in my last reply.mdyde wrote:For testing, you might find it easier to trouble-shoot using just a small number of stops, configured from all-default settings:
- Exit Hauptwerk if it's running.
- Launch Hauptwerk via a 'spare' 'Hauptwerk (alt confg N)' configuration (desktop shortcut) .
- Use 'File | Revert all settings to factory defaults' within that configuration to ensure that all of its settings are (still) at their defaults. (Hauptwerk will exit after you revert the settings.)
- Re-launch that same 'Hauptwerk (alt confg N)' configuration, and select your audio and MIDI devices when prompted but leave all other settings at their defaults.
- Load St. Anne's (since we all have access to it, and it's simple and very proven).
- Auto-detect a few MIDI pistons to the virtual pistons on the St. Anne's virtual console.
- Auto-detect just a few MIDI stops.
- See whether you can still reproduce the problem. If not, auto-detect the rest of the stops.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.
Re: Crash!
Martin,
The latest update I have on this situation is:
- The windows memory test locks at 21%, which I have discovered is not uncommon. The person at the computer will download a third party diagnostics tool in the next few days.
- When I examined the CODM file, I noticed that the indicated Hauptwerk version in the General table was 4. I changed that to the version being used on this computer. Could this have been the culprit?
- The disk tested normal.
- The downloaded installer file appears to be correct. Since I am working remotely, I am going to wait a bit to re-install the software.
Since correcting and reloading the CODM file, things seem to be working properly for now.
Thank you so much for your help.
The latest update I have on this situation is:
- The windows memory test locks at 21%, which I have discovered is not uncommon. The person at the computer will download a third party diagnostics tool in the next few days.
- When I examined the CODM file, I noticed that the indicated Hauptwerk version in the General table was 4. I changed that to the version being used on this computer. Could this have been the culprit?
- The disk tested normal.
- The downloaded installer file appears to be correct. Since I am working remotely, I am going to wait a bit to re-install the software.
Since correcting and reloading the CODM file, things seem to be working properly for now.
Thank you so much for your help.
Re: Crash!
Thanks, Mark.
The value of the CODM-ODF._General.CurrentHauptwerkVersion attribute is never actually used for anything anyway -- it just gets set whenever Hauptwerk saves a CODM ODF (e.g. imports it from a SQLite database) for reference.
If the RAM turns out to be fine and if the original problem appears to have gone away (for whatever reason), then I suggest not worrying about it too much, unless it reappears subsequently.
The value of the CODM-ODF._General.CurrentHauptwerkVersion attribute is never actually used for anything anyway -- it just gets set whenever Hauptwerk saves a CODM ODF (e.g. imports it from a SQLite database) for reference.
If the RAM turns out to be fine and if the original problem appears to have gone away (for whatever reason), then I suggest not worrying about it too much, unless it reappears subsequently.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Hauptwerk software designer/developer, Milan Digital Audio.