Thanks, will look into it ;) > On 17 Jan 2023, at 21.08, Alexandre Torres Porres <por...@gmail.com> wrote: > > 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 <mailto: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 >> <mailto: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 >>>> <mailto: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 <mailto: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 <mailto: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 list >>>>> Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> >>>>> https://lists.puredata.info/listinfo/pd-dev >>>>> <https://lists.puredata.info/listinfo/pd-dev> >>>> _______________________________________________ >>>> Pd-dev mailing list >>>> Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> >>>> https://lists.puredata.info/listinfo/pd-dev >>>> <https://lists.puredata.info/listinfo/pd-dev> >>>> _______________________________________________ >>>> Pd-dev mailing list >>>> Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> >>>> https://lists.puredata.info/listinfo/pd-dev >>>> <https://lists.puredata.info/listinfo/pd-dev> >>> > > _______________________________________________ > Pd-dev mailing list > Pd-dev@lists.iem.at <mailto:Pd-dev@lists.iem.at> > https://lists.puredata.info/listinfo/pd-dev > <https://lists.puredata.info/listinfo/pd-dev>
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
