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

Jakob Skouborg syntaxerror60 at hotmail.com
Tue Jan 17 21:12:20 CET 2023


Thanks, will look into it ;) 

> On 17 Jan 2023, at 21.08, Alexandre Torres Porres <porres at 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 <syntaxerror60 at hotmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 list
>>>>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>>>> https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev>
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>>> https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev>
>>>> _______________________________________________
>>>> Pd-dev mailing list
>>>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>>> https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev>
>>> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
> https://lists.puredata.info/listinfo/pd-dev <https://lists.puredata.info/listinfo/pd-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230117/c5d8c6f9/attachment.htm>


More information about the Pd-dev mailing list