[PD-dev] Send~ and receive does not allow you to change name with a symbol!

[Alexandre Torres Porres]

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 <
syntaxerror60 at 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 <info at 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 <porres at 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 <
> info at 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 <
>> syntaxerror60 at 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-dev at lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230117/0204f1a3/attachment-0001.htm>