I worked on <a href="https://github.com/magnetophon/faustlibraries/commit/ca99bc0c313c

I found the problem: basics.lib was using <code class

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

You can either do <div class="snippet-clipboard-content notranslate position-relat

Ok thanks - this worked: git clone<a href="https://github.com/magnetoph

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

trouble adding compressors,about grame-cncm/faustlibraries

Comments (25)

rmichon commented on June 19, 2024

Interesting... I've see this error before and it basically tells you that there's something broken in the libraries without really being very specific haha. So I'm afraid the only way to identify the origin of the problem is to comment things out step by step. I wish I could give you a better answer haha. At least you know that the issue must come from the change you've made.

Here are a few other things I've noticed while quickly looking at your commit:

You can't add:

declare author "Bart Brouns";
declare license "GPLv3";

to compressors.lib because it will be applied to all the functions declared in that library (including the one written by @josmithiii). @orlarey, @josmithiii, and myself were talking about implementing a declare that would be function-specific but we haven't done it yet. For now, you should put your name, license, and copyright outside of the comment section that ends up in the doc:

// Doc section
//-----------------------------------------------------
// Author: You
// License: STK-4.3

until we get something better...

I don't really like these: :)

rmsMaxSize = 2:pow(17); // highest usable for faust2lv2
sr = 44100;
maxRelTime = rmsMaxSize/sr;

especially sr that might create confusions with ma.SR. I would move those inside the function using them (using with{}) even if it implied redefining them internally a few times. Also, why do you need sr=44100? Does it mean that some functions were designed to work at a specific sampling rate? Why not use ma.SR? rmsMaxSize could be defined as a global variable of compressors.lib but it should appear in the doc in that case...

from faustlibraries.

magnetophon commented on June 19, 2024

I found the problem: basics.lib was using si. without declaring it.
When you remove the definition of si in basics.lib, you get:
BoxIdent[si] is defined here : routes.lib:39, and not undefined symbol : si
Would it be possible to get a better error message in that situation?

I fixed most of the other issues, but I'm still looking for a good solution regarding rmsMaxSize.

rmsMaxSize is the main factor in CPU usage, so maybe I should make it a parameter of the RMS compressors?
If not, I could move it inside RMS_compression_gain_mono, but that would not be ideal, because you need it to calculate the max value of the release slider.
A third option would be to leave it where it is, and document it.

Am I missing any options?

Another issue I'd like to fix is that the maximum release time depends on the sample rate, but a slider's maximum value needs to be known at compile time.
Any ideas?

Finally: should I add some compressors to demos.lib?
If so: in addition to the current ones, or instead of the current ones?

Are you happy with the rest of my code and comments?

from faustlibraries.

magnetophon commented on June 19, 2024

@josmithiii
In an effort to keep the discussion of each topic in the correct place, I'll reply to this here.

As requested, here is my compressors.lib.
It uses some functions I added to basics.lib.

Thanks for having a look!

Once you are OK with the content of those, I'll do a pull request.

from faustlibraries.

josmithiii commented on June 19, 2024

Perfect, thanks I know this sounds lame, but after 5 minutes trying I cannot figure out how to download the files for comparing in Emacs. What is the preferred method for this?

…

On Sun, Apr 1, 2018 at 2:40 PM, Bart Brouns ***@***.***> wrote: @josmithiii <https://github.com/josmithiii> In an effort to keep the discussion of each topic in the correct place, I'll reply to this <#4 (comment)> here. As requested, here is my compressors.lib <https://github.com/magnetophon/faustlibraries/blob/master/compressors.lib> . It uses some functions I added to basics.lib <https://github.com/magnetophon/faustlibraries/blob/master/basics.lib>. Thanks for having a look! Once you are OK with the content of those, I'll do a pull request. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFU_42iAdLQVWujTjWBfzTyg8TWY0ks5tkUlDgaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

You can either do

git clone https://github.com/magnetophon/faustlibraries/

or you can go to the links in my previous posts, right click the Raw button, and select save.

from faustlibraries.

josmithiii commented on June 19, 2024

Ok thanks - this worked: git clone https://github.com/magnetophon/faustlibraries faustlibraries-bart

…

