- Original Message -
From: Roman Haefeli reduz...@gmail.com
To:
Cc: pd-list@iem.at pd-list@iem.at
Sent: Thursday, June 7, 2012 4:48 AM
Subject: [PD] settable receive again (was: ipoke~ ?)
On Wed, 2012-06-06 at 08:56 -0700, Jonathan Wilkes wrote:
- Original Message -
From: Roman Haefeli reduz...@gmail.com
To: pd-list@iem.at
Cc:
Sent: Wednesday, June 6, 2012 4:26 AM
Subject: Re: [PD] ipoke~ ?
On Wed, 2012-06-06 at 09:53 +0200, Jeppi Jeppi wrote:
Hey,
I wonder whether there is something similar to Max' ipoke~
(an
interpolating buffer~ writer) for Pd. I should need it for some
physical modelling and resampling stuff. Otherwise, I could
implement
it myself. It seems only interpolated reading is available
(tabread4~
and similar ones), not writing.
This somehow reminds of the thread about settable [receive].
Whether or not the user who started the settable [receive] thread really
needed a settable receive, there are situations where it's needed, like
wrapping s/r in abstractions so that I don't have to prepend a $0-
which,
in 95% of cases is what I want, and using a 2nd arg for setting scope for
the other 5% of situations.
Forgive my ignorance, but I don't understand. Can you elaborate this?
I've posted about it before. Just imagine [s] inside abstraction [foo] and
[r] inside abstraction [bar]. I want to type [foo blah] and have my
abstraction
set the inner [s] symbol to [parent-$0]-blah. Easy enough. Similarly, I want
[bar blah] to set its inner [r] symbol to [parent-$0]-blah. Roadblock.
The scope stuff is more involved than that, but that's enough of an example to
demonstrate a use case for a dynamically settable [receive].
There, not having a
settable receive leads to hacky solutions like dynamic-patching or
feeding a message-box with a semicolon, the receive-symbol, and
the message (which also requires a hack to get list foo to
remain
list foo when it comes out). Both of those solutions are
obscure and
way more error-prone than simply sending a symbol to an inlet.
Sure, I wasn't advocating to substitute a settable receive by some
dynamic patching hack. I just happened not to be able to think of a case
that absolutely needs a settable receive (and am sorry for not yet
understanding the one you provided above).
And the historical replies to a user wanting a settable receive of
why do
you want to do that are misleading, because the real question was
why do you want to do that when there's a long-standing bug--
even in
all the iemguis-- that may cause a crash by doing that?
There never was a bug in [r ], afaik.
There's a bug in [iem_r] and all the other alternatives to [r] that tried to
add that functionality, plus the iemguis which are internal objects.
I didn't know about the fact, that
adding an inlet to [r] would imply implementing a bug before it was
mentioned in this thread and I always thought, that for conceptual
reasons it was never implemented. And for some reason I haven't missed
it in all those years of Pd patching.
What are the conceptual reasons?
-Jonathan
Anyway, Ivica apparently has fixed the issue.
That's good.
Roman
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
