Fix the clicks heard during instrument note-off .

[mikobuntu]

I'm sure that this has been addressed before somewhere ( I will edit my post later to better suit all of the details ). The thing that is most obvious is the click that you hear using the triple_osc instrument on default in a track. Looking at the waveform in the top_bar waveform view you can notice that the waveform is drifting ( a song export reviewed in audacity shows a crossover of non zero ), where it should really be a uniform sine wave. we can kind of solve the click by enabling the envelope within the instrument [ well not really solving it as such, but at least making it not have that initial click ] . I'm unsure of the terminology, perhaps antialiasing or such, but whatever the term, there really is an underlaying issue within LMMS and always has been. I can remember @pgiblock mentioning something similar a few years ago if he has time to chip in here.

[michaelgregorius]

-actual made speculate: Would it be possible to always activate ENV when an instrument is dragged/ send into _song-edito_r, and always disable it when it is dragged/ send into BB-editor That would a fix

That would rather be a band-aid as the problems go much deeper. If I understand correctly, even if the volume envelope is disabled it cannot be guaranteed that long samples get played back until the end (for example in AFP).

[tresf]

Is there no way to tackle this as a release-only task? 99.99% of the time, people do not want harsh note-offs, but the envelope controls so much more than the note-off since they affect attack, hold and decay, causing major regressions in sound.

If we could allow the release to be enabled regardless of the rest of the envelope, the notes would sound mostly the same. For those that don't like it, they can turn it off, we'd have it default to off for old projects.

[zonkmachine]

Is there no way to tackle this as a release-only task? 99.99% of the time, people do not want harsh note-offs, but the envelope controls so much more than the note-off since they affect attack, hold and decay, causing major regressions in sound.

If we could allow the release to be enabled regardless of the rest of the envelope, the notes would sound mostly the same. For those that don't like it, they can turn it off, we'd have it default to off for old projects.

Maybe interpolation as suggested further up in the thread?

[lukas-w]

Apologies for not reading the whole thread but what about the PlayHandle removal fix from https://github.com/LMMS/lmms/issues/3086#issuecomment-519087089? It's been a couple of years since I've looked at this, but If I remember correctly, this fixed the note-off clicks in all instruments, at least in TripleOscillator though.