On Sun, Apr 1, 2018 at 3:43 PM, Bart Brouns ***@***.***> wrote: You can either do https://github.com/magnetophon/faustlibraries/ or you can go to the links in my previous posts, right click the raw button, and select save. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFRU6hql5PlazT2fZbOFi-sUPdSahks5tkVgigaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

rmichon commented on June 19, 2024

@magnetophon it all looks good to me. I think there might a few changes needed in the documentation of some functions, but I can take care of that, shouldn't take too long ;). @josmithiii, once you say you're OK with @magnetophon contributions, can @magnetophon do a PR? Thanks for your hard work @magnetophon !

from faustlibraries.

magnetophon commented on June 19, 2024

@rmichon Cool. What should I do with rmsMaxSize?

from faustlibraries.

josmithiii commented on June 19, 2024

Today I looked closely at Bart's basics.lib and everything looks great. It was useful to learn about the inputs(b) primitive giving the number of signals in b. - Julius

…

On Sun, Apr 1, 2018 at 7:34 PM, Romain ***@***.***> wrote: @magnetophon <https://github.com/magnetophon> it all looks good to me. I think there might a few changes needed in the documentation of some functions, but I can take care of that, shouldn't take too long ;). @josmithiii <https://github.com/josmithiii>, once you say you're OK with @magnetophon <https://github.com/magnetophon> contributions, can @magnetophon <https://github.com/magnetophon> do a PR? Thanks for your hard work @magnetophon <https://github.com/magnetophon> ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFZUkd5Rq5ULGcvlIDtCHq5Y_7Ck3ks5tkY4zgaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

josmithiii commented on June 19, 2024

The only disappointment I noted was use of GPL instead of MIT or the like, since I avoid use of GPL code in my consulting work. - Julius

…

On Mon, Apr 2, 2018 at 5:37 PM, Julius Smith ***@***.***> wrote: Today I looked closely at Bart's basics.lib and everything looks great. It was useful to learn about the inputs(b) primitive giving the number of signals in b. - Julius On Sun, Apr 1, 2018 at 7:34 PM, Romain ***@***.***> wrote: > @magnetophon <https://github.com/magnetophon> it all looks good to me. I > think there might a few changes needed in the documentation of some > functions, but I can take care of that, shouldn't take too long ;). > @josmithiii <https://github.com/josmithiii>, once you say you're OK with > @magnetophon <https://github.com/magnetophon> contributions, can > @magnetophon <https://github.com/magnetophon> do a PR? Thanks for your > hard work @magnetophon <https://github.com/magnetophon> ! > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#3 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACGVFZUkd5Rq5ULGcvlIDtCHq5Y_7Ck3ks5tkY4zgaJpZM4S55YN> > . > -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

josmithiii commented on June 19, 2024

If I understand correctly, rmsMaxSize sets the maximum number of samples in the sliding rectangular window, and the issue is simply where to put it. I think it should be an argument passed to every function all the way down to maxn in slidingReduce. I would also make it the first argument like delay() and friends do. That way one can absorb it into the function name if desired: delay8K = delay(8192); The slidingReduce primitive added to basics.lib is a very cool construct (and not easy to write!) which achieves log2(N) complexity for performing N operations by doing them in a tree structure. However, note that in the present situation, complexity O(1) is available, e.g., slidingSumN(n,maxn) = slidingReduce(+,n,maxn,0); can instead be slidingSum(n) = _ <: fi.integrator, fi.integrator@int(max(0,n)) :> -; // 0 guard optional, but I would keep it Finally, note that slidingSumN and slidingMeanN have N in their names while other analogous functions do not. I would omit the N whenever the N=1 case is not an often-used case that would benefit from getting the "no N" version name instead of having to write functionName(1,...) all the time. This worked out well for maximize and bypass, for example, in basics.lib. I still need to look at the compressors, but I'm sure they'll be fine as long as old code does not break. If the licenses can be changed to STK-4.2 or MIT, etc., I will rewrite and/or deprecate anything I wrote, as appropriate, in favor of the new functions. (I think of STK-4.2 as "MIT + please share your enhancements".) Otherwise I will need to maintain a "parallel universe" of STK-4.2 compressors and such. Thanks Bart for these solid contributions! - Julius

…

