the information about delay and keeping things in sync is in the [pd execution order] suboatch in the help files
Em ter., 17 de jan. de 2023 às 17:07, Jakob Skouborg < syntaxerro...@hotmail.com> escreveu: > Yes, I checked help patches, I saw that they are kind of opposite, the > send~ and the catch~. I was just wondering if there were any differences > “under the hood”? > > Do you for example know if there is a block of delay added to catch~ or > tabsend~, like Miller mentioned there would be if the symbol naming feature > was added to send~? > > Best wishes, > Jakob > > On 17 Jan 2023, at 21.01, Christof Ressi <i...@christofressi.com> wrote: > > > Beside that you can have several throw~ with same name and only one send~ > with a specific name? > > That's the main point. You can have several [catch~] objects summing into > the same [throw~] object. Conversely, you can have many [receive~] objects > reading from the same [send~]. So in a way they do the exact opposite. > > On 17.01.2023 20:57, Jakob Skouborg wrote: > > I’ve never used catch~ or throw~before. Tried it and it works :) > > Just out of curiosity, what's the difference between send~/receive~ and > throw~/catch~? Beside that you can have several throw~ with same name and > only one send~ with a specific name? Is there a block of delay added to > throw~, like Miller mentioned there would be for send~, if we add the > option to change name with a symbol? > > Best wishes, > Jakob > > On 17 Jan 2023, at 20.47, Alexandre Torres Porres <por...@gmail.com> > wrote: > > so, [throw~] can set the destination, why not use it? > > Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi < > i...@christofressi.com> escreveu: > >> >> I see, I wonder why exactly you need this, like a specific use case. >> >> One concrete example: you have a modular system where the output of an >> abstraction may be used by other abstractions, but they do not know >> anything about each other. For this you might want to use a [send~] and >> [receive~] objects where the names are chosen by the user, e.g. with symbol >> atoms. >> >> In general it's problematic if a parameter can only be set as a creation >> argument because sometimes not everything is known at creation time. This >> can be worked around with dynamic patching, but as we know, this is not >> "officially" supported. >> >> @Miller: a settable [send~] can be written easily, you just have to call >> canvas_update_dsp() after changing the name. Of course, this is not >> realtime-safe, but it's better than nothing. >> >> Christof >> On 17.01.2023 20:21, Alexandre Torres Porres wrote: >> >> Em ter., 17 de jan. de 2023 às 16:07, Jakob Skouborg < >> syntaxerro...@hotmail.com> escreveu: >> >>> I will check the ELSE options, thanks, all though it is the sender that >>> doesn’t offer option to change name. >>> >>> For adding it to Vanilla version, Miller gave an answer, which indicated >>> there is not an easy way to do it, without adding a block of delay. But >>> nice to see that an issue has been raised, mentioning it. >>> >> >> The issue on github is for an inlet to receive, not being able to set >> send name in [send~]. >> >> >>> I just need to be able to change the send~ name. >>> >> >> I see, I wonder why exactly you need this, like a specific use case. >> >> >> _______________________________________________ >> Pd-dev mailing >> listpd-...@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@lists.iem.at >> https://lists.puredata.info/listinfo/pd-dev >> > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://lists.puredata.info/listinfo/pd-dev > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at > https://lists.puredata.info/listinfo/pd-dev >
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
