[PD] fexpr~ block limitations - bug

[Shahrokh Yadegari]

Hi Alexandre, (and all)

Attached is a pre Version 0.5 expr~.d_fat compiled on OSX 10.9.5 with some
fixes.  I have fixed a number of the bugs, which are listed on the attached
modified pd patch Alexandre sent me. I am still working on the others, but
I thought I send this intermediate version to you to test if you had the
time, before I pass the sources to Miller.

I am not sure if I have picked the best way to fix the functions that were
supposed to receive one argument, but were listed as needing two, or vice
versa.  My impetus was to fix and drop the erroneous version which would
break any patch that has used them in the wrong format. I think it is
better to break the patches and inform the author of the new change. Most
likely, the original use did not behave as it should have any way, and it
is better to fix the patch.

I would be happy to hear from any experiences.

best,
Shahrokh


On Wed, Sep 9, 2015 at 11:27 PM, Shahrokh Yadegari <sdy at ucsd.edu> wrote:

> 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 at 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 at 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 at 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 at 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
>>>>>
>>>>
>>>>
>>>
>>>
>>>
-- 
Shahrokh Yadegari
Professor of Composition and Sound Design,
Theatre and Dance Department
University of California, San Diego
Director, Initiative for Digital Exploration of Arts and Science, (IDEAS)
California Institute for Telecommunications and Information Technologies
(Calit2)
Email: sdy at ucsd.edu
Web: http://yadegari.org
Tel: (858) 822-4113
Fax: (858) 534-1080
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151106/11408609/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expr-Mega_Bug_Report-SDY-Response.pd
Type: application/octet-stream
Size: 22470 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151106/11408609/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expr~.d_fat
Type: application/octet-stream
Size: 240084 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151106/11408609/attachment-0003.obj>