Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird Behaviour of Delay Effects when Input is shorter than Delay Time #4284

Open
Sauerstoffdioxid opened this issue Apr 7, 2018 · 11 comments

Comments

@Sauerstoffdioxid
Copy link

Sauerstoffdioxid commented Apr 7, 2018

When a note (or sequence) ends before the delay starts, it will yield weird results. Most of the time it will simply not be delayed (i.e. the wet signal is silent) or it will play the delayed sound once the effect receives another input.

Steps to reproduce

Start LMMS, add an delay effect (preferably with feedback option), and play a short note. Or take a look at
this example project showcasing the behaviour for a couple delay effects with delay time set to a quarter note.

Expected Behaviour

All sounds are delayed/echoed properly.

Actual Behaviour

In the example project:

  • the first pattern is echoed/delayed in none of the instruments
  • when the second pattern starts, the delay of the first one plays on top of it (at least in the top 3 instruments)
  • the third pattern is played correctly by all effects since it's a quarter note long
  • if the sound hasn't gone silent before the fourth pattern starts (that should be on all but Echo Delay Line), it will be played correctly
  • because of the gap before the fifth pattern, the sound will become silent again. The pattern will play like the first one

Also, if you hold a piano key after the last pattern, you can hear the proper delay for that pattern.

@Sauerstoffdioxid
Copy link
Author

Another interesting thing becomes noticeable if you copy the short (e.g. the last) pattern between the 4th and the 5th pattern. (like this:)
grafik
It too will echo as intended at first but then suddenly cut off the moment the delay of the longer pattern (3rd) would turn silent (if it weren't followed by other patterns).

Additionally, I noticed that if the sound ends before the note ends (for instance because of an envelope) and the pattern (but not the sounds) is in total longer than the delay time, the echo will play for as long as the notes are long but at least one full delay.
Example test file.
Note that the delay that was cut off will play once the next input is received.

@musikBear
Copy link

if you change Amount in Vintage UI it normalizes
Amount must be > 0.25
Maby it would be logical to have Amount default be > 0? F.i. 1.0

@Sauerstoffdioxid
Copy link
Author

@musikBear Are you referring to Calf Vintage Delay? I agree, a default Amount of 0 is not ideal, but that's not what this issue is about.

@musikBear
Copy link

@Sauerstoffdioxid yes I should have written ' Calf Vintage Delay' not just 'Vintage', but Calf Vintage Delay will create a correct reverb, in your file, if you add Amount
-Must admit i have not used anything else than Calf Vintage Delay, it fills my needs
But something is off. It is only Calf Vintage Delay that produces the same output, independent of note-length.
(not using sine-waves makes it much more audible -btw)

@DomClark
Copy link
Member

DomClark commented Apr 8, 2018

I think what you're describing here is LMMS stopping running the effect since no audio is coming through.
If an effect stops outputting audio, LMMS stops running it until it gets input again in order to save CPU usage. With a delay effect, if the input is short enough to reach silence before the first echo comes through, this can lead to the problem described. Try turning up the "Decay" knob in the effect chain to a value larger than the amount of silence you have, or enabling "Keep effects running even without input" in settings.

@zonkmachine
Copy link
Member

Turning up the decay helped this. Should we have a higher minimum timeout() ?
https:/LMMS/lmms/blob/stable-1.2/include/Effect.h#L107
Something like Engine::mixer()->framesPerPeriod() ?

@musikBear
Copy link

@DomClark

enabling "Keep effects running even without input" in settings.

That changed everything! With that invoked, all output are independent and identical with all note lengths
But then the cpu-hit comes in.
Maby @zonkmachine suggestion is the right way to go, but on my humble box, i can run large projects with no cpu-issues at all. I wonder if this:
"Keep effects running even without input" in settings"
should be default ON in setting?
Very few users have a pc with less specs than mine i think (11 y old: Intel Core 2 Duo E6750, 2.667GHz, 1333SB
)

@Sauerstoffdioxid
Copy link
Author

Yes, that option makes it work correctly. I never new there was an option like that in the first place. Neither did I know just what that Delay knob was for. Thanks for the tip.

I agree with musikBear, this should probably be enabled by default (although I don't know what the average PC running LMMS is like). This might be an issue if someone is using some rather heavy VST plugin, but I don't think the internal plugins would be much of a problem. Also, I believe this is more of a performance option than a general one, so it may could be moved into the Performance tab.

@zonkmachine
Copy link
Member

Something like Engine::mixer()->framesPerPeriod() ?

@DomClark Tested this in #4291

@PhysSong
Copy link
Member

See also: #424

@PhysSong
Copy link
Member

PhysSong commented Jun 3, 2018

The setting "Keep effects running even without input" may look unclear for user and it's even more unclear auto-quitting may cause bugs. I think it should be clear for users that the side effect exists, or the feature should be dropped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants