Thanks Alexandre. I will be in touch soon with new objects.

best,

Shahrokh

On Tue, Sep 8, 2015 at 9:48 PM, Alexandre Torres Porres <porres@gmail.com> wrote:

sure, count me in for testing it, my pleasure ;)

I'm on a mac os - yosemite and mavericks

cheers

2015-09-08 21:22 GMT-03:00 Shahrokh Yadegari <sdy@ucsd.edu>:

Hi Alexandre,

I recall that I fixed this bug a while back so I am surprised that I see it again.

In any case your email is timely as I just started looking at the bugs and hope to be submitting new sources soon.

Would you care to be my alpha tester? If so, what environment are you on? (mac, linux, sorry I cannot deal with windows)

cheers,

Shahrokh

On Tue, Sep 8, 2015 at 1:12 PM, Alexandre Torres Porres <porres@gmail.com> wrote:

So, as it seems, I just found that there's an issue with the way [fexpr~] abbreviates the formulas and the way it behaves.

If you use it like this [fexpr~ ($x + $x[-1] + $x[-2] + $x[-3]) * 0.25] by supressing the outlet number, it won't check back on previous block sample values.

but if you do this [fexpr~ ($x1 + $x1[-1] + $x1[-2] + $x1[-3]) * 0.25] it will!

check attached patch

Anyway, still seems like a bug to me one way or another that needs to be fixed. And, as long as we're on the subject, how's the work on the previous bug reports?

Thanks

2015-09-08 1:47 GMT-03:00 Alexandre Torres Porres <porres@gmail.com>:

Hi Shahrokh and Pd list

I've been testing fexpr~ and it seems it won't get the previous samples from the previous block.

For example, a simple mean filter like this:

[fexpr~ ($x + $x[-1]) * 0.5]

will not work for the first sample of the block, because it won't get the last sample from the previous block.

So, I know that in practice it doesn't compromise much, it's just one sample, but in an 16 point average filter this becomes more of a concern. One way or another, even for just one sample, I consider this problematic and a bug, as it should always be able to address previous samples. 

Am I right?

thanks