Fix the clicks heard during instrument note-off . #3086
Comments
|
Like minimalist envelope-by-default? |
|
@tresf yeah for now that would solve the "click" problem I guess. |
|
@mikobuntu Could you please clarify the point about "crossover of non zero"? 😮🤔 |
|
|
|
Oh... I think that's not really an internal issue as much as one of setting more sane default values |
|
Perhaps an oscillator should always finish the cycle? |
This would cover it sometimes but it could cause unnecessary runoff. I feel like it would be less accurate versus just @sloping/leveling-out/centering the wave (whether through a default envelope or through code). The approach should also scale to other potentially spike-prone cutoffs. Most DSP is prone to this because most instruments generate waves which could suffer the exact same problem (unless they are coded to avoid this) |
|
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. @fundamental how does zyn handle this? |
|
@BaraMGB From doing a live recording of playing random length notes in the triple_osc in Audacity I noticed that the waveform always starts correctly, but depending on whether or not the note ends exactly at zero crossover, the cycle is cutoff at a non zero point, which always causes a clicking sound. I assume that zyn finishes out the cycle. ( i will check this now ) |
|
Any rapid change in volume within zyn results in an interpolation from the current value to the destination value over the course of a processing unit (buffersize in zyn terms). Just a simple linear interpolation to zero over 32 samples should be plenty to avoid the clicking. |
|
@mikobuntu zyn does not finish the cycle |
|
@fundamental Just seen that from your previous comment, perhaps you could guide the team on how to achieve this with the LMMS synths. |
|
@mikobuntu without making the commits myself I'm not sure what there is to guide beyond just repeating that parameter values should be interpolated when there are large deviations and linear interpolation over a handful of samples tends to be enough to avoid pops. |
|
Isn't the issue here just that by default there is no envelope and a note plays at full volume with no attack or release time? |
mikobuntu
changed the title
|
@grejppi I guess that would solve the issue ( for now ? ) . I think I can code this up easily enough in EnvelopeAndLfoParameters.cpp with sane values. I think I'm just wanting to have a permanent or more code based approach, which would cover all aspects. |
|
@tresf I have made a mess of my pull request ( on my local branch ) . It is showing all my changes , like updating my branch. I had done the patch firstly directly in Github and I believed at the time that it didn't work so I redid it in the terminal, so basically the patch it there ready for review, but there will be annoying messages in there. Is there an easy way to fix this. Thanks 🤕 |
|
@mikobuntu the best way is to actually backup your changes first. fetch upstream: Then, go and reset your branch If you were already on a separate branch, skip this step, but otherwise, if you're on your fork's Then, do your changes again (from the backup) after that, you can commit: And then just push your new branch: After that you can make your pull request on github and all should look well. |
|
@Umcaruje thank you for such a detailed explanation, I will get to work on it now :) |
This is the technique I use... generally |
|
@tresf I had tried the HEAD~( number of steps backward ) but forgot about rebasing. |
|
My MIDI device allows adjusting the volume of a note whilst playing it. That said, I have to turn this feature off with LMMS because then the non-zero-crossing clicks happen at every sample, causing a buzz of clicks throughout the note. Can't wait for this to be fixed! |
|
@mikobuntu Sorry, I forgot to get back to you after reverting #3090 .
Pseudo code: 'track->instrument->name()' if( 'track->instrument->name()' == "audiofileprocessor" )
{
m_amountModel.setValue( 0.0f );
}Code above goes here. |
@michaelgregorius I think there are two somewhat similar proposals, both inspired by Zyn IIRC. (EDIT, or not, see below) The "interpolation solution" was related to what ZynAddSubFX does internally, explained here by Fundamental (Zyn maintainer): #3086 (comment) In our context, it would mean constantly monitoring the signal for any rapid changes, and essentially smoothing out the transition by linear interpolation over the duration of one buffer period (so 256 frames or less in our case, since LMMS chops up longer buffer to smaller pieces to keep automation "smooth" if I'm not mistaken). This solution is Bad, because it filters out intentionally generated impulses etc.; i.e. the "DAW has no business babysitting the signal" argument. The "sinc tail" solution is what I thought Zyn does at the start and the end of outputting any signal (i.e. an "integrated invisible envelope") to safeguard against any pops and clicks, but searching the discussion, it seems I got the proposals mixed up and you were actually the first one who mentioned the term "sinc tail". I just assumed it would be the ideal shape for the "invisible anti-click envelope". The advantage would be that the user would be completely free to do what they want with the primary envelope, and the anti-click envelope at the end would still safeguard against random loud pops and clicks, no matter what. It could be very aggressive (very short) to minimize its impact on other stuff; even a ~10 sample long anti-click envelope could go a long way and make most clicks nearly inaudible. |
I believe this is extrapolating a bit. If we're to divide this "fix" into two options:
From my testing with another DAW, it's fixed elsewhere there, which contradicts many in support of the first option. The fact that the envelope is disabled by default in another DAW supports that it should be addressed elsewhere.
I actually agree that interpolation should be left alone with AFP. If someone loads clicky sounds, that's the way the sound was intended. I also believe envelope should be off by default with AFP. The sample should be the sample, hard stop.
What's being referred to as a "configuration issue" is also a proposal to fix THIS issue, so let's not minimize it. e.g. if we want a different default envelope AND the default envelope is enable by default the "configuration" will directly affect PASS/FAIL, so a "configuration issue" IS THIS ISSUE if it's the proposed solution.
I'm not sure how repeating this rhetoric (several time now) is helping reach a decision.
The project receives (and accepts) a lot of pragmatic, first solutions to problems. This is a first solution, yes, but pragmatism actually is part of each disagreement. To argue that one's ideas are pragmatic, but another's ideas are not is not constructive.
|
@he29-net thanks for summarizing. I think fixing this inside the stock plugins is actually the best route forward, quoting @Spekular: I wasn't convinced of this until I compared behavior to another DAW. I don't have any other DAWs installed though, so if this is completely off the mark, I'd love to know how other softwares tackle this problem. |
May I ask why the solutions are mutually exclusive in the first place? Turning on the envelope on the synths will give a better user experience because it's what people are used to in most synth plugins. It also fixes a major source of clicks right now.
The "configuration issue" referred to my branch, where the values of the default envelope are defined in one place. It was meant as an offer to change the values because you said that "our old Envelope (e.g. before #6895) visually looks more like an envelope". I don't understand where this polarization on the two solutions comes from. I just want to provide a solution to the users. This comment read a lot like "us vs. them" to me.
It's meant to show that for some reason no decision is reached. There's a working solution now and one "solution in the sky". Yet, the working solution is held back because one day the other solution might be available. Did you read the comments in the YouTube video that I have linked? There are several comments by frustrated users who never found out how to get rid of the clicks. They have been left hanging for these seven years due to some discussions about theoretical solutions that no one ever coded up. In my opinion this issue should have been fixed with a quick fix to the envelopes years ago. This would have immediately removed the clicks on many instruments in their default setting. First impressions count. And if there's another implementation that's better then it could just have been merged and the envelopes deactivated again if that's how FL Studio does it. All these users have gotten no solution at all.
Ok, this project seems to be more about word definitions and rhetoric fallacies than implementing features for users it seems. 😉 So, how successful is the practical application of the "interpolation solution"? It's also a very nice touch that you accuse me of being "not constructive" although I have provided working code to the project which solves the problem in many cases. What's the "Make developing more attractive" issue worth if this is how contributors are treated? Anyway, perhaps I should write my experiences with the project down in that issue. |
I've asked nicely to stop this rhetoric. Now, I'm demanding such. This is no place for this.
I am curious as to the outcome of this as well. I believe 3xosc would be a good first candidate for this. We may choose to share this plugin code with others if proven successful.
Please stop dramatizing this situation. The community (Discord, Facebook, Forums) are extremely helpful to users that suffer this problem, often within minutes of someone asking.
On second thought, I think I'm wrong with this and it'll need some form of interpolation as well for instances where the sample is cut short (e.g. piano roll). |
Because:
... for these reasons, I would strongly discourage against the proposed solution, instead favoring a solution which fixes the problematic plugins with and without the envelope enabled. |
This comment was marked as off-topic.
This comment was marked as off-topic.
The thing is, i haven't really seen many DAWS having a separate Envelope tab either. It's not about being an FL clone, it's about the fact that if FL Studio is the most similar DAW to LMMS in this circumstance, it sets a primary example for it. It's difficult to compare something that doesn't seems to be a standard in these softwares. Looking at other DAWS it seems like they avoid these issues by having some kind of ADSR internally for every instrument or sampler that is. Taking in example MuLab, as its demo is portable and i don't have easy access to other DAWS except FL and LMMS (and Reaper ig which is the type of daw not to have lots of native synths or native samplers afaik), if you import a sample as a pitched sample it gets loaded with the native sample player, which has a default envelope that you can't turn off. If you set the release to 0 a click surely appear tho. But as said this is something managed internally in the plugin, as there's no separate envelope tab, which is something i personally have seen only in LMMS and FL up to now. Also this doesn't mean they aren't using any kind of interpolation fix as the DAW doesn't have any clicks with "sample tracks" like in LMMS either. It is also true that it's a project on a way smaller scale than pro daws like FL or ableton and so on. I reread the whole topic although a bit on a rush and the zero cross things isn't an option and that's true, but it seems like interpolating would still cover up for any unwanted click issue, and that would leave the envelope untouched. The thing is that, in my mind i would have no issue to activate envelope by default as a fix, but if an interpolation fix do arrive in the future, it would feel weird to have activated by default envelopes, and it would be even weirder deactivating them by default again.
I think we're all aware about how this affects first time experiences with the software. Hell, i was among the ones that was annoyed by it until i discovered the envelope, and it's certainly not nice having to activate it every time. That's why this issue exists, too.
I guess it could be done. It would be a temporary fix, and it would be weird to revert the behaviour back, but it certainly could be done, i'm trying to think about any edge-case that could break but i can't picture one in my mind roght now. |
What do you mean when you say they change the sound? It's their job to change the sound. Or do you mean in some other ways than applying a volume envelope? I don't hear a very big difference in the sustained sound when I turn on the envelopes. Except that they remove the clicks.
I don't really think users have these fine grained expectations that you describe. I assume that they just want nice sounds and that this includes no clicks. If you default activated the envelopes then most users would not find it strange or unexpected at all. Especially if it's users coming from DAWs other than FL Studio and/or that are used to commercial 3rd party synth plugins (VST, etc.) and hardware synths. My question with regards to FL Studio is now answered as well. I now understand that FL Studio seems to be the reference that is still "mimicked". I honestly just wasn't aware of that. I know that LMMS has it's roots as an open source alternative to FL Studio (or I guess "Fruity Loops" then) but I always assumed that it wanted to go it's own direction in some ways. Especially since FL Studio has pulled so far ahead of LMMS anyway. But obviously this assumption was wrong. This is why I did not understand the insistence on the "interpolation" by some people here. |
You're kinda bending words. It's not that FL is the reference that still needs to be mimicked. It's just that looking at professional DAWs it's a great help at understanding industry standards, and as LMMS has its root as an FL alternative, although it's now distancing itself, makes some things, as the envelope tab, something comparable only with FL Studio itself. Or, at least, i tried giving a quick search about envelope tabs on Ableton, Cubase, Bitwig and Studio One and couldn't find anything, all seemsto work quite differently with envelopes. If we were to look at other daws than FL, it seems to me that we should just give up on the envelope tab and implement the envelope within every native plugin instead. Which i guess it's doable but it would kind of drastically change LMMS workflow from a UI perspective (other than probably being a way more big job) and will still require interpolation anyways for the clicks that aren't fixable by applying and envelope. At this point i'd rather have people with experiences with other DAWs adding their bit to it tbh.
LMMS does want to go in it's own direction and it's already doing it. It's drastically different from FL Studio under lots of aspects, even the base workflow is as it doesn't revolve only around a pattern editor. Same goes for the mixer and lots of other things. The insistence on the interpolation is because that would probably fix any click when there's a drastic change in audio, and so making default envelopes unneded. It's kinda easy to see where it goes past just activating the envelope as it would be more of a global fix, possibly making the default envelopes change no more useful. |
Is this "interpolation" intended to catch these drastic changes in the midst of a signal? From many descriptions it reads like this. If that is the case then we can stop calling it "interpolation" and start calling it a lowpass filter because that's what it is then. The signal that changes the most dramatically is something like [1, -1, 1, -1, ...]. This is a signal at Nyquist frequency. If you want to kill these kind of signals/frequencies then you are implementing a lowpass/highcut filter. So this fix would be about implementing a lowpass filter with a very steep cutoff in all LMMS instruments. IIRC this will either mess with the phase of the signal and/or introduce some very non-linear frequency response, i.e. color the sound. And I think a low pass filter would not even really do the job as the click contains the whole frequency spectrum. So you would still hear the lower frequency components of the click. I would really appreciate if someone could describe the idea in more detail than just linking to Fundamental's few sentences which don't really give a whole picture. Is it a lowpass filter that should catch the signals everywhere? Is is some release envelope that's triggered on note-off events?
It would be nice if the work was not wasted. However, now I am not too sure anymore about moving the envelope and LFO class into the instrument as was done in the branch. It was done through the eyes of a non-FL Studio DAW user and from that perspective it seemed natural because as you have noted other DAWs don't have that. |
|
I feel like both camps prefer their solution because of the similar concerns, and that is "don't touch my synth output". @michaelgregorius prefers enabling envelopes by default, so that there is always the option to turn them off completely and a get a raw, untouched signal out of any synth. @tresf is against solving clicks by enabling envelopes because it means we would be touching the synth output by default. And to make things more complicated, kind of I agree and disagree with both of these camps:
So going back to the "fix the synths" solution, I would split it into:
For sample-based playback, we never want to touch "start" and "expected end". If the sample contains a click, well, tough luck dear user, get a better sample. But we should gradually fade-out in the "unexpected end" case, because there is basically no way to avoid having random clicks otherwise. And because those clicks are random, I would argue they have limited artistic value and do not need a user configurable option to preserve them. For synthesizers, things are not so clear. I believe that we should not touch synthesizer starts. For example 3osc starts with a small inaudible click, because the sine wave starts abruptly from a zero line. But this click is consistent, and while not very loud, it may add some "punch" or pluckiness to the note. It can be also controlled by shifting the phase, so the user may intentionally make it louder. And so on; a fixed fade-in envelope would interfere with this use-case, so "start clicks" should be left to the user and optionally enabled envelope (default off, because start click is not disruptive or random). The problem is with "expected end" and "unexpected end". In a way, for most synths, all ends are unexpected, as they could go on forever. So I would argue we should apply a short fade-out on most, if not all, "clicky" synths in LMMS. The synth cannot predict when the note ends, so the end always comes "at the wrong time" and causes a click. Depending on how exactly the wave looks at the time, it may be a loud, or less loud click. At random. I do not see any value of allowing such random artifacts, so I do not see a need for a user configurable option to preserve them. Is the "fix the synths" solution something we can agree on, or are there any use-cases it would affect? I don't think we need to emulate artifacts of hardware synthesizers (if that is the intention, we may add a clicky "analog" version of 3osc, but it should not be the default), and by only fading out "unexpected ends", use-cases like an impulse being send to a convolution reverb are possible as well. Anything else I missed? Signing off from the "invisible envelope" camp... 🏕️ |
This fixes to bugs leading to clicks on instrument note-off in most instruments. The first bug was introduced as part of a refactoring done by Vesa [1] and caused each note play handle's last buffer being dropped because the play handles were deleted before being processed in AudioPort. Thanks to @lleroy for pointing this out. [2] The second bug / typo has always been there [3] and was a misplaced parenthesis in Instrument::applyRelease breaking the calculation of the note-off envelope's start frame, sometimes putting it outside of the buffer. Fixes #3086 [1] 857de8d and related commits [1] #3086 (comment) [2] 0243338
|
Right, see d962070 for a possible patch to restore the instrument release envelope that has been in LMMS since 0243338 but was broken nine years ago in 857de8d. Pushed to Hopefully at least fixing that regression is something we could all agree on. Before/after examples:
|
@lukas-w I see; I did not actually check if changing the starting phase make the clicks louder, I just assumed it would because there is no fade-in. So maybe it's the recently added fade-in that makes the start click weaker and consistent, and not just the default start from zero. At any rate, if nobody complained at the time, I don't have much issue with it. There are probably other, more controlled ways how to add "punch" or "pluck" to the start anway. Good job on finding that regression; I see while this discussion slowly devolved into a war zone, you simply went to work and implemented a fix. Respect. :) |
I mean, the envelope, historically, and in other software sounds different once activated and disabled (immediate feedback to the user). The proposal greatly hides that trait, which is not desired. |
I understand your point and I have different views, opinions and experiences. I feel like I have spent/wasted(?) way to much time on this issue so I will let it rest now. It seems that all this activity has at least finally led to the implementation of the preferred alternative solution which is good for the users.
I agree that it is good to finally have a(ny) fix that solves the problem. 👍 The "you simply went to work and implemented a fix" aspect is where my frustration towards the end of the discussion came from by the way. I didn't just talk and argue either and instead also went to work and implemented a working fix. However, in that case the work was not appreciated although it solved the problem, albeit differently. But at least some other aspects of the project are a bit clearer to me now. Thanks for the moderation towards the end, @he29-net! |
|
@michaelgregorius Oh, I did not mean to imply you did not put in any effort into this. Actually implementing your proposed solution to show how it would work is way more than I or anyone else did. And you have been one of the most active contributors lately, which is definitely very appreciated. It's just that when Lukas appeared out of the blue with a fix to an actual bug that started all of this, it felt like an intervention from a higher power. :) I built the fixed branch and played around with 3osc and AFP, and can confirm the note-off clicks are gone. Or more precisely, "technically still present, but inaudible". Looking at the Waterfall display in Spectrum Analyzer, the clicks at the end are now weaker than the "stable" clicks at the start. Which makes sense to me (the end click is less predictable, so it makes sense to me to suppress it more). The diff looks good to me as well, so if anyone wants to do a "second review" (even though it's not a full PR), maybe we could get it merged today? It may be also a good opportunity to release a second 1.3.0 alpha. And / or a 1.2.3 stable, since a new stable will take some time still, and I agree that "first impressions are important". :) |
Sorry, I didn't mean to devalue your work ❤️ I have no doubt that everyone here appreciates the time and energy you invest into this project and I know it can be really disheartening to feel like that investment is wasted, especially for someone who cares so much about the product and its users as you evidently do. Just like any other open source project LMMS wouldn't go anywhere without that healthy dose of passion. But when passion turns to temper and strong clashing opinions turn progress into stagnation, it may be time for everyone to take a step back and find a less controversial way to work towards the same goal. Even if it's just for the sake of preserving ones passion and energy. After all, the goal itself is clearly shared by everyone here. So let's get there one baby step at a time. I hope that my fix can be that uncontroversial baby step. It's a tiny patch that restores functionality the way it's been before and to my knowledge no-one has complained about it at the time it was still working. It's likely not the end of the story though. I don't think it fixes all instruments and there are probably more bugs waiting to be discovered. Also some of the points made here will still be valid regardless of this fix. I'm not interested to take part in that discussion though 😁 |
Just like I intended 🧙♂️ Time to disappear for another three years and resurface when you least expect it - can't lose that mystical air that now surrounds me! 😄 |
Appreciated != accepted. That said, since you were the one that resurrected this two weeks ago, and also the one that typed the most comments in those two weeks, I can see how this may have been inferred. I'd chalk this up to the catfish effect. On a personal note Click to expand...I take this project a bit more personal than most, it's just my personality , I guess, but I haven't been feeling well IRL as a result of conflicts like this. Due to the escalation, I considered reaching out in PM to clarify any motives or lack of appreciation -- but I don't have a way to do this (please consider this an open invite, as well as a partial apology for any bad feeling I've caused - Discord, Telegram, Google Chat, Email). Without many people to talk to, I drafted a post to the admins on Discord, whom I respect , but many don't use GitHub, so I deleted it. Next, I discussed with my partner about this dilemma... how a fantastic developer (@michaelgregorius) was back helping again but how my perspective may be souring things, not be attractive to new developers, etc. All this while I've never coding one, single line of DSP code, so I can't even argue, technically. I'm not happy that the efforts weren't directly accepted, but I'm happy that it brought out the best solution. I personally struggle to find a path to that without driving certain personalities away. For that, I'm sorry. |
|
Thanks for the kind words @tresf! I haven't heard about the "Catfish effect" before. But sounds like it might very well have been in effect here. 🙂 Also continuing in an expander here... Click to expand...Partial apologies accepted! I'd like to offer apologies as well if some of my misconceptions about the goals of the project and the lack of knowledge about the specific requirements of this issue might have led to stress. I understand what you mean about the effects on real life as the exchange seems to have affected both of us. IMHO it's also an effect of how these kind of projects are structured/organized. There is no direct face-to-face communication and this can lead to misunderstandings and typing everything out also leads to lots of effort. So it becomes very frustrating on both sides if one gets the feeling of still not being understood or going in circles. If I find the time I will add some constructive feedback based on my general experiences in the "Make developing more attractive" issue. |
Sorry for your pain. I'd suggest the "path" is non-violent communication. It seems to me this is not necessarily a clash between personalities, but about how we communicate, especially when frustrated.
https://www.youtube.com/watch?v=LSGfqyhleUA How do we promote this on such an open collaboration forum as this... well, that's an open research question... |
|
I agree that good communication is important especially in a distributed project like this one. From the linked video I gathered that non-violent communication mainly works when dealing with emotions and opinions. However, this project is not only about emotions and opinions. I would say that many issues can be assigned to the following two categories:
I am aware that I write in an authoritative style sometimes but I hope that I only do it when it comes to science related things like DSP topics. When it comes to these topics I don't want to write in any different style about them because I don't want them to seem like opinions. Science and especially established scientific facts are not opinion. The fact that many people now (want to) believe this is a big problem of our times. Last but not least, @Erudition I hope you are aware that up-vote and down-vote buttons are a form of communication and that downvotes can be considered a form of violent communication. You were very busy with systematically downvoting my comments even when I was in "Giraffe" mode (a term from the linked video) and asked open questions to understand the other side like for example here. The ones which resulted in the opportunity for people to learn something about the DSP side or which brought the issue forward by ruling out some solutions were not upvoted either. |
My comment about communication was not directed at a particular person, it was about everyone, including myself. It stands on its own. But since you addressed me I will reply to your other statements.
Facts are not opinions, but being science-related does not make every opinion a fact. Fact-based conversations are full of opinions, especially judgements of those facts. I brought it up because the opinions which humans think are "based in fact and science" and tend to think of as not opinions are precisely the ones that typically cause communication problems on technical forums. It's not always necessary to avoid mixing them, but as soon as it becomes clear that not everyone agrees on what is factual or what one "should" conclude from said facts, going forward I try to put the facts/observations and the judgements separately in a sentence - the judgements typically being the phrases with things like "should" or "sane" or "expected" or "bad idea".
There is no voting going on; Github doesn't have downvotes but it does have reactions. Votes have consequences, reactions are human social signals and can't be wrong. The selection of emoji is intentionally limited to not facilitate violent communication - a "thumbs down" could mean "I disagree" or "this is not good rhetoric", which is not harmful but can be used to silently signal that harmful rhetoric has been noticed and should be curbed without a confrontation with words (which typically provokes more non-constructive rhetoric due to defensiveness). Relatedly, in Reddit land where "downvote" is used for real, it is strictly for marking comments that aren't constructively contributing to the conversation, not even disagreement (per reddit's rules, moderator enforced).
My reactions were about the dramatic rhetoric, as others called it. It does not always look like authoritative statement of opinion, though that was true of the earliest one. Like others, I did not want to expound on the reactions, specifically to keep the discourse constructive. But alas... In the comment you linked, you shifted the goalposts from "no other DAWs do this so we shouldn't either" to "oh so we want to be an FL clone" after evidence was presented that other DAWs do in fact do it, without acknowledging the pivot or verifying that "we want to be an FL clone" was actually a shared sentiment - instead stating it as fact ("I always assumed that it wanted to go it's own direction in some ways. But obviously this assumption is wrong.") to (as I interpret it, I'm sure you'll disagree) provoke a contradiction, which is indeed what followed. (Even if the rest of your comment was not, hopefully you can see why under this interpretation it contained "the Jackal".) Another downthumb was a comment involving the same tactic, this time conflating "your rhetoric is not constructive" with "nothing you do is constructive, not even the code contributions from earlier" which I (!) saw as a bad-faith interpretation to dodge the criticism and again provoke a contradiction from others (which immediately followed), and then the "project seems to be more about word definitions than users" poke. I don't think Giraffes are passive-agressive, but even without NVC as a goal, I hope this clarifies why a downthumb is a more amicable/constructive social signal than confrontation. Those are all of the three (3) comments of yours I was "very busy" with "systematically downvoting". But due to human nature I preferred not to spell it out as it's not likely to lead anywhere constructive - drama begets drama, and most of that phrasing gives you plausible deniability anyway. |
|
I still think the down votes were one sided, especially taking the fact into account that an apology was issued towards me as well. Perhaps there was some kind of bias in voting. IMHO down votes are the complete opposite of "Giraffe mode" as this mode seems to be about understanding the other side and giving them the chance to understand your own views. It's about engaging with each other. By just downvoting you rob people of that chance. Saying that this would just have made things worse sounds like a contradiction to me. You have to invest something in this mode, it does not come for free. The fact that the meaning of down votes can be misinterpreted because it's not clearly defined also shows that they are bad for communication because they introduce ambivalence and misunderstanding. Yes, I will move on as well. I think it's important to have a good communication but it will never be perfect anyway because we are all humans with our own experiences that we have made. I will now go back to providing features, bug fixes and results under these constraints. These things are important for a project as well. Currently I am trying to aid the implementation of #6908 as it does not seem to be as simple as previously thought, i.e. the code that was reactivated seems to have problems of its own which needs fixing. |
|
I respect your opinion, and I agree "perhaps there was some kind of bias in voting", probably the natural negativity bias, especially given they're reactions and not votes. Like many, I don't have much of a reaction to most comments, so I'll aim to generously distribute positive reaction clicks anyway. As far as the alleged contradiction, IME due to human ego defensiveness, people rarely respond constructively when confronted about poor communication, so it can be best not to dig into it (publicly at least). Thank you for not becoming an example of that. |
and others
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.
The text was updated successfully, but these errors were encountered: