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 <
syntaxerro...@hotmail.com> escreveu:
> Ahh, okay, thanks :)
>
> > On 17 Jan 2023, at 21.14,
Ahh, okay, thanks :)
> On 17 Jan 2023, at 21.14, Christof Ressi 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
I was thinking the same.
Also, if the concern is "too many dsp objects", put them in sub patches /
abstractions and use [switch~] to turn them off. This is what I do in our
spatialization server patches at work where there are 4 levels of channel
routing between 64 objects on each level. For
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
Thanks, will look into it ;)
> On 17 Jan 2023, at 21.08, Alexandre Torres Porres 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
>
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 <
syntaxerro...@hotmail.com> escreveu:
> Yes, I checked help patches, I saw that they are kind of opposite, the
> send~ and the
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
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 wrote:
>
> Eh, [throw~] is many-to-one, not one-to-many...
>
>
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 <
syntaxerro...@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
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
Em ter., 17 de jan. de 2023 às 16:57, Christof Ressi
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.
___
Pd-dev mailing list
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
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~,
so, [throw~] can set the destination, why not use it?
Em ter., 17 de jan. de 2023 às 16:44, Christof Ressi
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
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 <
syntaxerro...@hotmail.com>
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~]
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
Em ter., 17 de jan. de 2023 às 16:07, Jakob Skouborg <
syntaxerro...@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
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
Em ter., 17 de jan. de 2023 às 15:55, Jakob Skouborg <
syntaxerro...@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
Em ter., 17 de jan. de 2023 às 12:28, Jakob Skouborg <
syntaxerro...@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,
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
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
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~
24 matches
Mail list logo