[PD] Review of expr 0.55 (released in 0.48) and a Pull Request
sdy at ucsd.edu
Mon Sep 18 18:34:59 CEST 2017
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
> 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
> 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
Thank you very much for your update of the documentation patch.
On Sat, Sep 16, 2017 at 7:36 AM, Alexandre Torres Porres <porres at gmail.com>
> 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-
Professor, Music Department
University of California, San Diego
Director, Sonic Arts R&D and IDEAS
Email: sdy at ucsd.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list