Re: Dynamic Compressor Effect
Robert Hänggi <[email protected]> Tue, 30 Mar 2021 09:07:07 +0200
| Newsgroups | gmane.comp.audio.audacity.devel |
|---|---|
| Message-ID | <CAJhgUZ3gf-6kgDvGtSmmCD+WFRhjJ7MRLgBfevP2NLRE1arPcw@mail.gmail.com> |
On 28/03/2021, Peter Sampson <[email protected]> wrote: > On Sun, Mar 28, 2021 at 12:46 PM Max Maisel <[email protected]> wrote: > >> Hi James, >> >> it's no problem for me to wait for the 3.0.1 release. >> > > Max, > > I'm hoping that between us we can get the real time preview working before > this > gets released - it will make it much more useful (and more fun). > I would go further and say that it is essential to have real time preview. Static preview without parameter manipulation is pointless, especially for a compressor. Not to mention that the conventional preview doesn't include other tracks and lacks therefore context. I think you have to make compromises on the Attack/Release calculations. Would it be helpful to work with approximations and the already stored peak/RMS values? The rendering (= applying the effect) could still be executed accurately though. Robert > Peter > > > >> The latency is mainly caused by various kinds of lookahead. One >> lookahead is selected directly by the user, another lookahead is >> implicit in case of the exponential fit envelope detector because the >> algorithm needs to process the signal backwards in the attack stage. >> >> Latencies in the range of minutes are extreme cases if users select >> high lookahead times or, in case of exponential fit, high attack times. >> But I don't want to limit the ranges of the lookahead and attack time >> sliders for offline processing just because of latency in realtime >> mode. >> >> When using the analog simulation envelope detector together with low >> lookahead (a few milliseconds) like a real analog compressor, there is >> almost no noticably latency. >> >> Max >> >> On Saturday, 27 March 2021 at 14:41, James Crook wrote: >> > Hi Max. >> > >> > The previous update I had on this was about the long latency. >> > Disabling realtime preview is sort of OK, but something seems wrong. >> > A one minute latency is colossal. That points to something >> > underlying wrong. >> > >> > Also 3.0.1 has now become very very much a maintenance release for >> > addressing the 3.0.0 unitary project issues. Paul would love to get >> > some structural >> > changes in that improve independence between pieces of code, and I am >> > saying no. >> > We'd also like to get portaudio and FFmpeg library updates in, and I >> > am saying no. >> > >> > It is pretty clear that the release after 3.0.1 is going to be quite >> > soon, so as RM >> > I'm sorry to have to say that your compressor will have to sit out >> > for 3.0.1. >> > >> > 3.0.1 is due to actually release on 17th April, so it's a further >> > delay of about 3 >> > weeks for you in seeing progress on your compressor getting in to >> > Audacity. >> > >> > Is there a good reason for the very long latency? >> > >> > --James. >> > >> > >> > >> > >> > On Sat, 27 Mar 2021 at 07:56, Max Maisel <[email protected]> wrote: >> > > Hi all, >> > > >> > > I've polished my Dynamic Compressor effect and think it is ready >> > > now >> > > for inclusion. >> > > >> > > Since my last mail (see >> > > https://sourceforge.net/p/audacity/mailman/message/37109016/ for >> > > the >> > > initial message), I mainly reworked the user interface accoring to >> > > your >> > > feedback and fixed several bugs. >> > > >> > > The effect is basically realtime capable but for now realtime >> > > preview >> > > is disabled after some discussion with Steve because there are >> > > bad user experience due to high processing latency in the effect at >> > > some settings. >> > > >> > > Main probleme here is, that the RealtimeEffectManager gives the >> > > effect >> > > a small block, e.g. 256 samples, and expects the same amount of >> > > samples >> > > in return. So if an effect like my compressor has a high processing >> > > latency, there can be an initial silence for over one minute which >> > > the >> > > users will think is a bug. Any changes made to the effect settings >> > > will >> > > only take effect after this long time as well. >> > > >> > > A possible solution would be latency compensation in the >> > > RealtimeEffectManager so that the effect can request the required >> > > amount of samples in advance at the beginning or when the user >> > > changes >> > > settings. The silence at the beginning can then be discarded so >> > > that >> > > users do not notice it. But this is out of scope of the compressor >> > > effect changes. >> > > >> > > The lastest revision including CI builds can be found in my pull >> > > request at https://github.com/audacity/audacity/pull/676. >> > > >> > > The latest documentation for the effect is can be found at >> > > https://alphamanual.audacityteam.org/man/Dynamic_Compressor. >> > > >> > > I'm looking forward to further feedback and integration. >> > > >> > > Max >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > audacity-devel mailing list >> > > [email protected] >> > > https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > _______________________________________________ >> > audacity-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> >> >> >> _______________________________________________ >> audacity-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >