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

[Alexandre Torres Porres]

When you specify the use case we can think of alternative solutions than
the one you're asking, that's why I ask. I also ask to get convinced I'd
need to add it to my library for you with M1 support, you know?

Em ter., 17 de jan. de 2023 às 16:37, Jakob Skouborg <
syntaxerror60 at hotmail.com> escreveu:

> Why exactly I need it?
>
> It’s not only for me but for everyone. I just think it would be great if
> all those style of objects had the same feature. Send~, receive~, send and
> receive, they are all related and I think it would be nice with same
> features. That was why I mention the receive version too.
>
> If there are issues with adding it, I respect that, I just felt that it
> would be a nice update. I can’t code that well, but non coders still have
> ideas and suggestions, but in the end I respect what the coders say, they
> know if it’s feasible or not.
>
> A use case is to be able to use one send~ to be able to send it to
> different destinations. So for example if you have 3 receive~ called
> dest-1, dest-2 and dest-3. Then it would be nice to able to set the name of
> send~ to one of the 3 names, so you can switch between which one you send
> to. As it is now, then I need to use 3 different send~ objects, with the
> same names as the destinations object and then use a multiplexer to route
> it to the right send~. My experience is just, especially for big patches,
> that keeping the amount of audio rate objects to a minimum is always the
> best. If we could use one send instead of 3 or 10 for that matter, it would
> be better, performance wise. Generally it can be used for all kinds of
> routing matrixes :)
>
>
> On 17 Jan 2023, at 20.21, Alexandre Torres Porres <porres at gmail.com>
> 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.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230117/ebb1199e/attachment.htm>