[PD] Inlet - Unexpected Behaviour

Christof Ressi info at christofressi.com
Sat Aug 29 23:50:36 CEST 2020

I already made a PR which addresses the issues pointed out by Jonathan: 

On 29.08.2020 21:04, Alexandre Torres Porres wrote:
> Em qui., 6 de ago. de 2020 às 16:08, Jonathan Wilkes 
> <jancsika at yahoo.com <mailto:jancsika at yahoo.com>> escreveu:
>     > On Thursday, August 6, 2020, 2:07:09 PM EDT, matthew brandi
>     <mfbrandi at outlook.com> wrote:
>     > Dear people
>     > In my role as village idiot, I am asking whether the string
>     "fwd" in a message has a
>     special meaning to inlet.
>     > Naively, I was expecting inlet to pass the string to the
>     subpatch, but it seems not
>     to. See example patch attached.
>     AFAICT that's a regression due to the way Pd Vanilla implemented
>     message forwarding for
>     [inlet~ fwd]. That's a feature that allows a signal inlet of a
>     subpatch/abstraction to forward
>     non-signal messages to the right outlet of [inlet~ fwd]. (The
>     right outlet sprouts when the
>     "fwd" argument is present.)
>     Another regression-- there is no longer an error if you try to
>     send a non-signal message to
>     [inlet~].
>     Another regression-- [inlet~ fwd] unconditionally allocates space
>     on the stack to copy the
>     entire incoming message. If you generate a long enough message
>     this will blow the stack
>     and cause Pd to crash. Esp. important given that Windows stack is
>     much smaller than the RAM
>     available for heap allocation on most machines.
>     Also-- I *think* Pd Vanilla doesn't forward pointer messages
>     through [inlet~ fwd]. It appeared to be an oversight-- at least I
>     didn't see any comment about it.
>     A GSoC student spent some time reimplementing this in Purr Data,
>     so none of thiese should be
>     issues there.
> I think it's a good idea if you're changing and fixing stuff to also 
> send a PR to vanilla as a proposal. Would you consider doing that as 
> well?
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200829/6db3c928/attachment.html>

More information about the Pd-list mailing list