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@gmail.com wrote:
Em ter., 17 de jan. de 2023 às 16:07, Jakob Skouborg <syntaxerror60@hotmail.com mailto:syntaxerror60@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.