Hi Pd-list,
A couple times now I've thought that it would be very convenient to change the name of a receive after instantiation, but I'm not finding any way of doing that. If this is impossible, I'll clarify that essentially what i want is for an abstraction to be able to point to the $0 patch number on instantiation. Is there a solution like this available within Pd?
Thanks!
Francis
If you don't have any problem with using externals you can use [iemlib/iem_send].
That's what I use. There is also a [iem_receive] in case that you happen to need that.
Ingo
From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Francis Blair Sent: Wednesday, March 25, 2020 4:29 PM To: pd-list@lists.iem.at Subject: [PD] Changing Send/Receive Names After Instantiation
Hi Pd-list,
A couple times now I've thought that it would be very convenient to change the name of a receive after instantiation, but I'm not finding any way of doing that. If this is impossible, I'll clarify that essentially what i want is for an abstraction to be able to point to the $0 patch number on instantiation. Is there a solution like this available within Pd?
Thanks!
Francis
On 3/25/20 5:04 PM, Ingo wrote:
If you don't have any problem with using externals you can use [iemlib/iem_send].
what's that for?
i mean: what is the advantage over [send] (without arguments)?
That's what I use. There is also a [iem_receive] in case that you happen to need that.
changing the receiver is dangerous (as in: could crash your system).
gfmdasr IOhannes
changing the receiver is dangerous (as in: could crash your system).
Yes. Actually, I've experimented with different ways to make it safe, see:
https://github.com/pure-data/pure-data/pull/614
or
https://github.com/pure-data/pure-data/pull/849
I think the second version is not too unreasonable.
Christof
On 25.03.2020 17:27, IOhannes m zmölnig wrote:
On 3/25/20 5:04 PM, Ingo wrote:
If you don't have any problem with using externals you can use [iemlib/iem_send].
what's that for?
i mean: what is the advantage over [send] (without arguments)?
That's what I use. There is also a [iem_receive] in case that you happen to need that.
changing the receiver is dangerous (as in: could crash your system).
gfmdasr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thank you all for your responses! I think I've found a solution that can work. Basically what I did was create an abstraction where the first argument is $0 and has a receive object inside with the name $1-parent. It was right under my nose the whole time, but thank you all for helping me sniff it out!
Best,
Francis
On Wed, Mar 25, 2020 at 12:55 PM Christof Ressi info@christofressi.com wrote:
changing the receiver is dangerous (as in: could crash your system).
Yes. Actually, I've experimented with different ways to make it safe, see:
https://github.com/pure-data/pure-data/pull/614
or
https://github.com/pure-data/pure-data/pull/849
I think the second version is not too unreasonable.
Christof
On 25.03.2020 17:27, IOhannes m zmölnig wrote:
On 3/25/20 5:04 PM, Ingo wrote:
If you don't have any problem with using externals you can use [iemlib/iem_send].
what's that for?
i mean: what is the advantage over [send] (without arguments)?
That's what I use. There is also a [iem_receive] in case that you happen to need that.
changing the receiver is dangerous (as in: could crash your system).
gfmdasr IOhannes
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi everyone,
I just wanted to share my latest (open hardware) Raspbery Pi - Pure Data project with you. It's a Control Hat that gives one 8 analog inputs, 4 push buttons and 2 indicator LEDs in PD. One also gets a quit handy reset/shutdown button for the Raspberry Pi: https://paperpcb.dernulleffekt.de/doku.php?id=raspberry_boards:raspbi-pd_con...
Together with a good sound card, such as that one (with stereo audio in): https://paperpcb.dernulleffekt.de/doku.php?id=raspberry_boards:raspi-sound-h...
... one could easily build an amazing stand alone PD instrument or effect unit.
Have fun!
Wolfgang
I had some cases where I had to send e.g. to different preset banks to dump some data. The bank name was different depending on the selected bank.
There can be a number of reasons to send to different objects depending on other settings. But I agree that you can find different ways of doing it. I havn't used it in quite some time.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of IOhannes m zmölnig Sent: Wednesday, March 25, 2020 5:27 PM To: pd-list@lists.iem.at Subject: Re: [PD] Changing Send/Receive Names After Instantiation
On 3/25/20 5:04 PM, Ingo wrote:
If you don't have any problem with using externals you can use
[iemlib/iem_send].
what's that for?
i mean: what is the advantage over [send] (without arguments)?
That's what I use. There is also a [iem_receive] in case that you happen to need that.
changing the receiver is dangerous (as in: could crash your system).
gfmdasr IOhannes
IOhannes m zmölnig wrote:
changing the receiver is dangerous (as in: could crash your system).
really ? that's (bad) news to me. how so ? why could that crash a system ? and why is it not dangerous to change the receiver in the signal domain ?
would you say, it's "saver" to do dynamic patching if a [receive] has to be flexible ? (i.e. create and destroy vanilla [recieve] objects in a subpatch when they need to have another address)
(atm i use [iem_receive] quite a lot in my patches ...)
thanks for any insight
oliver
Check out the following discussion on GitHub: https://github.com/pure-data/pure-data/pull/604
TL;DR: if you unbind a symbol from a receiver while sending to the symbol, Pd can crash because you modify the bind list while iterating over it.
Personally, I've been using [iem_receive] in some projects and didn't run into problems, but only because I avoid the case described above. Note that the same problem exists with the iemgui objects where you can set the receive symbol dynamically.
and why is it not dangerous to change the receiver in the signal domain ?
In the case of [r~], it is [s~] which is bound to a symbol, that's why you can change the symbol of [r~] but not of [s~]. With [throw~] and [catch~] it's the other way round.
would you say, it's "saver" to do dynamic patching if a [receive] has to be flexible ? (i.e. create and destroy vanilla [recieve] objects in a subpatch when they need to have another address)
Dynamically destroying objects is even more dangerous ;-)
Christof
On 25.03.2020 20:46, oliver wrote:
IOhannes m zmölnig wrote:
changing the receiver is dangerous (as in: could crash your system).
really ? that's (bad) news to me. how so ? why could that crash a system ? and why is it not dangerous to change the receiver in the signal domain ?
would you say, it's "saver" to do dynamic patching if a [receive] has to be flexible ? (i.e. create and destroy vanilla [recieve] objects in a subpatch when they need to have another address)
(atm i use [iem_receive] quite a lot in my patches ...)
thanks for any insight
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Christof Ressi wrote:
Check out the following discussion on GitHub: https://github.com/pure-data/pure-data/pull/604
TL;DR: if you unbind a symbol from a receiver while sending to the symbol, Pd can crash because you modify the bind list while iterating over it.
Personally, I've been using [iem_receive] in some projects and didn't run into problems, but only because I avoid the case described above.
Thanks Christof for the explanation !
@IOhannes: i think this should be noted in the helpfile.
Dynamically destroying objects is even more dangerous ;-)
Bummer ... another thing i do quite often ;-)
Since i am not a programmer: how would i decode that twinkle emoji in your sentence ?
does it mean:
a.) be happy that you survived so far, because you're really on mined territory here ...
b.) i know it's not encouraged, but as long as you don't tell anybody ...
sorry ... getting a little anxious these days ... ;-)
best
oliver
Haha, what I wanted to say is that if you're worried about the danger of using [iem_receive], then dynamically destroying [r] is not a solution because it is just as dangerous because the destructor of [r] will unbind the symbol.
An easy way to avoid this problem on the user side is to always use a clock for the message that is going to unbind the symbol. E.g. the following is always safe:
... -> [del 0] -> [set foo( -> [iem_receive]
The reason is that [del 0] breaks the message passing chain and executes the messages downstream at the beginning of the next scheduler tick. Same thing for dynamically deleting objects.
Don't worry too much. If you've been using [iem_receive] and dynamically deleted objects and didn't experience a crash, it probably means you're using it in more or less safe ways. It's just something to keep in mind for your next patch :-)
Christof
On 25.03.2020 22:16, oliver wrote:
Christof Ressi wrote:
Check out the following discussion on GitHub: https://github.com/pure-data/pure-data/pull/604
TL;DR: if you unbind a symbol from a receiver while sending to the symbol, Pd can crash because you modify the bind list while iterating over it.
Personally, I've been using [iem_receive] in some projects and didn't run into problems, but only because I avoid the case described above.
Thanks Christof for the explanation !
@IOhannes: i think this should be noted in the helpfile.
Dynamically destroying objects is even more dangerous ;-)
Bummer ... another thing i do quite often ;-)
Since i am not a programmer: how would i decode that twinkle emoji in your sentence ?
does it mean:
a.) be happy that you survived so far, because you're really on mined territory here ...
b.) i know it's not encouraged, but as long as you don't tell anybody ...
sorry ... getting a little anxious these days ... ;-)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I guess this is a parallel discussion, right?
https://github.com/pure-data/pure-data/pull/604
we've been discussing how to add an inlet to [receive] so it behaves like [iem_receive]
Em qua., 25 de mar. de 2020 às 18:50, Christof Ressi info@christofressi.com escreveu:
Haha, what I wanted to say is that if you're worried about the danger of using [iem_receive], then dynamically destroying [r] is not a solution because it is just as dangerous because the destructor of [r] will unbind the symbol.
An easy way to avoid this problem on the user side is to always use a clock for the message that is going to unbind the symbol. E.g. the following is always safe:
... -> [del 0] -> [set foo( -> [iem_receive]
The reason is that [del 0] breaks the message passing chain and executes the messages downstream at the beginning of the next scheduler tick. Same thing for dynamically deleting objects.
Don't worry too much. If you've been using [iem_receive] and dynamically deleted objects and didn't experience a crash, it probably means you're using it in more or less safe ways. It's just something to keep in mind for your next patch :-)
Christof
On 25.03.2020 22:16, oliver wrote:
Christof Ressi wrote:
Check out the following discussion on GitHub: https://github.com/pure-data/pure-data/pull/604
TL;DR: if you unbind a symbol from a receiver while sending to the symbol, Pd can crash because you modify the bind list while iterating over it.
Personally, I've been using [iem_receive] in some projects and didn't run into problems, but only because I avoid the case described above.
Thanks Christof for the explanation !
@IOhannes: i think this should be noted in the helpfile.
Dynamically destroying objects is even more dangerous ;-)
Bummer ... another thing i do quite often ;-)
Since i am not a programmer: how would i decode that twinkle emoji in your sentence ?
does it mean:
a.) be happy that you survived so far, because you're really on mined territory here ...
b.) i know it's not encouraged, but as long as you don't tell anybody ...
sorry ... getting a little anxious these days ... ;-)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I've already linked to this GitHub discussion, see below ;-)
On 27.03.2020 17:43, Alexandre Torres Porres wrote:
I guess this is a parallel discussion, right?
https://github.com/pure-data/pure-data/pull/604
we've been discussing how to add an inlet to [receive] so it behaves like [iem_receive]
Em qua., 25 de mar. de 2020 às 18:50, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
Haha, what I wanted to say is that if you're worried about the danger of using [iem_receive], then dynamically destroying [r] is not a solution because it is just as dangerous because the destructor of [r] will unbind the symbol. An easy way to avoid this problem on the user side is to always use a clock for the message that is going to unbind the symbol. E.g. the following is always safe: ... -> [del 0] -> [set foo( -> [iem_receive] The reason is that [del 0] breaks the message passing chain and executes the messages downstream at the beginning of the next scheduler tick. Same thing for dynamically deleting objects. Don't worry too much. If you've been using [iem_receive] and dynamically deleted objects and didn't experience a crash, it probably means you're using it in more or less safe ways. It's just something to keep in mind for your next patch :-) Christof On 25.03.2020 22:16, oliver wrote: > Christof Ressi wrote: >> Check out the following discussion on GitHub: >> https://github.com/pure-data/pure-data/pull/604 >> >> TL;DR: if you unbind a symbol from a receiver while sending to the >> symbol, Pd can crash because you modify the bind list while iterating >> over it. >> >> Personally, I've been using [iem_receive] in some projects and didn't >> run into problems, but only because I avoid the case described above. > > Thanks Christof for the explanation ! > > @IOhannes: i think this should be noted in the helpfile. > > >> Dynamically destroying objects is even more dangerous ;-) > > Bummer ... another thing i do quite often ;-) > > Since i am not a programmer: how would i decode that twinkle emoji in > your sentence ? > > does it mean: > > a.) be happy that you survived so far, because you're really on mined > territory here ... > > b.) i know it's not encouraged, but as long as you don't tell anybody ... > > > > sorry ... getting a little anxious these days ... ;-) > > best > > oliver > > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi,
You can do [s $0-foo] [r $0-foo].
See menu/help --> Pure Data/2.control.examples/13.locality.pd
--
Mensaje telepatico asistido por maquinas.
On 3/25/2020 12:29 PM, Francis Blair wrote:
Hi Pd-list,
A couple times now I've thought that it would be very convenient to change the name of a receive after instantiation, but I'm not finding any way of doing that. If this is impossible, I'll clarify that essentially what i want is for an abstraction to be able to point to the $0 patch number on instantiation. Is there a solution like this available within Pd?
Thanks!
Francis
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
Francis Blair -
Ingo -
IOhannes m zmölnig -
Lucas Cordiviola -
oliver -
wolfgang spahn