Chorus Clipping

[Atasco]

So, I've used OpenMPT for a long, long time on many computers. This most recent one (a 64 bit lenovo laptop running Windows 10 ) is giving me the most random issue I've encountered. The VST "Chorus" that comes with OpenMPT by default is clipping loudly, and experiencing severe performance issues in it's GUI. No other VST on my computer, even the other default VSTs, just that one. I was going to export a project I'd been working on because the first export got deleted on accident, but any instrument that was being run through Chorus was making this horrible clicking noise that was impossible to ignore every three or so seconds, regardless of what I did, short of completely bypassing the VST.

I don't know what could be causing this. I've run it before on other 64 bit computers with no issues, and every other VST works without hiccup, so that can't be it. I've tried running it in administrator mode (I know), I've run it in compatibility mode, turned on the compatibility tools in MPT, turned them off, reset them to the default, ran it on different modes, changed the settings inside of the Chorus GUI, everything I could think of. Nothing worked; every three seconds or so it makes this loud clicking noise.

If it's something wrong with the song itself (somehow) then I'll attach it below, but I'm pretty sure it's a problem with my computer or version of OpenMPT.

[LPChip]

Does the clipping also occur when you export to wav?

You mention you were going to, but you don't specify if you actually did.

If its not on the export it is something with your computer. If its in the export, then it is some setting or the plugin.

A few quick things you can try:

- Go to Control Panel > Power Management > Show additional plans > High Performance. By default its set to balanced, and I found out that in rare occassions, it can make the audio driver not get a high enough priority as it tries to conserve energy.
- Increase the buffer in OpenMPT
- Save the song as a new name, and then remove all other plugins except for the chorus one and replace any VSTi with a sample, just so you can ensure that it is the plugin or not.

[Saga Musix]

First off, the default plugins that ship with OpenMPT (except for "MIDI Input Output") are not VST plugins, they are DirectX Media Objects. They are shipped with Windows and are not part of OpenMPT. I don't think Microsoft touched the code of those in a long while but of course it's possible.
I don't have a 64-bit machine with Windows 10 to try, and it seems to work just fine on 32-bit or on Windows 7 64-bit, so just to be absolutely sure, could you maybe test the 32-bit version of OpennMPT?

[Atasco]

THANK YE LPCHIP. I'll address everything you said in order .o. :

Does the clipping also occur when you export to wav?

You mention you were going to, but you don't specify if you actually did.

If its not on the export it is something with your computer. If its in the export, then it is some setting or the plugin.

A few quick things you can try:

- Go to Control Panel > Power Management > Show additional plans > High Performance. By default its set to balanced, and I found out that in rare occassions, it can make the audio driver not get a high enough priority as it tries to conserve energy.
- Increase the buffer in OpenMPT
- Save the song as a new name, and then remove all other plugins except for the chorus one and replace any VSTi with a sample, just so you can ensure that it is the plugin or not.

I did indeed try to export it as a .wav, sorry about not being clear. That's actually what clued me into what the problem was, as it was during the editing process in Audacity to make it sound better did I realize where the clicking noise was coming from. I usually export one file per channel to try and keep everything the correct volume, and I found that the thing causing it was on channel 4, the one with the Chorus plugin on it.

I followed the directions (it was slightly different on my laptop but I got the gist of it) you gave me, and it indeed led me to the plans, but I'd actually already had it selected, and the only other hidden plan was the Power Saver plan. I looked into the advanced settings, and it turns out that despite giving me options for the processor speed, video & gaming performance, and a lot of technical things, not a single option was for audio. I set everything in there to 100% just in case, but the issue persisted ;o; .

At first all I could find relating to buffer size was the sample undo buffer percentage, so I googled how to do what you said, and found (in the Advanced tab of the Setup menu) the "TraceSize" value, which I wasn't sure what to do with. I thought 'hey, what could go wrong?' and just doubled the value, and you know what happened? It worked. It plays fine now without the clipping, and I thank you C:

First off, the default plugins that ship with OpenMPT (except for "MIDI Input Output") are not VST plugins, they are DirectX Media Objects. They are shipped with Windows and are not part of OpenMPT. I don't think Microsoft touched the code of those in a long while but of course it's possible.
I don't have a 64-bit machine with Windows 10 to try, and it seems to work just fine on 32-bit or on Windows 7 64-bit, so just to be absolutely sure, could you maybe test the 32-bit version of OpennMPT?

Ahh :0 ! I didn't know that; I just thought that those were shipped with OpenMPT, but now I know. I guess Windows needs to optimize them for more recent operating systems

[Saga Musix]

At first all I could find relating to buffer size was the sample undo buffer percentage, so I googled how to do what you said, and found (in the Advanced tab of the Setup menu) the "TraceSize" value, which I wasn't sure what to do with. I thought 'hey, what could go wrong?' and just doubled the value, and you know what happened? It worked. It plays fine now without the clipping, and I thank you C:

