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
>>
>