On Mon, Apr 2, 2018 at 5:41 PM, Julius Smith ***@***.***> wrote: The only disappointment I noted was use of GPL instead of MIT or the like, since I avoid use of GPL code in my consulting work. - Julius On Mon, Apr 2, 2018 at 5:37 PM, Julius Smith ***@***.***> wrote: > Today I looked closely at Bart's basics.lib and everything looks great. > > It was useful to learn about the inputs(b) primitive giving the number of > signals in b. > > - Julius > > On Sun, Apr 1, 2018 at 7:34 PM, Romain ***@***.***> wrote: > >> @magnetophon <https://github.com/magnetophon> it all looks good to me. >> I think there might a few changes needed in the documentation of some >> functions, but I can take care of that, shouldn't take too long ;). >> @josmithiii <https://github.com/josmithiii>, once you say you're OK >> with @magnetophon <https://github.com/magnetophon> contributions, can >> @magnetophon <https://github.com/magnetophon> do a PR? Thanks for your >> hard work @magnetophon <https://github.com/magnetophon> ! >> >> — >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub >> <#3 (comment)>, >> or mute the thread >> <https://github.com/notifications/unsubscribe-auth/ACGVFZUkd5Rq5ULGcvlIDtCHq5Y_7Ck3ks5tkY4zgaJpZM4S55YN> >> . >> > > > > -- > > Julius O. Smith III ***@***.***> > Professor of Music and, by courtesy, Electrical Engineering > CCRMA, Stanford University > http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/> > -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

@josmithiii

Thanks for the review!

I like the GPL much more than the free-er licenses, though I understand it's not ideal for your purposes.
I will think about it.

Yes, it's probably best to make rmsMaxSize an argument, will do.

Thanks for the compliment on slidingReduce; it means a lot to me!
Is this an existing algorithm? Do you know it's name?

Your slidingSum is much more elegant.
However, when I do:

process(x) =
  (x:abs:slidingSum(n))-(x:abs:ba.slidingSumN(n,maxn)):hbargraph("dif", -5, 5);
slidingSum(n) = _ <: fi.integrator, fi.integrator@int(max(0,n)) :> -;
maxn = pow(2,21);

the hbargraph moves, especially when I move the slider. Any idea why this is?

I'll remove the N from the names.

from faustlibraries.

josmithiii commented on June 19, 2024

Hi Bart, I am not aware of a special name for organizing a string of computations into a tree structure to maximize reuse, although there are special examples such as "Fast Fourier Transform" (FFT). It also comes up often in parallel computing since you can start the base of the tree fully in parallel. For example, a length N dot product can happen in log2(N) steps (adds). By "guard" I meant the "max(0)" step, which guards against negative delays. Such a guard is useful when hooking up oscillating networks and such to the length parameter, but unnecessary in normal use. Ideally the Faust compiler will remove the compare to 0 when it can prove that the signal is nonnegative. I've sometimes added 'p' to the name of a function when it is "protected" in this sort of way (e.g., tf2np = transfer-function of order 2, normalized ladder, and protected to be stable no matter what coefficients you give it). I see a small jitter on hbargraph as well (Qt, Mac). I think it means that the algorithms are not equivalent for a random (mic) input, so I guess there is further debugging to do. - Julius

…

On Tue, Apr 3, 2018 at 3:32 AM, Bart Brouns ***@***.***> wrote: @josmithiii <https://github.com/josmithiii> Thanks for the review! I like the GPL much more than the free-er licenses, though I understand it's not ideal for your purposes. I will think about it. Yes, it's probably best to make rmsMaxSize an argument, will do. Thanks for the compliment on slidingReduce; it means a lot to me! Is this an existing algorithm? Do you know it's name? Your slidingSum is much more elegant. However, when I do: process(x) = (x:abs:slidingSum(n))-(x:abs:ba.slidingSumN(n,maxn)):hbargraph("dif", -5, 5); slidingSum(n) = _ <: fi.integrator, ***@***.***(max(0,n)) :> -; maxn = pow(2,21); the hbargraph moves, especially when I move the slider. Any idea why this is? What do you mean by: guard optional, but I would keep it I'll remove the N from the names. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFdJMEzeWDYGQ-NwZpmAiwguS0Ch1ks5tk0-lgaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

A minute after I asked about the guard, I realized what you meant and removed the question, but since you interact with github trough mail, it was to late...

Where would one start debugging?
I tried comparing both versions to:

