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. See Miller's response below:
If the object has a method for "signal" then its first inlet (i.e., itself) is then passed a signal to process. 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. Also, it's funny to send it a message like "float" and not have that trigger a computation. So I
think
it's probably just as well to leave it as is.
However, I will look into why fexpr~ does not convert float to signal.
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.
Thank you very much for your update of the documentation patch.
cheers, Shahrokh
On Sat, Sep 16, 2017 at 7:36 AM, Alexandre Torres Porres porres@gmail.com 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