That's not possible at all. TraceSize is a debugging parameter that does not do anything at all by default (if TraceEnable = 0), and even if TraceEnable = 1, it will not change performance in any way. What I rather guess is that hitting the Apply button in the setup dialog modified some of your parameters in the Sound Card tab for whatever reason.
What LPChip was referring to are the Latency and Period settings in the Sound Card tab - but if the problem even persists during WAV export, no performance-related parameters can fix your problem.

FWIW, about the only performance-related parameters you could change are found in the Sound Card tab, and the following Hidden Settings: GUIUpdateInterval, VuMeterUpdateInterval, ProcessPriorityClass, BoostedThreadPriority, BoostedThreadMMCSSClass.

[Atasco]

At first all I could find relating to buffer size was the sample undo buffer percentage, so I googled how to do what you said, and found (in the Advanced tab of the Setup menu) the "TraceSize" value, which I wasn't sure what to do with. I thought 'hey, what could go wrong?' and just doubled the value, and you know what happened? It worked. It plays fine now without the clipping, and I thank you C:

That's not possible at all. TraceSize is a debugging parameter that does not do anything at all by default (if TraceEnable = 0), and even if TraceEnable = 1, it will not change performance in any way. What I rather guess is that hitting the Apply button in the setup dialog modified some of your parameters in the Sound Card tab for whatever reason.
What LPChip was referring to are the Latency and Period settings in the Sound Card tab - but if the problem even persists during WAV export, no performance-related parameters can fix your problem.

FWIW, about the only performance-related parameters you could change are found in the Sound Card tab, and the following Hidden Settings: GUIUpdateInterval, VuMeterUpdateInterval, ProcessPriorityClass, BoostedThreadPriority, BoostedThreadMMCSSClass.

...hhhhhhuh. That's bizarre. I'm not sure how that worked then.... Hmmm, one thing I forgot to mention (that I kind of off-handedly changed without thinking it would make a difference) while looking for the buffer size was change the Format from 192000Hz to 48000Hz. 192000Hz worked fine without lag on my old laptop so my brain kind of glanced over it and forgot about it :0 . Could OpenMPT defaulting at that Hz from my old computer have been the reason for the clicking and lag in the VST?

[Saga Musix]

Could OpenMPT defaulting at that Hz from my old computer have been the reason for the clicking and lag in the VST?

Yes, definitely, rendering at 192 kHz requires at least four times the processing power compared to 48 kHz, so buffer underruns ("clicks") are more likely. In that case, the solution is to either lower the mix rate (192 kHz is a bit over-the-top really) or increase the latency and period values.
In particular, many plugins do not work well if being used with mix rates higher than 48 kHz (some even don't work at all with any mix rather other than 44 kHz), and it is entirely possible that the Chorus plugin is one of those. I know that some of the default DirectX effects fall into this category, but I cannot recall of the top of my head if Chorus was one of them.

[Atasco]

Yes, definitely, rendering at 192 kHz requires at least four times the processing power compared to 48 kHz, so buffer underruns ("clicks") are more likely. In that case, the solution is to either lower the mix rate (192 kHz is a bit over-the-top really) or increase the latency and period values.
In particular, many plugins do not work well if being used with mix rates higher than 48 kHz (some even don't work at all with any mix rather other than 44 kHz), and it is entirely possible that the Chorus plugin is one of those. I know that some of the default DirectX effects fall into this category, but I cannot recall of the top of my head if Chorus was one of them.

Ahhh, alright, that has to be the explanation then. Sill makes me wonder how my old laptop managed to handle it, but that's not really applicable anymore . Thanks for your help! I've applied that fix, and now it works just fine C:

[Saga Musix]

Sill makes me wonder how my old laptop managed to handle it

Different systems are different. I'm not saying that a modern computer cannot handle 192 kHz playback (in fact, even a ten-year-old computer should be able to handle it if all things are set up correctly), however there are many things that contribute to this, for example the the operating system version, sound hardware, sound drivers, other software that runs in the background, wi-fi drivers (a very common culprit when encountering clicks and pops in audio), etc.

[LPChip]

Was your old laptop running the same version of windows? The Chorus plugin is part of DirectX, and Different OS versions come with different versions of DirectX, and guess what, I've seen these effects get changed with many different Direct X versions. Even up to a point where an old song sounded great on Windows XP, and not on Windows Vista.

[Saga Musix]

The effect implementations have actually not changed since forever, except that since Windows XP, they also allow for floating-point I/O. The differences you experiences were most likely during the time I switched from int to float I/O without considering how this will break some effects because of the weird way some of them are implemented. This is no longer an issue though and the effects will sound the same on all OSes.

[LPChip]

Ah, maybe its that. I don't use XP anymore anyway, but before I completely abandoned it, I exported that particular song once more to wav to keep its sound with me.