bruteForceSum(n,x) = x:seq(i, maxn, _+(x@(i+1)*((i+1)<n)));

using

maxn = pow(2,10);

but neither give the same result.
I'm a bit lost as to what to do next.

Also, I thought fi.integrator would run out of bits at some point, but some testing and some googling made clear that that is unlikely to happen, even with single precision floating point.
Is that a correct train of thought?

from faustlibraries.

josmithiii commented on June 19, 2024

Ok, it sounds like I should always click on the pull-request link to get latest info. My tests also come out clean, e.g.: // trunningsum.dsp // Usage: faust2plot trunningsum.dsp; trunningsum import("stdfaust.lib"); bart = library("basics-bart.lib"); n = 12; signal = 1; bruteForceSum(n,x) = x:seq(i, maxn, _+(x@(i+1)*((i+1)<n))); process = signal <: bruteForceSum(n), slidingSum(n), bart.slidingSumN(n,maxn); // :> - : hbargraph("dif", -2, 2); slidingSum(n) = _ <: fi.integrator, fi.integrator@int(max(0,n)) :> -; maxn = pow(2,10); It is true that fi.integrator will eventually run into numerical trouble when there is a persistent dc component. One easy guard against that is to replace fi.integrator by fi.pole(p) where p=1-1/maxn, e.g., gives a "leaky integrator" that is guaranteed to reach a finite steady-state gain for dc. The completely clean thing to use here is Truncated Infinite Impulse Response (TIIR) filters. However, this issue exists in many places throughout the libraries, so I haven't worried about it too much. When someone actually runs into trouble, I suppose we can start a new line of library functions that are numerically stable "forever". This has not yet come up for me, or in any issue reports I've seen. - Julius

…

On Tue, Apr 3, 2018 at 1:10 PM, Bart Brouns ***@***.***> wrote: A minute after I asked about the guard, I realized what you meant and removed the question, but since you interact with github trough mail, it was to late... Where would one start debugging? I tried comparing both versions to: bruteForceSum(n,x) = x:seq(i, maxn, _+(x@(i+1)*((i+1)<n))); using maxn = pow(2,10); but neither give the same result. Your algorithm only very occasionally differs from the brute force one though. I'm a bit lost as to what to do next. Also, I thought fi.integrator would run out of bits at some point, but some testing and some googling made clear that that is unlikely to happen, even with single precision floating point. Is that a correct train of thought? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFR-t0EGxUElrgqQrMXdiMUbanJF3ks5tk9cxgaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

My tests don't come out clean: I can't get the 3 versions to agree, when the input is random.

from faustlibraries.

josmithiii commented on June 19, 2024

In case it is not clear, I would simply use fi.integrator and do only signal-processing-level testing. I would test and debug slidingReduce only when I had a winning use-case for it. I think the corner-case we have here must be in there somewhere, and if the new application doesn't care about it, I would let it be. That's the FOSS way! :-)

…

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

josmithiii commented on June 19, 2024

My tests *don't* come out clean: I can't get the 3 versions to agree,

when the input is random. Our emails crossed in the ether, but my previous email still holds for me. Do any two of the three agree with each other?

…

On Wed, Apr 4, 2018 at 5:17 PM, Bart Brouns ***@***.***> wrote: My tests *don't* come out clean: I can't get the 3 versions to agree, when the input is random. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFb_4_zOS-Ju9jjIMkwPdUIGTcQ0lks5tlWKrgaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

I would test and debug slidingReduce only when I had a winning use-case for it.

My use case for slidingReduce is slidingMin, in LazyLimiter

Do any two of the three agree with each other?

No, I can't get any 2 to agree.

from faustlibraries.

josmithiii commented on June 19, 2024

That is very interesting --- an irresistible debugging challenge I would say :-) My "signal processing answer" for slidingMin (also O(1) complexity) would be runningMin = min ~ _ ; slidingMin(n) = min ~ *(1.0-(1.0/max(1.0,n))); // sets exponentially fading-memory exponential time-constant near n samples I suppose this should be a special case of exponentiallyFadingReduce(op, ...) with op = 'min'. For op = 'max', we get the classic amplitude envelope follower an.amp_follower(n/ma.SR) for nonnegative signals. - Julius

…