I had bisected this and found that these clicks weren't always heard (contrary to what I claimed in https://github.com/LMMS/lmms/issues/3086#issuecomment-362056978, sorry @tresf) and that bug was introduced as part of some larger changes @diizy made time in 2014. I forgot sharing that info back then and I've since lost the exact commit & fix to a drive failure :( It must have been around 857de8d2c829dc688745f41ba8eddbe148a63a20.

[michaelgregorius]

In my opinion adding extra release-only logic or some potentially invisible interpolation might make the instruments even more confusing. The ADSR should work like most users expect an ADSR to work. It should be flexible enough to create sounds with and without clicks. The release-only logic would make it behave different than ADSRs in other software/hardware and the interpolation might prevent user to get clicks if they want them, e.g. for synthetic kick drums, without a chance to understanding what's hindering them.

IMHO the underlying problem is the design of the instruments. As noted here the instrument "framework" imposes a too strict behavior on all implementations and most implementations seem to differ only on the sound generation aspect. They all share the same envelope section which cannot accommodate for all scenarios:

• Sampler with triggers
• Synths with ADSR

Of course we could add something like a trigger mode to the envelope section that would be used in the pattern editor cases and that could be queried by instrument implementations like the AFP so that they knew how to behave. But I would not even know where to put it in the tiny instrument GUI. And it might be confusing to users as well as it adds more complexity because the problem is solved at the wrong place.

It might sound harsh but I wonder if it is possible and even worth to fix the old instruments as every solution just seems to be a band-aid over the general deficiencies of the instruments.

What if LMMS was more open?

It's also a bit of a question where the project wants to go in general. In my opinion the project concentrates too much on keeping the status quo which might also be caused by architectural issues which are hard to break up without breaking backwards compatibility.

Imagine if LMMS was a more general DAW that supported several plugin interfaces (VST, LV2, CLAP) as first class citizens. With "first class citizen" I mean that you simply add a VST to a track instead of adding a Vestige instrument and then start hunting for the VST DLL.

If that was the case then LMMS could ship with a handful of plugins that are implemented according to one of these standards, e.g. CLAP. The old plugins could be sunset or reimplemented with one of these standards. That might be hard though as they do not seem to be "real" plugins anyway as they can access tons of LMMS internal logic. Other shipped plugin formats like the LADSPA plugins could be provided as extra packages that could be downloaded optionally. Doing so would also remove the burden of backwards compatibility from the LMMS team.

Ok, this post did not really solve the problem but isn't it nice to dream? 😉

[zonkmachine]

Apologies for not reading the whole thread but what about the PlayHandle removal fix from #3086 (comment)? It's been a couple of years since I've looked at this, but If I remember correctly, this fixed the note-off clicks in all instruments, at least in TripleOscillator though.

I had bisected this and found that these clicks weren't always heard (contrary to what I claimed in [#3086 (comment)

I dropped out of the discussion early on so I missed the patches from @lleroy. The codebase has moved a bit since.

[tresf]

Other shipped plugin formats like the LADSPA plugins could be provided as extra packages that could be downloaded optionally. Doing so would also remove the burden of backwards compatibility from the LMMS team.

A bit off-topic, but in this scenario we likely still need to build and offer downloads for them since many are offered upstream as source-only. In regards to backwards compatibility, there's always a moment when we need to draw a line in regards to what we can help with. Caps is a sparkling example of this.

There's an old mailing list conversation about why we bundle the LADSPA stuff -- and although I can't find the exact email thread -- I think Toby's sentiments from way back then still ring true today and that's that: As long as LMMS bundles the plugins, LMMS can ensure that a project will still open and sound OK. How far we go to ensure backwards compatibility (e.g. versus leaving the plugins stale) will continue to be a crowd-sourced effort and decision.

Since these conversations occurred (some 16 years go!) developers have actively written "native" plugins to replace (and improve) functionality found the LADSPA ones. If we ship a sane baseline of plugins with LMMS, offering a "LADPSA" plugin-pack to our users becomes more and more attractive of an option.

In regards to note-off, what's the proposed solution? I would imagine that fundamental's proposal of interpolation can still negatively impact edge-case samples. At some point, don't we need to make this configurable, regardless of how small the instrument UI is?

[Erudition]

I write only on my personal experience as a novice LMMS user.

The ADSR should work like most users expect an ADSR to work.

I expect the ADSR to work like it does, but I do not expect to be forced to use it to avoid clicks I never asked for. Perhaps that's just me.

The release-only logic would make it behave different than ADSRs in other software/hardware

Zyn is "other software", and the release-only logic would make it behave exactly like this other software - not differently. I have not had these clicks in any other software, even besides Zyn - this is an LMMS-specific surprise.

If the clicks really are desirable in some use case (e.g. for synthetic kick drums as you suppose) and not better achieved by specifically adding a click sound (exploiting the limitations of digital harmonics or physical acoustic speaker limitations does not seem to me a good way to rely on producing sound), then I would wonder, how is this achieved in other e.g. professional music software? Even in LMMS there are lots of situations where the click is covered up, so it's not even reliable to produce clicks intentionally by leaving the envelope off.

But I still think relying on envelopes is not the best solution and one big indicator tells me why - again, when I change volume of some instruments mid-note, the clicks can be heard - even if I'm not jumping to zero volume. This is not a retrigger of the note, so the start envelope wouldn't help here. Even if it did, I would need to rely on my envelope for masking clicks and then no longer be able to use it to shape the start and finish of a new note without messing with what happens in between.

[michaelgregorius]

The proposal would be to pull the plugins into their own repositories and to build binaries from these. So more or less separation of concerns: LMMS is the DAW and the plugins are the plugins. This would also simplify the build of LMMS itself because some dependencies would just fall away.

The plugins are also part of what gives a first impression of LMMS. And some of the plugins are really bad. Does anybody think that the LADSPA Calf flanger sounds like a flanger (I noticed this while checking issue 5738)? So if an experienced user decides to try out LMMS and thinks "Hey, I put a flanger on this track" and has a certain expectation and then hears the result I think he would quickly abandon the software because he gets the impression that the developers don't even know their basic effects/DSP.

With regards to backwards compatibility there's always the option to draw a line and to tell users to open old projects with old versions of LMMS which could be provided on the download page.

If LMMS would concentrate on supporting the existing and established standards (VST, LV2, CLAP, etc.) then a set of native plugins would not even really be needed because user could choose from a plethora of 3rd party plugins. Image how this video could have played out if the guy would have seen his VSTs, loaded them (directly and not via the Vestige instrument) and used LMMS to craft some nice patterns, etc. But it did not go like this because he heard clicks in the built-in synths, got irritated by some bad sounding plugins and then seems to have resorted to using samples.

I think I am writing this because to me it feels like the development of LMMS is held back a lot by too much old "cruft". It's almost ten years now that I am with the project (on and off) and it feels like at its core it has not come far. If some more breakage was allowed the project might progress quicker. The project already does not have many resources and much of them are bounded by cruft.

[michaelgregorius]

I write only on my personal experience as a novice LMMS user.

The ADSR should work like most users expect an ADSR to work.

I expect the ADSR to work like it does, but I do not expect to be forced to use it to avoid clicks I never asked for. Perhaps that's just me.

You are hearing the clicks because the default state of the volume ADSRs is off. So what you hear is an oscillator that stops mid wave most of the times. If the oscillators ran until an active ADSR has finished then you would not hear clicks with reasonable attack or decay settings.

The release-only logic would make it behave different than ADSRs in other software/hardware

Zyn is "other software", and the release-only logic would make it behave exactly like this other software - not differently. I have not had these clicks in any other software, even besides Zyn - this is an LMMS-specific surprise.

Ok, I have just checked it and I guess it is the "Forced Release" feature. This is the first synth where I see something like this.

If the clicks really are desirable in some use case (e.g. for synthetic kick drums as you suppose) and not better achieved by specifically adding a click sound (exploiting the limitations of digital harmonics or physical acoustic speaker limitations does not seem to me a good way to rely on producing sound), then I would wonder, how is this achieved in other e.g. professional music software?

In another DAW it could be achieved as follows:

1. Load a VST, e.g. Spire.
2. Set a sine wave.
3. Set its phase to something mid wave, e.g. 90°.
4. Set the shortest release possible.
5. Module the pitch with an ADSR.

If the phase was free running I would sample several kicks (which would all have different phases) and select the best sounding ones.

On a side note: It never occurred to me that this method relies on the physical speakers to generate the sound and that it will likely sound different on different speakers. Interesting aspect.

Even in LMMS there are lots of situations where the click is covered up, so it's not even reliable to produce clicks intentionally by leaving the envelope off.

That's why I am advocating against the interpolation proposal which would likely cover up the clicks non-transparently, thus preventing users to do things that they can do in other software.

But I still think relying on envelopes is not the best solution and one big indicator tells me why - again, when I change volume of some instruments mid-note, the clicks can be heard - even if I'm not jumping to zero volume. This is not a retrigger of the note, so the start envelope wouldn't help here. Even if it did, I would need to rely on my envelope for masking clicks and then no longer be able to use it to shape the start and finish of a new note without messing with what happens in between.

If you change the volume of the sound mid wave in drastic ways then I would expect clicks anyway. It's a bit like saying: "If I manipulate the wave form to look like repeated step functions I get clicks."

[tresf]

I think I am writing this because to me it feels like the development of LMMS is held back a lot by too much old "cruft". It's almost ten years now that I am with the project (on and off) and it feels like at its core it has not come far.

I think this is grossly conflating. The developers have been working very hard on the standards listed. A lot of the "cruft" actually has been carefully weeded out over time. Perhaps not at the pace expected, but this is part of working with a volunteer crew.

In regards to "clicks" I think the vast majority of users would be happy to have a few projects broken in exchange for the bug going away.

[M4rotte]

That's why I am advocating against the interpolation proposal which would likely cover up the clicks non-transparently, thus preventing users to do things that they can do in other software.

This is my opinion too. I, from far, would prefer that the volume envelope to be activated by default rather than a “hidden” envelope-like applied internally just to avoid the click.

Activating the current volume envelope as it is (at 100 % of course), just makes the default 3oscillator preset to not click anymore.

If I take Audacity as an example, if one stop the playing at the “wrong” place, it results in a click, and that’s fine. I’m sure many software do the same.

[michaelgregorius]

What about the following proposal?

1. Volume envelopes of newly added instruments are active by default
2. The current default project consists of one synth and one pattern editor with a kick. Adjust it as follows to demonstrate both scenarios:
   • The synth has an active volume envelope with the new default settings.
   • The kick has an inactive volume envelope with the previous default settings.
3. As proposed by @musikBear: If an instrument is pulled into the song editor then the volume envelope is activated by default. If it is pulled into a pattern editor then the volume envelope is inactive with the old values. However, I would only do so if it works well with the code. The instruments themselves should have no knowledge of whether they are used in the song editor or in a pattern editor. It should only be a configuration of the added instrument's volume envelope that's done by some of the higher layers.
4. I am not too sure about this one: Patterns in the pattern editor are not represented with very short notes anymore. Instead each note lasts until the next note starts or until the end of the whole pattern if there is no following note. Although I can already imagine that there are scenarios where users do not want this behavior and want to have the short 16th notes of the current implementation.

The thing with the volume envelopes is the following:

• Now that they are deactivated by default user complain about clicks and might find it hard to find out how to get rid of them.
• If the volume envelopes were activate by default users might complain about short sounds when they are used with the pattern editor and might find it hard to find out how to alleviate this problem.

Both scenarios might indicate poor UI/UX. However, the first one is also a bad default because it results in bad sounds from a software users want to use to create nice sounds aka music. Both problems could also be solved by better "education" but we cannot magically force our users to read manuals.

With regards to the patterns: if I switch REAPER's MIDI editor to drum mode and use it to play a synth then the synth will play very short notes, i.e. it does not implement some magic to sound longer. This is quite obvious because plugins a la VST, LV2, CLAP, etc. do not, cannot and must not have much knowledge about the host. There's also no hand holding done by REAPER. User have to know that if they use something that treats notes as short triggers then they have to use a matching plugin/instrument that can deal with the triggers or adjust the instrument accordingly. REAPER seems to assume educated users here.

Edit: pull request #6864 now implements the first two items of my proposals.

[michaelgregorius]

Here are some investigation results for the third proposal (differentiate the drop targets of instruments and set their volume envelope accordingly). The different drop targets trigger the following methods:

• "Song Editor": TrackContainerView::dropEvent
• "Pattern Editor": PatternEditor::dropEvent

In most cases the "Pattern Editor" delegates to TrackContainerView::dropEvent though.

The method TrackContainerView::dropEvent contains the main logic for adding instruments, samples, etc. So we somehow have to get the information on whether the envelopes need adjustment or not into this method.

One option might be that PatternEditor::dropEvent extends the information in the provided QDropEvent such that TrackContainerView::dropEvent knows that the original drop target was the "Pattern Editor". The implementation code could then adjust the volume envelope of the created instrument accordingly.

The implementation might be complicated by the InstrumentLoaderThread that is used in some cases.

[Rossmaxx]

I have an idea, why not drop the old envelope altogether and use the new envelope exclusively. If dropped in the pattern editor, the envelope can be turned off. That gets rid of the complexity of keeping two envelope patterns.

[michaelgregorius]

I have an idea, why not drop the old envelope altogether and use the new envelope exclusively. If dropped in the pattern editor, the envelope can be turned off. That gets rid of the complexity of keeping two envelope patterns.

Isn't this exactly what the third proposal from my comment here is about?

[Rossmaxx]

Oops, didn't read the entire thing properly. I saw somewhere in this thread about having both old and new envelopes and made that post.

[Rossmaxx]

Btw i think if (dropped into pattern track) set amt = 0 inside the drop handler function might be good enough here without dealing with the rest of the stuff

Edit : reread the comment. What I meant is to add a small setting within PatternEditor::dropEvent() to set amt to 0.

[michaelgregorius]

The "Pattern Editor" doesn't know anything about the added instrument as it's simply calling the void method TrackContainerView::dropEvent after peeking into the event.

Instead of embellishing the QDropEvent with extra information another option might be to add a method like TrackContainerView::handleDrop(QDropEvent *e, bool disableVolumeEnvelope).

The implementation of TrackContainerView::dropEvent would then simply delegate to this method by calling handleDrop(e, false) whereas PatternEditor::dropEvent would delegate by calling handleDrop(e, true). I have just noticed that PatternEditor inherits from TrackContainerView so technically this should work nicely.

[Rossmaxx]

Ohh i see.

[michaelgregorius]

Pull request #6864 now implements the first three proposals of this comment. The forth proposal is outside of the scope of the pull request anyway, so I'd say the pull request is ready to go and ready for review.

The pull request improves the current implementation in that instruments which are added to the song editor do not click anymore as they have an activated volume envelope. Instruments that are added to the pattern editor have the disabled "legacy" volume envelope including clicks, etc.

I would very much appreciate if people gave the pull request a test drive.

[michaelgregorius]

Additionally we could also add a new option to the settings dialog that would enable more experienced to use the active volume envelopes by default everywhere:

In this case users would have to disable the new option to get the active volume enveloped everywhere. If wanted we could of course also set the default such that users would have to opt-in to the legacy envelopes.

For now the option is under "GUI" but it could also be moved into a new group, e.g. "Behavior".

[DomClark]

I think we should fix #2074, then enable envelopes by default for all instruments everywhere.

Imagine if LMMS was a more general DAW that supported several plugin interfaces (VST, LV2, CLAP) as first class citizens. With "first class citizen" I mean that you simply add a VST to a track instead of adding a Vestige instrument and then start hunting for the VST DLL.

Off topic, but I want to reply to this comment. The internal plugin architecture has little to do with whether plugins appear as first class. The reason VSTs are added via VeSTige and not directly is that we had no way to scan all VSTs and present them in the instrument sidebar. @JohannesLorenz has made it possible to present third-party plugins there, and that's where you'll find LV2 instruments in LMMS, not through some shell instrument like VeSTige. We already have VST effects presented alongside others in the effect dialog, and it shouldn't be hard to do the same for VST instruments in the sidebar. I would expect all new plugin formats supported by LMMS to be presented in the same way.

[RoxasKH]

Here's my five cents and current take on this issue (and the reason why #6864 got linked):

* All clicks would be fixed if the volume envelopes were activated by default on all instruments.

* Activating the volume envelopes leads to problems with instruments being used in the "Pattern Editor" though because it represents the patterns with the help of very short notes.

* There is no way to fix both problems due to problems in the instrument architecture which you can read about [here](https://github.com/LMMS/lmms/pull/6864#issuecomment-1718265782). Long story short: the current instrument architecture is very rigid and therefore an instrument implementation, e.g. a sampler, cannot decide by itself how a MIDI note is interpreted and how it is used to shape a volume envelope. Or at least it does not have the last word on it and the "Envelope" tab will always somehow interfere.

I wanna add my bit on this, which i don't know if it has already been addressed, to do some arguing: this doesn't fix all clicks, but it does fix all clicks caused by a missing envelope (usually by not having any release). I better explain myself, some clicking will still occurs, with the Sample Tracks and chopping.

As of right now you can chop sample in the LMMS alpha version, but at the edges of the chopped part a very slight click usually happens due to the sample not ending on a 0 point as always.

While it is true that the upcoming PR #5616 (although it now seems to be inactive for a while) of fading might circumvent the issue, i still think that fading is supposed to be used for aggressive fade in and out on the sample, more than to fix clicks, a bit like the envelope.

Obviously this is not a big issue, and as it affects the sample track and its chopping functionality only, i guess it could be done in a separate PR.

Another clicking situation was mentioned when looping samples inside AFP (#5855).

Those 2 are probably an even more complicated matter tho, as the starting point of the sample (either in sample track or in the AFP loop) can be the cause of the clicking, too.

That said, in these situations something like zero cross points and interpolation might help fixing them, and so now i'm concerned about if they should be treated as separate clicking issue with separate fixing, or if it's better to find a universal fix for all the clicking, even if less immediate.

I gotta say tho that a universal fix could still be applied later and having an activated envelope shouldn't affect it, so i'm guessing the envelope fix can still be merged.

That said, just to quote a behaviour from a known professional DAW, FL studio avoid clicks without having an envelope on by default. That said the behaviour is kinda weird, or well, when there's no envelope on, playing a key or any note added will just play the whole sample length.

[michaelgregorius]

I wanna add my bit on this, which i don't know if it has already been addressed, to do some arguing: this doesn't fix all clicks, but it does fix all clicks caused by a missing envelope (usually by not having any release). I better explain myself, some clicking will still occurs, with the Sample Tracks and chopping.

I agree that my statement has been a little to "broad". 😅 However, with the volume envelope disabled all/most instruments are prone to generate click sounds. So the PR fixes one of the more obvious sources for clicks.

The other sources for clicks that you describe are plugin internal sources where the processing and generation of sounds is done in a way that generates clicks right at the source. I think these problems will have to be handled on a case by case basis, i.e. inside of the plugin. So the slicer plugin from #6857 might for example offer some options for (cross)fades, etc.

On the other hand, LMMS should never prevent plugins from generating clicks. If I want to write a plugin that generates Dirac pulses then I want to be able to hear them or pipe them into other plugins without the sound being tampered with internally and non-transparently. In my opinion DAWs should be "unbiased" and should at the same time offer flexibility. So if someone wanted to filter the Dirac pulses from the example above they should add a filter plugin after it or wherever they want to do the filtering.

That said, just to quote a behaviour from a known professional DAW, FL studio avoid clicks without having an envelope on by default. That said the behaviour is kinda weird, or well, when there's no envelope on, playing a key or any note added will just play the whole sample length.

Does it somehow do this for all instruments, e.g. also for VSTs, or only very specific ones, e.g. like built-in samplers, etc.?

[RoxasKH]

I wanna add my bit on this, which i don't know if it has already been addressed, to do some arguing: this doesn't fix all clicks, but it does fix all clicks caused by a missing envelope (usually by not having any release). I better explain myself, some clicking will still occurs, with the Sample Tracks and chopping.

I agree that my statement has been a little to "broad". 😅 However, with the volume envelope disabled all/most instruments are prone to generate click sounds. So the PR fixes one of the more obvious sources for clicks.

The other sources for clicks that you describe are plugin internal sources where the processing and generation of sounds is done in a way that generates clicks right at the source. I think these problems will have to be handled on a case by case basis, i.e. inside of the plugin. So the slicer plugin from #6857 might for example offer some options for (cross)fades, etc.

On the other hand, LMMS should never prevent plugins from generating clicks. If I want to write a plugin that generates Dirac pulses then I want to be able to hear them or pipe them into other plugins without the sound being tampered with internally and non-transparently. In my opinion DAWs should be "unbiased" and should at the same time offer flexibility. So if someone wanted to filter the Dirac pulses from the example above they should add a filter plugin after it or wherever they want to do the filtering.

That said, just to quote a behaviour from a known professional DAW, FL studio avoid clicks without having an envelope on by default. That said the behaviour is kinda weird, or well, when there's no envelope on, playing a key or any note added will just play the whole sample length.

Does it somehow do this for all instruments, e.g. also for VSTs, or only very specific ones, e.g. like built-in samplers, etc.?

I'm sorry, i've been a little confusing. First, i linked the wrong PR, as i said i meant to link the fading one (#5616) and not the slicer. I fixed it also in the previous message. This is to say that is not a plugin only issue, that one is related to sample tracks. I haven't tested the slicer so i wouldn't know if it has clicking issues, i guess it could tho.

I agree that you should be able to generate clicks (i've never really felt the need in my life, but i guess sound designers might need it), althouth as it's a very more niche usercase that should be made possible with a separate option instead. Activating the envelope by default might be an idea.

About FL i've been vague once again, yes i just tried loading a sample in the main sampler, and that was the default behaviour. VSTs aren't worth checking as the behavior there is left to the singular plugin programmer, in fact VST don't cause any clicks in LMMS too, just like soundfonts don't.

However, also 3rd party plugins like the 3osc in FL don't produce any kind of click caused by missing envelope,and the envelope is off by default there as well. So the sampler and 3osc are the most clear examples. Other plugins like GMS tends to have a builtin envelope which usually you can't disable. Others like BooBass don't click, but have no envelope at all, mostly cause it should be in the plugin, but the plugin in this particular case don't have one.

[michaelgregorius]

Off topic, but I want to reply to this comment. The internal plugin architecture has little to do with whether plugins appear as first class. The reason VSTs are added via VeSTige and not directly is that we had no way to scan all VSTs and present them in the instrument sidebar. @JohannesLorenz has made it possible to present third-party plugins there, and that's where you'll find LV2 instruments in LMMS, not through some shell instrument like VeSTige. We already have VST effects presented alongside others in the effect dialog, and it shouldn't be hard to do the same for VST instruments in the sidebar. I would expect all new plugin formats supported by LMMS to be presented in the same way.

Also off topic, but I do not want to join discourse and do not know where to discuss these things otherwise. 😉 I did not only mean the selection of plugins with "first class citizens". Other aspects would be:

• Being able to use VST, LV2 and CLAP plugins (without shell GUIs)
• Being able to add the following types of plugins to a track:
  • MIDI generators
  • MIDI manipulators, e.g. arpeggiators
  • Audio generators, e.g. samplers, synths, etc.
  • Audio manipulation, i.e. effects
• Being able to see the GUIs
• Being able to automate plugin parameters

I think to support all of this some changes to the architecture would be needed. Currently most instruments work in conjunction with the InstrumentTrack. The InstrumentTrack is responsible for the MIDI manipulation (chord stacking, etc.) and for some reason it also does the processing of envelopes, filters, etc. The actual plugin can mostly only change the way the sounds are generated. The rest of the synth architecture is always the same. To me this design seems very strange because the main purpose of the track should be to hold and manage the input data, e.g. the MIDi clips, etc. The actual processing and sound shaping should be done by the plugins.

Due to the heavy marriage of the Instrument with the InstrumentTrack one has to actively work around some things, like for example removing the sound shaping for VSTs, etc. This is not very convenient. And I think it is also one of the reasons why all internal plugins use the same (tiny) GUI because even if you wanted to implement a new GUI you'd have to reimplement all of the features of the current InstrumentTrack. In a cleaner design there would be reusable elements that were used inside of the plugins, e.g. the plugin would decide how many envelopes there are and when they are applied, etc. The current design of the instruments is very static.

To support the features above I think it would be necessary to create a new track type that only holds the MIDI clips and then routes the data and the results through plugin chains. It should not do any hard coded sound shaping, etc.

[Erudition]

I have just checked it and I guess it is the "Forced Release" feature

Not quite. Extreme jump interpolation is not some optional feature of Zyn, it's part of the algorithm. (The author of zyn participated in this thread early on.) "Forced Release" is unrelated, which causes a note's envelope to jump to the release stage even if the sustain stage has not started yet.

You are hearing the clicks because the default state of the volume ADSRs is off. So what you hear is an oscillator that stops mid wave most of the times. If the oscillators ran until an active ADSR has finished then you would not hear clicks with reasonable attack or decay settings.

There are many good earlier comments explaining that, so I'm well aware of the reason the click appears, but I don't think having the envelope off completely is an "unreasonable" decay setting as you imply. Without the envelope, I would expect the instrument to stop abruptly, yes. I would not expect there to be a click sound added, however. This is not a part of the instrument's sound and would not happen in real life (with the fastest string-dampening method physically possible, even). As previously pointed out in this thread, cutting off the waveform like that is essentially telling the speaker to move to 0 at infinite speed. Sure, as a programmer I understand why this is happening - it is an artifact, a leak in the abstraction. But as a musician, this does not match my intention, which is what UX is all about. In Zyn, the musician's intention is preserved, and this is not the only software that corrects for this artifact.

It never occurred to me that this method relies on the physical speakers to generate the sound and that it will likely sound different on different speakers.

Me either, but it was explained earlier in this thread, with visuals. This is why I think it's better to deliberately add desired pop sounds through normal synthesis rather than relying on artifacts. Perhaps we can hear from more users who exploit this regularly, so far you're the only one to say so out of all the users posting here.

That's why I am advocating against the interpolation proposal which would likely cover up the clicks non-transparently

No that's exactly the desire. Good UX does not expose the user to leaks in the abstraction, such as digital audio artifacts. It's better to round off the rough edges than to ship every user a pair of goggles to wear that hide the rough edges from view. I think most of the users on this thread would agree, though we could poll that. I can imagine the envelope coverup might end up implemented simply because it's the easiest fix.

But it only fixes some of them:

If you change the volume of the sound mid wave in drastic ways then I would expect clicks anyway. It's a bit like saying: "If I manipulate the wave form to look like repeated step functions I get clicks."

A step function does not represent my intent when I press more or less lightly on a note. If I want to go from 30% to 60% volume (in an abrupt way perhaps, but not an infinitesimal jump with artifacts), of course the instrument isn't going to interpolate that for me, it's the software's job. It is a digital device and like all digital devices it speaks in quanta - there is no way to provide truly continuous input. So while the digital data might technically resemble a step function, that's always the case with MIDI - and there's no way to "envelope" your way out of that when you're still holding the key down.

If LMMS patches this issue with only note-offs and not a general interpolation across unrealistic jumps, all of the other jumps will remain unfixed. This makes LMMS an undesirable DAW for instruments with polyphonic aftertouch, for example.

By fixing this issue with interpolation - again, only the bare minimum to cover physically impossibly extreme jumps, not a radical softening - we eliminate these artifacts wherever they appear, for good.

Searching online, I don't see anyone complaining about Zyn's lack of click artifacts, so I just think this is the clear winner for UX, where LMMS' behavior would match the intention of most digital musicians.

[michaelgregorius]

TLDR: Instruments should be able to implement whatever they want. The signal path of the DAW should not mess with the signal at all. There a no "unrealistic jumps". The "problem" cannot be fixed "for good".

"Forced Release" is unrelated, which causes a note's envelope to jump to the release stage even if the sustain stage has not started yet.

This is "normal" ADSR behavior then.

Instruments/plugins should be free to implement whatever they want

This is not a part of the instrument's sound

Well, it can be part of an instrument's sound because you currently hear it very often in LMMS. 😉 And who's to say what a "real" instrument should sound like and what's desirable?

I think each instrument should be able to implement the behavior as its developers see fit. If one instrument wants to smooth the sound because it wants to model a rather low-frequency-ish process (e.g. your damped string example) then be it so. If another one doesn't then that's obviously also fine. Perhaps it is considered part of the "character".

The signal path of the DAW should not mess with the signal

What I find important, and I hope that we are all on the same page here, is that the smoothing should not take place in the signal path of the DAW/LMMS itself. So the DAW should not say: "Before I pass the output of this plugin into the next I will mess with the signal."

Plugins and instruments however are free to implement whatever they want because their job is to create/manipulate sound. Users expect them to "mess" with the sound.

The DAW itself must keep the signals it deals with pristine.

There are no "unrealistic jumps"

[...] cutting off the waveform like that is essentially telling the speaker to move to 0 at infinite speed. [...]

No, it does not. It tells the speaker to ideally fade out with a sinc tail (plus the shifted and multiplied sinc functions of the previous samples).

And by the same argument there are no "unrealistic jumps". A digital synthesizer is a an instrument just like any other. It creates a signal which at some point is passed into the DA converter of the sound card which will turn it into a continuous signal using its reconstruction filters. So nothing physically impossible is happening here.

In a sampled system it is not even possible to define an input that results in the speaker being told to move infinitely fast to its resting position. The important thing to note is that there isn't and cannot be a step function at the output/speakers anyway. The speaker is not fed the samples.

You can also think about this the other way around. If it were possible to have the physical impossible jump that you refer to in reality then it couldn't even be represented in a system that uses samples in the first place. In the perfect system the signal would be perfectly lowpassed to half the sampling rate and then sampled. This means that the sharp edge of the "real" jump would already be smoothed before it is sampled so the samples represent something else: the lowpassed signal. If you do not lowpass the signal you will get an aliased signal which also does not represent the infinite jump. Hence the sampled system cannot reproduce the jump.

The "problem" cannot be fixed "for good"

By fixing this issue with interpolation - again, only the bare minimum to cover physically impossibly extreme jumps, not a radical softening - we eliminate these artifacts wherever they appear, for good.

This sounds like you want to implement something in the signal path of the DAW itself, which is a very bad idea. This "problem" cannot and should not be fixed "for good" because it is impossible (and not a general problem that needs ultimate fixing anyway). Let's check the following possibilities:

• The clicks are attempted to be fixed in the plugins. Someone will write a plugin that creates clicks. The problem is back.
• You attempt to solve the clicks in the signal path of the DAW itself. Now you have non-transparently broken lots of other use cases people might want to achieve in their DAW.

Edit: formatting and slight rewording.

[tresf]

@michaelgregorius going back to the original bug report, wouldn't your argument suggest that 3xosc is internally bugged (and any instruments that provide this sound)? So -- according to this argument -- wouldn't the fix be to add interpolation to each bugged instrument?

I just did some quick testing and can reproduce the issue with most of our native instruments, which is why I side with the argument that the DAW should do it. I'm not arguing for all jumps to be interpolated, just that the tail-end of a note-off is interpolated. The opposing argument (I feel) would be to modify all instruments to achieve this same result. (I didn't test any 3rd-party instruments, so I'm not sure how they're affected).

[michaelgregorius]

Hi @tresf, I would say it's mainly a problem with the initial configuration of the instruments because their envelopes are turned off by default. If you build #6864 you will find that the problem of the click sounds is fixed for all instruments (at least if you drop them onto the song editor). This can be heard very well with the default 3OSC because its default preset is some layered sines where the clicks become very apparent if the envelope is turned off.

So PR #6864 fixes the problem that is reported by this issue: the clicks that are heard during note-off events because no envelopes are applied.

Does every instrument need to be fixed?

Yes, indeed every instrument needs to be fixed. However, due to the rather rigid "architecture" of the instruments that are offered by LMMS the fix of the volume envelopes only had to be done in a handful of places and didn't need to be spread all over the code. It's mainly fixed in the InstrumentSoundShaping instance of the InstrumentTrack. Much of the other code that was changed by the PR is just a chain of delegation to reach that place. The constructor of the class EnvelopeAndLfoParameters was also adjusted so that newly added instruments can have an activated volume envelope by default.

Why is all of this so complicated?

While it might seem nice that the problem could be fixed in a handful of places the current structure is still wrong, causes lots of problems and makes the instruments "same-ish" and inflexible. To elaborate why I think so let's first have a look how things work in other DAWs and third party instruments, e.g. VSTs.

Objects and responsibilities in other DAWs

In the simplest case we have three objects:

• A track
• MIDI clips
• An instrument

The track is a "stupid" container that contains MIDI data/clips. It is also associated with the instrument. When the track is being played the MIDI data at the current position of the track is fed into the instruments. All of the heavy lifting is then done by the instrument and the instrument has a lots of freedoms of what it provides and what not.

What's important in the context of the next section is that all envelopes, filters, etc. are part of the instrument. So it's an implementation detail of the instrument of what envelopes are offered, how they are applied, etc. A sampler might have different envelopes and settings than a synth because it has different requirements.

It's also completely up to the instrument how to interpret the MIDI data. The instrument can interpret MIDI notes as Note-On and Note-Off events to drive an ADSR or it can only interpret the Note-On events and interpret them as triggers for some internal logic.

Objects and responsibilities in LMMS

In LMMS we also find the three aforementioned objects of tracks, clips and instruments. However, their responsibilities are "cut" differently. In LMMS the track is mainly represented by the InstrumentTrack class (at least for the instruments). As I have already noted above the InstrumentTrack also has a member InstrumentSoundShaping which is responsible for applying volume envelopes and filters. This means that in LMMS the track does what should be an implementation detail of each instrument! This is also the reason why the instruments are not really flexible because the output of each instrument has to go through that stage.

This structure is also the reason why LMMS fights with the problem of instruments in the pattern editor where it's hard to ensure that they play their sounds long enough. Some strange notes with negative lengths have been invented in an attempt to fix the problems with the volume envelopes.

This is all caused by the fact that the volume envelopes are not part of the instrument itself and that they are applied outside of the instrument! If LMMS' instruments were as "free" as the VSTs described above then AFP would have its own internal envelopes and logic. It would consume normal MIDI notes and trigger the samples according to its own logic. If it was configured to have no envelopes and to play the samples until the end it would simply wait for a Note-On and play the sample without any envelope until the end. This would be possible because it had full control.

Regarding you question of how 3rd-party instruments are affected. For the Vestige instrument the envelopes and filters of the InstrumentTrack are disabled so that they do not interfere with the sound coming out of the VST. If this was not done an additional volume envelope might be applied. However, in the code you have to "fight against" something that's not wanted and that should not be there in the first place because it belongs into the instruments and not in the track.

What's meant with "the DAW should do it"?

@tresf, can you please elaborate what exactly do you mean when you write "the DAW should do it"? Where do you draw the line between the DAW and the instruments? I just want to make sure that we do not misunderstand each other.

Question about the settings dialog

Shall I also push the changes for the additional settings (see this comment)? They are not yet contained in #6864 because I don't know if something like this is wanted.

[M4rotte]

The constructor of the class EnvelopeAndLfoParameters was also adjusted so that newly added instruments can have an activated volume envelope by default.

That’s a good thing. But while it doesn’t have to be done for any instrument, I think it must be done for the TripleOscillator instrument, which is the primary and most iconic LMMS’s native instrument.

Activate the envelope by default breaks nothing. It won’t upset any user AFAIK. But knowingly let this note-off click sound inspires, could be n of shitty software to the average user.

[tresf]

@michaelgregorius if you pause or delete a piano roll segment while it's playing, the click still occurs even with #6864.

• Do you believe that "note off" bug's scope should NOT include the pause button?
• Should the pause button honor the envelope? (Are we OK with this for super long releases?)
• Converting a zero-length B&B track to a Piano Roll track re-exposes this bug. Is this out of scope?
• Dragging an instrument directly to the B&B editor re-exposes this bug. Is this out of scope?

Some presets such as DirtyReece.xpf do not have a default envelope, so the click can still occur regardless of this patch. Do you consider this in-scope for this bug report? Is the preset at fault, or the behavior of LMMS? (e.g. Should we activate "ghost" envelopes or use the default envelope proposed in #6864?

I'm not going to go into detail in what the "DAW" is in the context of this bug report, it's just TL;DR, I'm just advocating for a palatable solution that fixes the behavior like everyone else.

I'm still not convinced that toggling the envelopes on by default (depending on drop target), is the fix for it, however, I can say that the new envelope values in #6864 are a much improved experience over the old envelope values. Most instruments "just work". I played a few drum samples and they sound good too, but there are still many scenarios in a normal workflow that I feel are not addressed.

[michaelgregorius]

TLDR: There are different sources for clicks and in my opinion it would be best to tackle them in separate issues.

Do you believe that "note off" bug's scope should NOT include the pause button?

I would create a new issue for the clicks that are caused by to the implementation of the pause and stop buttons. The reason is that this is yet another source for clicks that must be fixed outside of the instruments.

To check how REAPER deals with both buttons I have setup the following:

• Add a track with Hive as the instrument. Set a very long release.
• Add a MIDI clip with a long note.

I have then checked the behavior of pressing the stop or pause button while it's playing.

Pressing the stop button mid-note will still play the full release of the instrument. So it seems that REAPER sends note-off events to the plugins when stop is pressed but then keeps processing the audio streams. It does not kill the sound immediately.

Pressing pause stops the sound immediately but there are not clicks. So I assume that REAPER tries to retain as much state as possible (because everything is just paused) but that it simply does not send anything to the output. The fact that this does not create any clicks seems to indicate that REAPER does not immediately stop when the event is received but that it at least keeps processing to fill a buffer that's long enough so that a quick fade-out can be applied.

Should the pause button honor the envelope? (Are we OK with this for super long releases?)

It depends on how LMMS wants to tackle the problem. The stop and the pause button both create clicks because the audio stream is cut off abruptly/immediately.

I find REAPER's behavior very intuitive. If I play a song that ends with a very long reverb tail then I want to be able to hear the tail even if the actual playback has already stopped. If I press pause then I assume the processing to be stopped because it is a pause that's expected to continue later in the same state as before. Interestingly this does not seem to work 100% in REAPER.

Converting a zero-length B&B track to a Piano Roll track re-exposes this bug. Is this out of scope?

I don't know how to convert a zero-length to a Piano Roll track but to me it sounds like the problem is very likely caused by these strange zero-length notes. I am not even sure if something like this exists in other software. For most other DAWs I would assume that they deal solely with MIDI data and not with some intermediate own note class/format. If I remember correctly these zero-length notes have a negative length internally?

So if these notes are the cause a new issue should be created to fix this source.

Dragging an instrument directly to the B&B editor re-exposes this bug. Is this out of scope?

This is done on purpose because otherwise a Kicker that's dragged into the beat editor will cut off too early and not play the full sound. As I have laid out above this is in part caused by the architecture of the instruments. What to do here also depends on the education/experience of the users. Activating or deactivating the envelope when an instrument is dragged into the beat editor has the following consequences:

• If the volume envelope is activated then users have to know/learn that they might have to adjust the volume envelope. Otherwise Kicker will cut out early, samples will not play fully, etc.
• If the volume envelope is deactivated then users have to learn that they must activate the volume envelope for some instruments, e.g. 3OSC, or else they will get click sounds.

The proposed new setting in the settings dialog is somewhat of a compromise because it lets the users decide which of the two options suits them better.

Some presets such as DirtyReece.xpf do not have a default envelope, so the click can still occur regardless of this patch. Do you consider this in-scope for this bug report? Is the preset at fault, or the behavior of LMMS?

It is hard to draw a line regarding who's at fault because the presets have been created by different users. I assume that it's a mix between bad defaults (deactivated volume envelopes) and inexperienced users. I can imagine that some presets have been generated by inexperienced users who did not know that they have to turn on the volume envelope so that their preset sounds nice and does not click.

I also don't know the process of how these presets got added to LMMS' default presets but it seems that there was not much of a quality control.

For dealing with the quality of the presets I would therefore create yet another issue. One would have to go through the presets and then decided if they need an activated volume envelope or not.

I'm still not convinced that toggling the envelopes on by default (depending on drop target), is the fix for it, however, I can say that the new envelope values in #6864 are a much improved experience over the old envelope values. Most instruments "just work". I played a few drum samples and they sound good too, but there are still many scenarios in a normal workflow that I feel are not addressed.

I agree. As you have laid out there are some others sources for clicks that need to be tackled. But I think my PR definitively solves one very prominent source for clicks.

In summing up, IMHO we should create new issues to tackle the following other sources of clicks:

1. Implementation of the pause and stop buttons
2. Zero-length notes aka instruments and samplers in the Pattern Editor
3. Quality control of the presets

I assume that the problem with the zero-length notes and instruments in the Pattern Editor will be the hardest to solve satisfyingly because it comprises of many aspects, some of which are not under our control: instrument architecture, education of users, etc.

[tresf]

I don't know how to convert a zero-length to a Piano Roll track but to me it sounds like the problem is very likely caused by these strange zero-length notes.

It's in the right click of every BB track to convert it to a piano roll. I'm not talking about zero-length notes, I'm talking about the default behavior to NOT add an envelope now being undesired when it is converted into a piano roll.

[tresf]

There are different sources for clicks and in my opinion it would be best to tackle them in separate issues.

Since most sources for clicks are a hard cutoff, this is why a proposal to interpolate the note-off sounds best, from 1,000 ft. It sounds like it fixes the problem without compromise. And in the rare event that someone wants this artifact at the end of the note-off, we can have an LED to toggle it back on.

[michaelgregorius]

How do you want to interpolate the note-off sounds in third party instruments, e.g. VSTs? Here you have no control over how the instruments implement the note-off events. Or is your statement about fixing the note-off events in the LMMS instruments?

Also, the clicks that are caused by the current implementation of the pause event have to be fixed independently anyway because they should not be fixed with the help of note-off events. If pause is intended to be implemented like described above then the instruments must be in the same state they were in before pause was hit when playing is resumed. Sending a mid-note note-off would prevent this because one long note would now look like two shorter notes that are adjacent to each other.

[michaelgregorius]

I don't know how to convert a zero-length to a Piano Roll track but to me it sounds like the problem is very likely caused by these strange zero-length notes.

It's in the right click of every BB track to convert it to a piano roll. I'm not talking about zero-length notes, I'm talking about the default behavior to NOT add an envelope now being undesired when it is converted into a piano roll.

@tresf, do you mean when some other note lengths are added in the Piano Roll representation? Because if I do not add other notes it sounds identical to me (at least with the Kicker example I have used).

[tresf]

I don't know how to convert a zero-length to a Piano Roll track but to me it sounds like the problem is very likely caused by these strange zero-length notes.

It's in the right click of every BB track to convert it to a piano roll. I'm not talking about zero-length notes, I'm talking about the default behavior to NOT add an envelope now being undesired when it is converted into a piano roll.

@tresf, do you mean when some other note lengths are added in the Piano Roll representation? Because if I do not add other notes it sounds identical to me (at least with the Kicker example I have used).

Correct. This is not about the undefined behavior of zero-length notes that are confusingly converted into the piano roll, but rather regular notes added by clicking. I see a lot of projects shared on Facebook, LSP and YouTube that use the BBEditor for its piano roll capabilities, so it's a use-case that's sure to rear its ugly head.

[tresf]

How do you want to interpolate the note-off sounds in third party instruments, e.g. VSTs?

I can't speak on behalf of the technical implementation of the fix or how the average plugin should behave.

P.S. I'm not sure if it's relevant, but I did test OpulenZ (which doesn't have the envelope tab) and initial testing showed that it does not suffer from this (I assume because this particular instrument has its own internal envelope/release which is honored on note-off).

the clicks that are caused by the current implementation of the pause event have to be fixed independently anyway because they should not be fixed with the help of note-off events.

Please excuse my ignorance, I'm simply stating that when I hit pause, the same bug occurs. In the current implementation of LMMS, I do not believe pause does as you're describing (pausing and resuming doesn't really work anything like you're describing currently), so from a user's perspective, the bug is identical. I'm not qualified enough to state whether or not this is technically the case.

[michaelgregorius]

Correct. This is not about the undefined behavior of zero-length notes that are confusingly converted into the piano roll, but rather regular notes added by clicking. I see a lot of projects shared on Facebook, LSP and YouTube that use the BBEditor for its piano roll capabilities, so it's a use-case that's sure to rear its ugly head.

Obviously that's a perfectly legal use case, especially if it used by a lot of people.

Fix with default envelopes per instrument

The best fix for this use case might be if every instrument had it's own default settings for the envelopes then. This would mean that each instrument would decide for itself on the AHDSR and amount settings. Or even better: each instrument should have its own logic for its envelopes, just like Opulenz which @tresf has mentioned above.

If that was the case then each instrument would just work with the piano roll because it had sane defaults as it knowns its own implementation best.

Synth-like instruments would have an activated volume envelope and triggered instruments like AFP and Kicker would have a deactivated envelope (or their own ones). And the zero-length notes would likely not be needed anymore.

Implementation effort

Trying to implement this might be quite some effort due to the current architecture and relationships/hierarchies between classes.

As I have already noted one problem is that the track is the owner of the envelopes and filter. These must become part of the instrument so that it can decide on their default settings.

Therefore some cleanup should be done. One goal of this cleanup should for example be that the instrument does not call back into the track anymore. There should be a clean hierarchy of "who knows/uses who?". The instrument is associated/used by the track, hence it should not know the track or manipulate it.

How to achieve this goal?

Achieving this might be done in several steps:

1. Move the envelopes and filters into the Instrument class. Technically this would mean to move the member InstrumentSoundShaping from InstrumentTrack into the Instrument. During construction each instrument could then decide on the amount set for the envelopes and what default values should be set for the AHDSR.
2. Bonus: Completely hide the "Envelope, filter and LFO" tab from the instrument view if the instrument is configured to not use them, like for example Opulenz.

These two steps might already solve the problem described above.

Free the instruments!

Let's not stop after the two steps described above. Instead let's dream and up the game:

1. Preparation for the following step: Free the instruments from their minuscule GUIs. Let each instrument decide for itself on how it wants to present itself. This would enable much more useful and usable GUIs, for example like the one @sakertooth shows in this comment. It really makes me weep inside a little bit when I see motivated people like @DanielKauss implement new plugins like the sample slicer (#6857) and they have to then cram them into this tiny window, thus also limiting their options and functionality. 😢
2. Implement instruments that do not have the rigid architecture anymore. These instruments would for example not have the current default InstrumentSoundShaping as a default member anymore. They would have as many envelopes, filters, etc. as they need/please, route the sound through them accordingly and present themselves in big and flexible GUIs.

After this step the LMMS internal plugins and instruments would look and behave much more like 3rd-party plugins and VSTs. Each could have it very own character.

Change for the second click issue

It seems like the second issue in the list of click issues (found at the end of this comment) must to be changed from "Zero-length notes aka instruments and samplers in the Pattern Editor" to "Enable default envelope settings per instrument" then.

[RoxasKH]

@michaelgregorius if you pause or delete a piano roll segment while it's playing, the click still occurs even with #6864.

* Do you believe that "note off" bug's scope should NOT include the pause button?

* Should the pause button honor the envelope? (Are we OK with this for super long releases?)

* Converting a zero-length B&B track to a Piano Roll track re-exposes this bug.  Is this out of scope?

* Dragging an instrument directly to the B&B editor re-exposes this bug.  Is this out of scope?

Some presets such as DirtyReece.xpf do not have a default envelope, so the click can still occur regardless of this patch. Do you consider this in-scope for this bug report? Is the preset at fault, or the behavior of LMMS? (e.g. Should we activate "ghost" envelopes or use the default envelope proposed in #6864?

I'm not going to go into detail in what the "DAW" is in the context of this bug report, it's just TL;DR, I'm just advocating for a palatable solution that fixes the behavior like everyone else.

I'm still not convinced that toggling the envelopes on by default (depending on drop target), is the fix for it, however, I can say that the new envelope values in #6864 are a much improved experience over the old envelope values. Most instruments "just work". I played a few drum samples and they sound good too, but there are still many scenarios in a normal workflow that I feel are not addressed.

This is what i agree the most with: while activating envelope by default it's easy to implement and present us a way better condition than the actual LMMS state about clicks, the problem is still not fixed at its root. If an interpolation or different fix will be anyway needed to fix the remaining clicks among the app, which would also automatically take care of disabled envelopes clicks, this feels more like kind of an extra step.

It's also true that this issue has persisted for a very long time in LMMS tho, gets new users far from the daw and there's been little activity around it in general for what i could see. So while i'm hesitant on the envelope fix as it feels like a temporary patch, LMMS would still benefit from it someway.

[michaelgregorius]

I have created #6885 to cover the issue of the clicks that are caused by the pause and stop events.

[michaelgregorius]

It's also true that this issue has persisted for a very long time in LMMS tho, gets new users far from the daw and there's been little activity around it in general for what i could see.

I agree. If you look in the comments of this video which was one of the motivations to do something about the volume envelope clicks then to you will find several people who state something like: "Ah, LMMS. It was the first DAW that I have used but then I found something else/better."

I have to admit that I'm also not "dog-fooding" on LMMS but this is in part my motivation to code on it and to attempt to improve it.

So while i'm hesitant on the envelope fix as it feels like a temporary patch, LMMS would still benefit from it someway.

I don't think it's a temporary patch. For every instrument that considers itself to be a synth an activated volume envelope is the very obvious first option to prevent clicks before any other magic is implemented. How many commercial synth plugins allow their users to completely disable the volume envelope? And even if it was possible: is it disabled by default or in the init preset?

[Erudition]

@michaelgregorius

There a[re] no "unrealistic jumps".

In the multitude of messages above, many users have already fleshed out this phenomenon. It is very much real, call it whatever you like if you don't like that term. I am not the first one to mention this, I am simply going along with the explanation that seems consensus by this point.

Otherwise, I think we're clear which phenomenon I'm referring to as these jumps.

["Forced Release"] is "normal" ADSR behavior then.

Exactly. Whereas the click smoothing is not a feature in the Zyn UI, but built in to the software, not optional, and as far as I can tell, disabling it has not been a requested feature.

Well, it can be part of an instrument's sound because you currently hear it very often in LMMS. 😉 And who's to say what a "real" instrument should sound like and what's desirable?

I don't think that's as unanswerable as you make it sound, but to keep it constructive, perhaps you can ask the plugin authors if they desired the clicks. Especially the ones that also work on other DAWs, since other DAWs don't produce this artifact.

What I find important, and I hope that we are all on the same page here, is that the smoothing should not take place in the signal path of the DAW/LMMS itself.

What I have been highlighting is precisely that we are not all on that page. Perhaps there is a "vocal minority" effect going on here, but reading the entire thread gives a bigger picture. There are at least as many people arguing for built-in-smoothing as there are for "just enable the envelopes".

Plugins and instruments however are free to implement whatever they want because their job is to create/manipulate sound. Users expect them to "mess" with the sound.

Users also expect a smooth out-of-box sound that is consistent and does not produce artifacts under weird specific circumstances. Forcing the envelope by default could hide this, but many of us see this as a hack.

No, it does not [tell the speaker to jump to zero]. It tells the speaker to ideally fade out with a sinc tail

I am not conflating theory with practice. The speaker will try to approximate the input, subject to the limitations of the laws of physics. The better the input signal respects the laws of physics, the more theory (the instructions) and practice (the physical output) will be aligned. The interpolation fix brings these together.

So nothing physically impossible is happening here.

Of course not, please re-read. Nothing in my comment suggests that something physically impossible actually ends up happening. That would be... physically impossible. I was riffing off the older discussion from comments such as this one.

In a sampled system it is not even possible to define an input that results in the speaker being told to move infinitely fast to its resting position.

Of course not, but you can try, and again, this is what you get.

implement something in the signal path of the DAW itself, which is a very bad idea.

This is the very opinion being debated. Simply restating it as a fact is not constructive. The case has to be made, and even then there are other programs doing this and no one is telling them it was a "very bad idea".

This "problem" cannot and should not be fixed "for good" because it is impossible (and not a general problem that needs ultimate fixing anyway).

Again restatement of opinion - but "cannot be fixed" is simply not true, again it has been fixed in other software.

1. The clicks are attempted to be fixed in the plugins. Someone will write a plugin that creates clicks. The problem is back.

That is your solution, sure, though it's not even clear that it helps in the "DAW pause" scenario. Also, cross-DAW plugins don't have to worry about this on other DAWs, so it's not clear that they should have to change anything.

2. You attempt to solve the clicks in the signal path of the DAW itself. Now you have non-transparently broken lots of other use cases people might want to achieve in their DAW.

The "non-transparent" aspect seems to be a non-issue judging by other implementations, and by the same logic the idea that there are "lots of other use cases". You mentioned a single esoteric use case, but can we find any that can't be achieved by other, more explicit means? Of what remains, can we find LMMS music in the wild actually relying on this?

The burden of proof is high here. It's great to develop software around real, proven use cases, but until then the principles of OOBE should come first. If someone needs clicks, perhaps what you said earlier would happen - "someone will write a plugin that creates clicks" - except on purpose this time.

A quote from @he29-net analysis earlier in the thread:

It doesn't even need to go through D/A conversion; whenever you have a sharp angle like that in the signal, you are including high frequency components (sine waves) in order to make it. To get a perfectly sharp change in the signal (e.g. a square wave) in the real world, you would have to include infinitely many of these components, expending infinite amount of energy. That's impossible, so the speaker driver does exactly what SecondFlight pictures above -- it just makes the signal as sharp as possible within its limits. The better the speaker, the smaller and faster the "ringing" will be, and the louder the clicks will become, since it will be able to include more of these high frequency components.

And @tresf capturing why it's too early to say one solution is agreed to be superior as a matter of fact rather than opinion

I'm just advocating for a palatable solution that fixes the behavior like everyone else. I'm still not convinced that toggling the envelopes on by default (depending on drop target), is the fix for it

[zonkmachine]

I am simply going along

FYI. I'm starting to swing away from interpolation.

[Spekular]

I don't think that's as unanswerable as you make it sound, but to keep it constructive, perhaps you can ask the plugin authors if they desired the clicks. Especially the ones that also work on other DAWs, since other DAWs don't produce this artifact.

From the very comment you've linked (emphasis mine):

I have never heard such a click in any other synthesizer except the lmms synths. I'm pretty sure they finish the cycle for avoiding this.

Preventing amplitude jumps should be left to the synth, not the DAW. The example you later link of "other software" fixing this via interpolation is in reference to ZynAddSubFX, which is also a synth.

[Erudition]

@Spekular you're right that Zyn is not a DAW, but the other software I meant includes DAWs as well. The "I'm pretty sure they finish the cycle" turned out to be false in this example.

Either way, sure, you could apply the fix "unilaterally across all LMMS synths" rather than at a higher level in LMMS itself, the audio output and OOBE is the same.

@zonkmachine my bad, that point was meant to be about the explanation of the bug, not the fix. Edited.

[michaelgregorius]

Thanks for your answer @Erudition.

Separation of concerns between a DAW and plugins

@Spekular has already alluded to the difference between the DAW and plugins. However, to get a mutual understanding I'd like to give a picture of how I see the separation of concerns between the two.

Concerns of the DAW

When it comes to sound processing a DAW to me is a pure tool that manages audio signals (samples, MIDI). It puts them through a graph that for example consists of sends to other channels, plugin chains, etc. At the end of all that is a master channel where it all comes together.

Examples of audio sources are:

• Samples that are put directly into audio tracks
• MIDI clips which route into plugins that generate sound, i.e. synths, samplers, etc.
• The output of every plugin

When the routing is done a DAW should not mess with the signals by itself (except for things like mixing of course). It must not take the output of one plugin, alter it intransparently and then feed it into the next plugin. If a DAW decided to do so it would be a bad OOBE because it would do unexpected stuff that no other serious DAW does. Examples for bad unexpected stuff follow later.

The DAW merely provides a flexible, reliable framework that can be extended with plugins.

Concerns of plugins

Plugins are used to extend the functionality of the DAW in flexible ways. The manipulation of audio signals is mostly done by plugins. They provide the users with the option to opt-in into certain sound processing. This way the user has all freedoms to mess with the sound. Therefore plugins can implement whatever functionality they want because they are not forced onto users. Because they are visible in the audio chain there are also no surprises.

Separation of concerns redux

So there is a clear separation between:

• The DAW does not alter the sound in any unexpected ways.
• Plugins can do whatever they want because users must opt-in into them anyway. If a plugin sounds crappy just don't use it.

It's no surprise that DAWs have evolved into this direction very early on because it gives maximum flexibility with expected results.

Let's please split the issues

Reading back through some of the comments I think that several different problems are all mixed up into this issue (clicks due to inactive envelopes, stop/pause clicks, etc).

Therefore I proposed to create new issues to discuss them separately (see the list at the end of this comment).

The pause problem for example must be fixed in the DAW because obviously there is no plugin that implements the play/pause/stop functionality of LMMS. It's part of the core/framework. However, this problem also does not need a generic solution as it has a very specific cause. To my understanding the original issue was not about the stop/pause problem because I also get the shown wave forms if LMMS is playing.

Here's an example for the confusion where I was not talking about the "DAW pause" problem:

1. The clicks are attempted to be fixed in the plugins. Someone will write a plugin that creates clicks. The problem is back.

That is your solution, sure, though it's not even clear that it helps in the "DAW pause" scenario. Also, cross-DAW plugins don't have to worry about this on other DAWs, so it's not clear that they should have to change anything.

Going through the arguments

With the picture above in mind let's go through some of the arguments again.

Examples for breakage and why it's a "very bad idea" to fix in the DAW signal path

implement something in the signal path of the DAW itself, which is a very bad idea.

This is the very opinion being debated. Simply restating it as a fact is not constructive. The case has to be made, and even then there are other programs doing this and no one is telling them it was a "very bad idea".

Please note that I referred to the signal path of the DAW itself, i.e. the routing inside of the DAW and not inside of a plugin. So which other DAWs do this?

There are two scenarios which would break if the DAW itself somehow messed with the sound:

• When I developed a compressor I created a WAV file that contained a step, i.e. several zeros followed by several ones. I have then fed that signal into my compressor and rendered the result. I have then checked if the curve looks as expected. If the DAW would have decided to mess with the signal before it was sent into my plugin, e.g. by applying a filter of linear interpolation between the step, I would have seen different results and would have thought that something was wrong with the implementation of my plugin when in fact it was unexpected behavior of the DAW.
• User might want to put a "dirac" pulse sample onto a track and send that through a reverb plugin to obtain a (static) impulse response of the reverb. If the DAW messed with the "dirac" pulse before sending it to the reverb the result will be suboptimal and not represent the real behavior of the reverb.

Please tell us exactly how to fix the problem for good

@Erudition, you seem to have promised to fix the problem for good some comments ago:

we eliminate these artifacts wherever they appear, for good.

By that I assumed that you meant that the problems cannot ever show up anywhere in any form in LMMS again. Please tell us how you want to implement this.

My argument is that you cannot fix it in this broad scope because if you fix it in the LMMS plugins then external plugins might show the behavior. If you fix it in the DAW you create other problems (see above).

2. You attempt to solve the clicks in the signal path of the DAW itself. Now you have non-transparently broken lots of other use cases people might want to achieve in their DAW.

The "non-transparent" aspect seems to be a non-issue judging by other implementations, and by the same logic the idea that there are "lots of other use cases". You mentioned a single esoteric use case, but can we find any that can't be achieved by other, more explicit means? Of what remains, can we find LMMS music in the wild actually relying on this?

The burden of proof is high here. It's great to develop software around real, proven use cases, but until then the principles of OOBE should come first. If someone needs clicks, perhaps what you said earlier would happen - "someone will write a plugin that creates clicks" - except on purpose this time.

Again, I was talking about what's done by DAW and not what's done by some plugins. Can you show me a DAW that messes with the sound intransparently and where users are OK with it?

The physically impossible stuff

So nothing physically impossible is happening here.

Of course not, please re-read. Nothing in my comment suggests that something physically impossible actually ends up happening. That would be... physically impossible. I was riffing off the older discussion from comments such as this one.

Quoting you here:

• "and would not happen in real life (with the fastest string-dampening method physically possible, even)."
• "By fixing this issue with interpolation - again, only the bare minimum to cover physically impossibly extreme jumps, not a radical softening - we eliminate these artifacts wherever they appear, for good."

The first sounds like you imply that LMMS does something that's physically impossible because it does not even happen with "the fastest string-dampening method physically possible".

The second quote contains "physically impossibly extreme jumps" verbatim.

Third-party plugins that work in other DAWs but not LMMS?

I don't think that's as unanswerable as you make it sound, but to keep it constructive, perhaps you can ask the plugin authors if they desired the clicks. Especially the ones that also work on other DAWs, since other DAWs don't produce this artifact.

Sure I will ask them. But first please provide me with a list of third-party plugins that create artifacts in LMMS but not in other DAWs. LMMS' native plugins don't work in other DAWs so you can't be referring to them. However, these plugins are exactly the ones that this issue is about. So I don't understand your argument.

Are we on the same page now?

What I find important, and I hope that we are all on the same page here, is that the smoothing should not take place in the signal path of the DAW/LMMS itself.

What I have been highlighting is precisely that we are not all on that page. Perhaps there is a "vocal minority" effect going on here, but reading the entire thread gives a bigger picture. There are at least as many people arguing for built-in-smoothing as there are for "just enable the envelopes".

If you refer to the plugins when you write "built-in-smooting" I am OK with that. However, please note that in my original comment I was arguing against implementing it in the DAW, i.e. into the routing framework, as described above.

[michaelgregorius]

Instead of only asking to split the issues I have now created issue #6895 ("Provide default volume envelopes on a per-instrument basis"). 😅

So we now have:

• 6885: Issue for the clicks that are caused by the implementation of the stop/pause button.

• 6895: Proposal for a more "fine-grained" fix for the clicks that are caused by inactive volume envelopes. Would supersede pull request #6864 if implemented successfully.

Are there any other known click causes for which issues should be created?

Edit: Added the overview and the question at the end.