----- 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