Hi Shahrokh, with the new release of pd 0.48-1 around the corner, I was wondering if we could have a look into that minor issue with [fexpr~], in which it doesn't convert float to signals in the main left inlet.
> However, I will look into why fexpr~ does not convert float to signal. > I've actually already made a Pull Request for that a while ago, see: https://github.com/pure-data/pure-data/pull/219 All I did was add *CLASS_MAINSIGNALIN(fexpr_tilde_class, t_expr, exp_f) *to fexpr~'s setup and it all works fine now. This is now the same as in expr~ setup, so it is consistent between each other and also how we expect a signaal object to behave. I would also go ahead and remove *class_addmethod(fexpr_tilde_class, nullfn, gensym("signal"), 0**) *cause I think it's unnecessary, (expr~ has it too). But I'll leave that to you and Miller. And, also, I guess this would call for an update to the version... to something like "0.56". About the documentation, I can also send a fix for the help file saying fexpr~ now promotes floats to signal, if this is accepted. I'm actually already working on a new help file because the new upcoming version of Pd has a different font size, so I'm just realigning things. cheers 2017-09-18 13:50 GMT-03:00 Alexandre Torres Porres <[email protected]>: > 2017-09-18 13:34 GMT-03:00 Shahrokh Yadegari <[email protected]>: > >> Dear Alexandre and all, >> >> Miller and I both agree that it is better not to change the behavior of >> expr~ and fexpr~ in respect to requiring the first inlet to be a signal. >> > > Let us just be clear. You mean the request to allow the first inlet to be > a float or symbol variable (such as $f1 or $s1) rather than a signal ($v1 > for expr~ and $x1[0] for fexpr~) - right? > > I think this means it would be a bit confusing not to use the first inlet >> as a signal... Pd would allow signal connections to it that you'd then >> ignore in favor of the float or symbol value it gets sent. >> > > Hmm, I see that now! Unlike secondary inlets, which would not allow a > signal connection, the left/main inlet would still allow it. So this is a > good reasoning... in fact it'd be better if it would not allow a signal > inlet, and that would require too much surgery. > > Anyway, I only brought it up cause it said so in the source code this > could be considered in the future. So yeah, just leave it as it is and > remove that remark from the source code. > > >> However, I will look into why fexpr~ does not convert float to signal. >> > > It's coz it doesn't have CLASS_MAINSIGNALIN in the setup method. But > expr~ has it, so it converts floats to signals. > > So I just added CLASS_MAINSIGNALIN(fexpr_tilde_class, t_expr, exp_f) to > fexpr~'s setup and it worked fine. > > Though now I think the class_addmethod(fexpr_tilde_class, nullfn, gensym(" > signal"), 0) is unnecessary, as well as it is not necessary for expr~. > Well, you and Miller should know better, I must be the most ignorant object > developer for Pd :) > > >> After receiving a few other requests for avg() and Avg() to come back, I >> will also soon include these functions and possibly others to the list of >> functions. >> > > Awesome :) > > >> Thank you very much for your update of the documentation patch. >> > > my pleasure > > Cheers > > On Sat, Sep 16, 2017 at 7:36 AM, Alexandre Torres Porres <[email protected] >> > wrote: >> >>> Hi Shahrokh and Miller. I've sent this before, but now I'm sending again >>> with a more explicit subject and also a Pull Request. >>> >>> I've tested the new expr (v0.55 released in pd 0.48) and I still have >>> some remaining bugs to report. These are bugs I really think should be >>> fixed, and some suggested feature requests. >>> >>> One of the bugs is plain simple, the fact that fexpr~ doesn't allow a >>> float input in its left inlet. That doesn't seem intentional, by the way, >>> because [expr~] allows it. Anyway, here's a simple Pull Request I created >>> about it, see if it's cool: https://github.com/pure- >>> data/pure-data/pull/219 >>> >>> cheers >>> >>> >>> >>> >> >> >> -- >> Shahrokh Yadegari >> Professor, Music Department >> University of California, San Diego >> Director, Sonic Arts R&D and IDEAS >> Qualcomm Institute >> Email: [email protected] >> Web: http://yadegari.org >> > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