On Wed, Apr 4, 2018 at 5:33 PM, Bart Brouns ***@***.***> wrote: I would test and debug slidingReduce only when I had a winning use-case for it. My use case for slidingReduce is slidingMin, in LazyLimiter <https://github.com/magnetophon/LazyLimiter/blob/master/LazyLimiter.lib#L110> Do any two of the three agree with each other? No, I can't get any 2 to agree. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFbbHRXsT9ay2E7Uz03ooEkxd-mGiks5tlWZagaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

That's also an interesting construct, but not suitable for my use-case.

The neat thing about LazyLimiter is that it has 0% distortion even when limiting low frequency sine-waves, yet when limiting a transient, it has a quick release time.
It does this by looking ahead 186ms; if the current gain-reduction is needed again within the window, it doesn't release (hence the 0% distortion), otherwise it does.
So for LazyLimiter, I really need the actual minimum of the last n samples, no exponential window trickery.

Do you have any ideas for debugging slidingReduce?

from faustlibraries.

josmithiii commented on June 19, 2024

Do you have any ideas for debugging slidingReduce?

I would just do the usual thing of finding the minimum failing case on a repeatable input signal (such as no.noise) and drill down on the C++, maybe in gdb. - Julius

…

On Thu, Apr 5, 2018 at 3:16 PM, Bart Brouns ***@***.***> wrote: That's also an interesting construct, but not suitable for my use-case. The neat thing about LazyLimiter is that it has 0% distortion even when limiting low frequency sine-waves, yet when limiting a transient, it has a quick release time. It does this by looking ahead 186ms; if the current gain-reduction is needed again within the window, it doesn't release (hence the 0% distortion), otherwise it does. So for LazyLimiter, I really need the actual minimum of the last n samples, no exponential window trickery. Do you have any ideas for debugging slidingReduce? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACGVFbgqQnCskhWssLOGq4madvuFzGtxks5tlpeygaJpZM4S55YN> .

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

josmithiii commented on June 19, 2024

Here is my minimum failing case at the moment. Very interesting: // trunningsum.dsp // Usage: // faust2plot trunningsum.dsp; trunningsum import("stdfaust.lib"); bart = library("basics-bart.dsp"); //signal = 1; // ok //signal = ba.time; // ok signal = no.noise; maxn = pow(2,5); n = 3; bruteForceSum(n,x) = x:seq(i, n-1, +(x@(i+1))); slidingSum(n) = _ <: fi.integrator, fi.integrator@int(max(0,n)) : -; process = signal <: _,bruteForceSum(n), slidingSum(n), bart.slidingSumN(n,maxn); // :> - : hbargraph("dif", -2, 2);

…

-- Here is my output: faustout = [ ... 5.74859e-06 5.74859e-06 5.74859e-06 5.74859e-06; ... -0.344846 -0.34484 -0.34484 -0.34484; ... -0.695186 0.959974 -1.04003 0.959974; ... -0.325039 0.634929 -1.36507 0.634929; ... 0.106768 -0.913457 -0.913457 -0.913457; ... -0.483426 -0.701696 -0.701697 -0.701696; ... 0.489666 0.113009 0.113009 0.113009; ... -0.397528 -0.391287 -0.391287 -0.391287; ... -0.630045 -0.537907 -0.537907 -0.537907; ... 0.256667 -0.770906 -0.770906 -0.770906; ... -0.625818 -0.999196 -0.999196 -0.999196; ... 0.825585 0.456434 0.456434 0.456434; ... -0.82728 -0.627513 -0.627513 -0.627513; ... 0.297812 0.296117 0.296117 0.296117; ... 0.643531 0.114062 0.114062 0.114062; ... 0.789655 -0.269003 1.731 -0.269003; ... ]; Note that 0.297812 + 0.643531 + 0.789655 = 1.731 and 0.297812 + 0.643531 -0.82728 = 0.11406. Curious! Unfortunately, I had only a few minutes to go after this. I might be overlooking something really simple. - Julius On Sun, Apr 8, 2018 at 11:45 PM, Julius Smith <[email protected]> wrote:

> Do you have any ideas for debugging slidingReduce? I would just do the usual thing of finding the minimum failing case on a repeatable input signal (such as no.noise) and drill down on the C++, maybe in gdb. - Julius On Thu, Apr 5, 2018 at 3:16 PM, Bart Brouns ***@***.***> wrote: > That's also an interesting construct, but not suitable for my use-case. > > The neat thing about LazyLimiter is that it has 0% distortion even when > limiting low frequency sine-waves, yet when limiting a transient, it has a > quick release time. > It does this by looking ahead 186ms; if the current gain-reduction is > needed again within the window, it doesn't release (hence the 0% > distortion), otherwise it does. > So for LazyLimiter, I really need the actual minimum of the last n > samples, no exponential window trickery. > > Do you have any ideas for debugging slidingReduce? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#3 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACGVFbgqQnCskhWssLOGq4madvuFzGtxks5tlpeygaJpZM4S55YN> > . > -- Julius O. Smith III ***@***.***> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

-- Julius O. Smith III <[email protected]> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ <http://ccrma.stanford.edu/>

from faustlibraries.

magnetophon commented on June 19, 2024

@josmithiii
Thanks for the debugging effort.
I wanted to get back to you with a useful result, but have not been able to do so so far.
Just as a heads up, I won't have time for this for a while, sorry.

from faustlibraries.

magnetophon commented on June 19, 2024

After a long hiatus from my side, the summing issue has been resolved upstream.

Now the three summing methods are mostly in agreement.
When I run the following with faust 2.20.2

import("stdfaust.lib");
bart = library("slidingReduce.lib");

signal = no.noise;
maxn = pow(2,13);
n = 3 ;
bruteForceSum(n,x) = x:seq(i, n-1, +(x@(i+1)));
slidingSum(n) = _ <: fi.integrator, fi.integrator@int(max(0,n)) : -;
process = sigcomp;
sigcomp =
  ( (signal:bruteForceSum(n) ) - ( signal:slidingSum(n) ) )
, ( (signal:bruteForceSum(n) ) - ( signal:bart.slidingSumN(n,maxn) ) )
, ( (signal:slidingSum(n)    ) - ( signal:bart.slidingSumN(n,maxn) ) )
;
sigs =
  signal <:
  (
    _
   ,bruteForceSum(n)
   , slidingSum(n)
   ,bart.slidingSumN(n,maxn)
  );

I get:

faustout = [ ...
 0 0 0; ...
 0 0 0; ...
 -1.1920929e-07 -1.1920929e-07 0; ...
 -9.26665962e-08 0 1.1920929e-07; ...
 -2.98023224e-08 0 0; ...
 1.1920929e-07 0 -1.1920929e-07; ...
 0 -7.4505806e-09 -5.96046448e-08; ...
 0 0 -5.96046448e-08; ...
 -1.1920929e-07 -5.96046448e-08 5.96046448e-08; ...
 -1.1920929e-07 1.1920929e-07 2.38418579e-07; ...
 -1.1920929e-07 0 1.1920929e-07; ...
 0 0 8.94069672e-08; ...
 0 0 -5.96046448e-08; ...
 2.38418579e-07 0 -1.78813934e-07; ...
 2.38418579e-07 0 -2.38418579e-07; ...
 2.38418579e-07 1.1920929e-07 -1.1920929e-07; ...
];

Interestingly, the error is almost always 1.1920929e-07 or double that or negative one of those.
That also holds true for huge n's.

I guess those who actually understand floating point math are not surprised.
I sure was!

When I compile with faust 2.5.23 I get;

faustout = [ ...
 0 0 0; ...
 0 0 0; ...
 2 0 -2; ...
 2 0 -2; ...
 -2.98023e-08 0 0; ...
 1.19209e-07 0 -5.96046e-08; ...
 1.19209e-07 0 -5.96046e-08; ...
 0 0 -5.96046e-08; ...
 0 0 5.96046e-08; ...
 -1.19209e-07 0 1.19209e-07; ...
 -2.38419e-07 0 1.78814e-07; ...
 -2.38419e-07 0 1.19209e-07; ...
 0 0 -5.96046e-08; ...
 2.38419e-07 0 -1.49012e-07; ...
 2.38419e-07 0 -2.38419e-07; ...
 -2 0 2; ...
];

If anyone has an idea about the cause, I'd be very interested.
May I suggest adding a test so this error doesn't return?

from faustlibraries.

trouble adding compressors about faustlibraries HOT 25 CLOSED

Comments (25)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent