Well, I am on pro of this, but at some point is useful. For example, if you make a loop song you probably want to hear the "fading" of an echo or reverb. I think that this is better if kept as a choice.

jmkz, if you would add an empty pattern after the one you have with the echo/reverb, it should normally be present in the export.

I doubt you would want to move this echo/reverb to the beginning of the song? (which is what this bug is about)

Maybe turn this bug in a selectable feature which allows you to wrap the rendered song/pattern's tail.

Its not about the rendering tail. its about the start of the rendering which still has stuff in it thats in the soundbuffer, so the start of the song doesn't sound like its supposed to be. Can have an annoying click and more in it, due to the soundbuffer not properly cleared.

I just want to add a note why this happens and why it's hard to fix (and thus will probably never be fixed).

Plugins can be turned on and off from the plugin host via the "effMainsChanged" opcode. The VST "standard" requires plugins to clear any buffers they may be using internally when they are switched on this way. OpenMPT calls this opcode whenever it stops or resumes playback, and there are many plugins which wipe their delay / reverb / etc. buffers when they are requested to do so.

As you have noticed, not all plugins do this, and there is no perfect way to handle them. You could theoretically render a bit of silence and check if the output of the plugin is also silence. However this would fail with e.g. echo plugins that have a long delay between echos (this delay will obviously be silent). Obviously this is a bug in the plugins and not OpenMPT. Other hosts simply "fix" this by never closing their audio buffer, and you have to do exactly the same thing as in OpenMPT before doing any audio export in those hosts: Wait until the effect tail has finished playing. This is the only proper way I can see to fix this issue: Never closing OpenMPT's audio output. Of course this should be an option if it is ever implemented.

I understand. Would it be possible to check if the audio buffer has data in it before the wave export begins, and issue a warning to the user?

For example, it opens the audiostream and sees if there's anything but silence directly at the beginning of the stream. This wouldn't be perfect for echos that could be mute, but its better than nothing.

If it does, a message pops up, and the wave export is aborted.

The message could be: "OpenMPT noticed that some plugins still play sounds. This can lead to unwanted sounds at the beginning of your song. You can clear this by playing an instrument from the instruments tab and wait until you hear silence, then export to wave again."

There is no audio buffer "before" wave export. The only way to check this would be to render a buffer of silence as described before and check if the output it also silence. However this would fail for the reasons described above, and it could even result in an infinite loop for plugins that always emit some audio (i.e. they are never silent)

<blockquote>You can clear this by playing an instrument from the instruments tab and wait until you hear silence</blockquote>

Telling the user to do something that the application itself could do is one of the worst violations of usability that you could do.

I've added an experimental feature to WAV export which will not completely solve the problem (as said before, that's technically not possible), but it helps in most cases: Use the "Clear plugin buffers before exporting" option to let OpenMPT render up to 20 seconds of silence for each plugin, so that reverb tails etc. can fade out. If the plugin has a longer effect tail and doesn't clear it, it will remain in the buffer (to prevent OpenMPT from waiting a potentially infinite amount of time for plugins to render silence).
The new feature can be tested at http://sagagames.de/stuff/mptrack.exe as always.

Confirmed to work perfectly :)

The tail I'd be having will be at most 5 seconds anyway, so 20 seconds is more than enough, and it does not compromise in any delay on the wave export, so you may consider this fixed. :)

I'd love to see an option to enable this checkbox by default.