Message: 4 Date: Tue, 17 Jan 2023 08:32:35 +0100 From: IOhannes m zmoelnigzmoelnig@iem.at
- [pack~] and [unpack~] are of course natural names for these objects.
*unfortunately* i have added objects of the same name (but with different functionality) to zexy about 23 years ago. (the objects predate zexy's use of*any* VCS; but the copyright boilerplate says 2000/09/01 and i have no reason to distrust it). so i expect that either old patches that use zexy's [pack~]/[unpack~] are going to break, or the new multichannel [pack~]/[unpack~] won't be usable if zexy is loaded as a multi-object library.
VCV Rack uses [split] and [merge] for this kind of objects
Hello :)
I was just wondering about a thing with the send and receive objects in PD, both the audio rate objects and the non audio rate objects.
These 2 objects allows you to set the name with a symbol: Receive~ Send
These 2 objects does not allow you to set the name with a symbol: Send~ Receive
So was just wondering if there is a specific reason why not all of them offers the option to change name with a symbol?
I have been using the externals ext13, but they haven’t been updated in a decade.
Personally I think it would be a nice and meaningful update that all of the send/receive objects would offer the same features.
Second, it would eliminate the need for decade old externals.
Is there a chance that this will be updated in the future?
Thanks in advance, Jakob
I can't think how to implement this without adding one-block delays (either compatibly with existing behavior but mysterious, or else just a blanket, incompatible one-block delay to everything. I don't think either situation would be any good.
I'd be open to adding a "delayadd~" object to add a signal into an existing delay line, in which the delay time could be managed better, I think. This would be usable as a signal bus - but would come with an explicit minimum delay of one block.
cheers Miller
On Tue, Jan 17, 2023 at 03:55:16PM +0100, Jakob Skouborg wrote:
Hello :)
I was just wondering about a thing with the send and receive objects in PD, both the audio rate objects and the non audio rate objects.
These 2 objects allows you to set the name with a symbol: Receive~ Send
These 2 objects does not allow you to set the name with a symbol: Send~ Receive
So was just wondering if there is a specific reason why not all of them offers the option to change name with a symbol?
I have been using the externals ext13, but they haven’t been updated in a decade.
Personally I think it would be a nice and meaningful update that all of the send/receive objects would offer the same features.
Second, it would eliminate the need for decade old externals.
Is there a chance that this will be updated in the future?
Thanks in advance, Jakob
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Hey :)
Ahh, I see, there might be some issues there. I am not that code savy, so can’t really make any suggestions.
Been using the ext13 send~/receive~ for a routing system for an updated version of a PD DX7 clone, rebuild using the clone object.
I am trying to keep everything as vanilla as possible, for future compatibility. I’ve got an M1 Macbook and would love to run PD without running it via Rosetta2, to take full advantage of the processor. I think some externals are pretty questionable if they ever will be updated to run natively on an M1 processor, so just looking for solutions that don’t need externals.
Anyway, just thought I’d suggest it. Thanks for the answer ;)
Best wishes, Jakob
On 17 Jan 2023, at 18.58, Miller Puckette msp@ucsd.edu wrote:
I can't think how to implement this without adding one-block delays (either compatibly with existing behavior but mysterious, or else just a blanket, incompatible one-block delay to everything. I don't think either situation would be any good.
I'd be open to adding a "delayadd~" object to add a signal into an existing delay line, in which the delay time could be managed better, I think. This would be usable as a signal bus - but would come with an explicit minimum delay of one block.
cheers Miller
On Tue, Jan 17, 2023 at 03:55:16PM +0100, Jakob Skouborg wrote:
Hello :)
I was just wondering about a thing with the send and receive objects in PD, both the audio rate objects and the non audio rate objects.
These 2 objects allows you to set the name with a symbol: Receive~ Send
These 2 objects does not allow you to set the name with a symbol: Send~ Receive
So was just wondering if there is a specific reason why not all of them offers the option to change name with a symbol?
I have been using the externals ext13, but they haven’t been updated in a decade.
Personally I think it would be a nice and meaningful update that all of the send/receive objects would offer the same features.
Second, it would eliminate the need for decade old externals.
Is there a chance that this will be updated in the future?
Thanks in advance, Jakob
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Em ter., 17 de jan. de 2023 às 15:55, Jakob Skouborg < syntaxerror60@hotmail.com> escreveu:
Been using the ext13 send~/receive~ for a routing system for an updated version of a PD DX7 clone, rebuild using the clone object.
Oh, so you've been using something else then... why do you need this? I can consider an alternative in ELSE...
Em ter., 17 de jan. de 2023 às 12:28, Jakob Skouborg < syntaxerror60@hotmail.com> escreveu:
So was just wondering if there is a specific reason why not all of them offers the option to change name with a symbol?
Yes, and what exactly do you need?
I have been using the externals ext13, but they haven’t been updated in a decade.
seems you need [receive] to take a receive name and you're using [receive13] instead. If you don't like a decade old dead external, you can use [else/receiver], which is pretty much alive.
Is there a chance that this will be updated in the future?
If you search on github, you'll see a request to add an inlet to vanilla's [receive] here https://github.com/pure-data/pure-data/issues/603 and a fix was proposed here https://github.com/pure-data/pure-data/pull/604
what's in the way is this --> https://github.com/pure-data/pure-data/pull/604#issuecomment-562873572
and there are two currently active PRs that needed to be merged before to clear out the way, they are https://github.com/pure-data/pure-data/pull/1759 and https://github.com/pure-data/pure-data/pull/1760
So, hopefully, these can be considered soon and merged and we'll see if Vanilla can also support this, so I can also get rid of else/receiver :)
cheers
I don’t mind using older externals, but just trying to future proof my patches. I am not expecting ext13 to be updated to run on natively an M1 processor.
I just need to be able to change the send~ name. 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. Hopefully that can be helpful :)
Best wishes, Jakob
On 17 Jan 2023, at 19.56, Alexandre Torres Porres porres@gmail.com wrote:
Em ter., 17 de jan. de 2023 às 12:28, Jakob Skouborg <syntaxerror60@hotmail.com mailto:syntaxerror60@hotmail.com> escreveu: So was just wondering if there is a specific reason why not all of them offers the option to change name with a symbol?
Yes, and what exactly do you need?
I have been using the externals ext13, but they haven’t been updated in a decade.
seems you need [receive] to take a receive name and you're using [receive13] instead. If you don't like a decade old dead external, you can use [else/receiver], which is pretty much alive.
Is there a chance that this will be updated in the future?
If you search on github, you'll see a request to add an inlet to vanilla's [receive] here https://github.com/pure-data/pure-data/issues/603 https://github.com/pure-data/pure-data/issues/603 and a fix was proposed here https://github.com/pure-data/pure-data/pull/604 https://github.com/pure-data/pure-data/pull/604
what's in the way is this --> https://github.com/pure-data/pure-data/pull/604#issuecomment-562873572 https://github.com/pure-data/pure-data/pull/604#issuecomment-562873572
and there are two currently active PRs that needed to be merged before to clear out the way, they are https://github.com/pure-data/pure-data/pull/1759 https://github.com/pure-data/pure-data/pull/1759 and https://github.com/pure-data/pure-data/pull/1760 https://github.com/pure-data/pure-data/pull/1760
So, hopefully, these can be considered soon and merged and we'll see if Vanilla can also support this, so I can also get rid of else/receiver :)
cheers
Em ter., 17 de jan. de 2023 às 16:07, Jakob Skouborg < 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.
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.
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@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@gmail.com wrote:
Em ter., 17 de jan. de 2023 às 16:07, Jakob Skouborg < 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.
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@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 https://lists.puredata.info/listinfo/pd-dev
so, [throw~] can set the destination, why not use it?
Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi info@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@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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@christofressi.com mailto:info@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@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.
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
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@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@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@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 https://lists.puredata.info/listinfo/pd-dev_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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@gmail.com mailto:porres@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@christofressi.com mailto:info@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@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.
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
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@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@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@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@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@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks, will look into it ;)
On 17 Jan 2023, at 21.08, Alexandre Torres Porres porres@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@hotmail.com mailto:syntaxerror60@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@christofressi.com mailto:info@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@gmail.com mailto:porres@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@christofressi.com mailto:info@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@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.
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
On 17.01.2023 21:06, Jakob Skouborg wrote:
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~?
There would be no extra block of delay for [send~]. I suspect Miller was really thinking about [delwrite~]. That one is indeed tricky...
Ahh, okay, thanks :)
On 17 Jan 2023, at 21.14, Christof Ressi info@christofressi.com wrote:
On 17.01.2023 21:06, Jakob Skouborg wrote:
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~?
There would be no extra block of delay for [send~]. I suspect Miller was really thinking about [delwrite~]. That one is indeed tricky...
by the way, there's already an active request at https://github.com/pure-data/pure-data/issues/1567
Christof, do you think you try a PR for this?
Em ter., 17 de jan. de 2023 às 17:27, Jakob Skouborg < syntaxerror60@hotmail.com> escreveu:
Ahh, okay, thanks :)
On 17 Jan 2023, at 21.14, Christof Ressi info@christofressi.com wrote:
On 17.01.2023 21:06, Jakob Skouborg wrote:
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~?
There would be no extra block of delay for [send~]. I suspect Miller was
really thinking about [delwrite~]. That one is indeed tricky...
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
you can avoid with 'order of execution', check info on the help patches
Em ter., 17 de jan. de 2023 às 16:57, Jakob Skouborg < syntaxerror60@hotmail.com> escreveu:
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@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@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@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@lists.iem.athttps://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Eh, [throw~] is many-to-one, not one-to-many...
Again, it is generally not good if a parameter can *only* be set via creation arguments.
BTW, my personal workaround is to use [tabsend~] and [tabreceive~]. They basically work the same way as [send~] and [receive~], but both objects are settable :-) Also, they work at any block size.
On 17.01.2023 20:47, Alexandre Torres Porres wrote:
so, [throw~] can set the destination, why not use it?
Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi info@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@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 https://lists.puredata.info/listinfo/pd-dev_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em ter., 17 de jan. de 2023 às 16:57, Christof Ressi info@christofressi.com escreveu:
it is generally not good if a parameter can *only* be set via creation arguments.
Agreed! And I hope we can update [send~] to also allow it.
Thanks, will check out the tabsend~ and tabreceive~ too.
I’ve used them in other cases, mostly with tables, never thought about using them for this kind of patching.
Best wishes, Jakob
On 17 Jan 2023, at 20.57, Christof Ressi info@christofressi.com wrote:
Eh, [throw~] is many-to-one, not one-to-many...
Again, it is generally not good if a parameter can *only* be set via creation arguments.
BTW, my personal workaround is to use [tabsend~] and [tabreceive~]. They basically work the same way as [send~] and [receive~], but both objects are settable :-) Also, they work at any block size.
On 17.01.2023 20:47, Alexandre Torres Porres wrote:
so, [throw~] can set the destination, why not use it?
Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi <info@christofressi.com mailto:info@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@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.
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
-
Alexandre Torres Porres -
Christof Ressi -
Jakob Skouborg -
Jean-Yves Gratius -
Miller Puckette