Re: [Faudiostream-users] Implementing high order FIRs

> Le 28 mars 2018 à 13:33, Oleg Nesterov a écrit : > > and I think there are more problems with overflows/conversions. Say, > > process = @(100.0); > > doesn't crash faust but the error message doesn't look right: > > ERROR : possible negative values

Re: [Faudiostream-users] Implementing high order FIRs

On 03/28, Stéphane Letz wrote: > > > Speaking of internal usage of min/max... checkDelayInterval() blindly > > converts double to int, this looks dangerous and wrong. Honestly I do > > not even know what int(HUGE_VAL+0.5) should return, but apparently the > > result is negative because this code >

Re: [Faudiostream-users] Implementing high order FIRs

> Le 27 mars 2018 à 18:13, Oleg Nesterov a écrit : > > On 03/26, Stéphane Letz wrote: >> >> If not then I guess this could/should be checked before the FIR generation >> step and the use of DeclareFunInst. > > So you have changed DeclareFunInst::DeclareFunInst() to report the

Re: [Faudiostream-users] Implementing high order FIRs

On 03/27, Oleg Nesterov wrote: > > Finally. > > process = ffunction(float ANYTHINGBEFOREminANYTHINGAFTER(), "",""); > > compiles to > > output0[i] = FAUSTFLOAT(float(min())); > > doesn't look exactly right ;) forgot to mention... this is probably because of 'if (startWith(inst->fName,

Re: [Faudiostream-users] Implementing high order FIRs

More precise type checking in DeclareFunInst for LLVM and C++ backends (even if too restrictive for LLVM backend, but at least it avoids crashes or assert..) https://github.com/grame-cncm/faust/commit/7adc199d0c399cb72448a9160f90fe6882de78c9 Stéphane > Le 26 mars 2018 à 22:41, Yann Orlarey

Re: [Faudiostream-users] Implementing high order FIRs

We can overload functions provided that the argument's signatures are different. Otherwise, the generated C++ code won't compile: error: functions that differ only in their return type cannot be overloaded But obviously, we should report an error ("foreign functions that differ only in their

Re: [Faudiostream-users] Implementing high order FIRs

> Le 26 mars 2018 à 14:48, Oleg Nesterov a écrit : > > On 03/24, Yann Orlarey wrote: >> >> Hi, >> >> The problem has been fixed in version 2.5.26. The compiler now reports >> an error instead of an exception. > > and the fix is much better than I tried to suggest, thanks. >

Re: [Faudiostream-users] Implementing high order FIRs

On 03/24, Yann Orlarey wrote: > > Hi, > > The problem has been fixed in version 2.5.26. The compiler now reports > an error instead of an exception. and the fix is much better than I tried to suggest, thanks. OK, let me report another minor/trivial problem. Again, I'm not sure I understand this

Re: [Faudiostream-users] Implementing high order FIRs

Hi, The problem has been fixed in version 2.5.26. The compiler now reports an error instead of an exception. Yann - Yann Orlarey Directeur scientifique www.grame.fr 2018-03-21 8:16 GMT-07:00 Yann Orlarey : > Hi Oleg, > > Thanks for pointing these

Re: [Faudiostream-users] Implementing high order FIRs

On 03/22, CrocoDuck o'Ducks wrote: > > Sorry, I have been sidetracked a bit. See below 2 minimal examples. > firLongTime.dsp takes around 5 minutes to compile, while firShortTime.dsp > takes only a bunch of seconds. I see the difference too. With the "patch" below both versions take the same time

Re: [Faudiostream-users] Implementing high order FIRs

Hi there! Sorry, I have been sidetracked a bit. See below 2 minimal examples. firLongTime.dsp takes around 5 minutes to compile, while firShortTime.dsp takes only a bunch of seconds. The FIR taps are all the same, only the precision is different. 64 bit on LongTime, 32 on ShortTime. The

Re: [Faudiostream-users] Implementing high order FIRs

On 03/21, Oleg Nesterov wrote: > > I don't really understand this code, but it seems that the isNumericalTuple() > simplification in realeval() is not right. At least the "patch" below seems > to fix a problem. Yes, I think this is true... So unless you are going to change the "propogate" paths,

Re: [Faudiostream-users] Implementing high order FIRs

On 03/21, Yann Orlarey wrote: > > Interestingly: > > process = 0,0,0 : +; > > crashes, while: > > process = _,0,0 : +; > > correctly reports a sequential composition error. I don't really understand this code, but it seems that the isNumericalTuple() simplification in realeval() is not right. At

Re: [Faudiostream-users] Implementing high order FIRs

Hi Oleg, Thanks for pointing these problems. Obviously, the compiler should report errors, not crash! Interestingly: process = 0,0,0 : +; crashes, while: process = _,0,0 : +; correctly reports a sequential composition error. We will have look... Cheers Yann -

Re: [Faudiostream-users] Implementing high order FIRs

On 03/21, Oleg Nesterov wrote: > > Ah, no, sorry, this is faustassert(lsig.size()==2) in realPropagate(), > >339 else if (isBoxPrim2(box, )) { >340 // printf("prim2 recoit : "); print(lsig); printf("\n"); >341 faustassert(lsig.size()==2); and thus it

Re: [Faudiostream-users] Implementing high order FIRs

On 03/21, Oleg Nesterov wrote: > > On 03/21, Oleg Nesterov wrote: > > > > And it is a bit funny that (without the patch) this code > > > > process = ba.take((1,1), (1,1)); > > > > crashes faust: > > > > ... > > faust[0x49f73a] > > faust[0x49ff36] > >

Re: [Faudiostream-users] Implementing high order FIRs

Speaking of ba.take(), can't we add take ((ns, nns), xs) = take(ns,xs), take(nns, xs); into libraries/basics.lib? see the patch below. This way you can do, say, take((1,3), (1,2,3)); or reverse(list) = take((par(i, ba.count(list), ba.count(list)-i)), list); And it is

Re: [Faudiostream-users] Implementing high order FIRs

Right. Internally the faust compiler uses doubles anyway and these doubles are parsed using a very standard atof function. It would be useful if you could send me a sample code because it's really weird. Yann - Yann Orlarey Directeur scientifique www.grame.fr

Re: [Faudiostream-users] Implementing high order FIRs

I would not expect that big of a difference in the amount of time to process 64-bit versus 32-bit input data. Something else may be afoot here. - Julius On Tue, Mar 20, 2018 at 3:42 PM, CrocoDuck o'Ducks wrote: > Hi guys, > > I think I probably found what was wrong.

Re: [Faudiostream-users] Implementing high order FIRs

Hi guys, I think I probably found what was wrong. So, I used the -t 0 option and it worked, but it took a really huge time to compile (almost a hour I think). I did some tests and I don't see any problem with fi.fir(), it supports very large lists. The fact that your times are as so much

Re: [Faudiostream-users] Implementing high order FIRs

> I think [complexity] info should be added in the library documentation. +1 - Julius On Tue, Mar 20, 2018 at 5:26 AM, Stéphane Letz wrote: > ba.take ==> complexity O(n^2) > > I think that this kind of info should be added in the library documentation. > > And also as a general

Re: [Faudiostream-users] Implementing high order FIRs

ba.take ==> complexity O(n^2) I think that this kind of info should be added in the library documentation. And also as a general rule in the « Contributing » section of https://github.com/grame-cncm/faustlibraries/blob/master/README.md, to push library writers to document this kind of things.

Re: [Faudiostream-users] Implementing high order FIRs

HI, I did some tests and I don't see any problem with fi.fir(), it supports very large lists. Here is the test file I used: // --- fir500.dsp -- import("stdfaust.lib"); process = fi.fir(( 1,2,3,4,5,6,7,8,9,10, ...48 copies... 1,2,3,4,5,6,7,8,9,10));

Re: [Faudiostream-users] Implementing high order FIRs

depending on what faust version you are using, a foreign function might help. I had to do this to do a convolution in my tambura synthesiser for exactly the same reason https://github.com/olilarkin/Tambura/blob/master/bridgeIR.dsp

Re: [Faudiostream-users] Implementing high order FIRs

> Le 18 mars 2018 à 23:06, CrocoDuck o'Ducks a > écrit : > > Hi there! > > I currently have some Julia code producing 512 taps for an FIR filter. Interesting ! Do you have some code to show? Is is part of an official JULIA ==> Faust project? Stéphane

Re: [Faudiostream-users] Implementing high order FIRs

CrocoDuck o'Ducks writes: Sometimes it seems to compile and work seemingly fine but often this happens instead when I issue faust2jackconsole: /usr/bin/faust2jackconsole: line 73: 3687 Alarm clock faust -i -a "$FAUSTLIB/jack-console.cpp" $OPTIONS "$f" -o "$f.cpp"

Re: [Faudiostream-users] Implementing high order FIRs

Greetings, The fir function is written as follows using pattern matching: fir((b0,bv)) = _ <: *(b0), R(1,bv) :> _ with { R(n,(bn,bv)) = (@(n):*(bn)), R(n+1,bv); R(n, bn) = (@(n):*(bn)); }; fir(b0) = *(b0); While very elegant, it requires a compiler evaluation for each

[Faudiostream-users] Implementing high order FIRs

Hi there! I currently have some Julia code producing 512 taps for an FIR filter. The Julia code also takes care of generating Faust code which uses ir.fir to implement the FIR. I then try to build the Faust FIR with faust2jackconsole. Sometimes it seems to compile and work seemingly fine