On Jan 18, 2023, at 2:41 AM, pd-dev-request@lists.iem.at wrote:
"MC is not an entirely new API for MSP objects. Instead it is built on top of the existing MSP API. (...)
This name prefix / wrapper approach seems like an implicit way of what Miller is looking at doing more explicitly via [clone]. Either way, they have also avoided having to update each object directly.
so it seems they did not create new codes and new objects, just adapted, and even made it possible for it to open a special help patch but it's all the same object and you can use this API to generate externals - if I get things correctly...
Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
I believe this doesn't require any changes in libpd, thankfully.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox danomatika@gmail.com escreveu:
Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
Hmm, I am still missing what is Pd's approach to load an existing external into a mc mechanism...
I'm understanding that [clone] may be able to load internal objects (and abstractions of course) into a new multi-channel paradigm, but not externals. Please enlighten me.
cheers
I can't answer you as I haven't looked at Miller's implementation. I can *imagine* that if [clone] is able to load an internal class then it follows it would be able to open an external class which is loaded. I didn't mean to imply that it can *now* but more than it *might* be able to if it can loaded internal objects.
On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu: Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
Hmm, I am still missing what is Pd's approach to load an existing external into a mc mechanism...
I'm understanding that [clone] may be able to load internal objects (and abstractions of course) into a new multi-channel paradigm, but not externals. Please enlighten me.
cheers
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Cool, yeah, it would be ideal if it could also load externals somehow ;)
Em qua., 18 de jan. de 2023 às 11:45, Dan Wilcox danomatika@gmail.com escreveu:
I can't answer you as I haven't looked at Miller's implementation. I can *imagine* that if [clone] is able to load an internal class then it follows it would be able to open an external class which is loaded. I didn't mean to imply that it can *now* but more than it *might* be able to if it can loaded internal objects.
On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox danomatika@gmail.com escreveu:
Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
Hmm, I am still missing what is Pd's approach to load an existing external into a mc mechanism...
I'm understanding that [clone] may be able to load internal objects (and abstractions of course) into a new multi-channel paradigm, but not externals. Please enlighten me.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
but anyway, I have a few doubts how [clone] would deal with internals, and this is just a rough idea so far, and we'll have to better discuss this when time is right...
for instance, how would someone deal with arguments?
Like, I made a simple abstraction to mimic somewhat MAX's [mc.dac~], which takes multichannel signals and distributes them from channel 1.
In clone, I need a damn simple abstraction with [inlet~] going into [dac~ $1], and I use the '-di' flag to distribute multichannel input and '-s 1' so '$1' gets values starting from 1. It works great, I also have an argument in [clone] for the number of abstractions that in this case represents maximum channels.
So, being able to call internal objects inside [clone] saves us the need to write a simple abstraction for this or any other object, which is good, but how would I be able to set the argument of [dac~] in [clone] and have it receive the instance number? That's something to think about, because simply calling "dac~" instead of an abstraction name doesn't or shouldn't do it.
Now, I can and will gladly code an abstraction that mimics MAX's [mc.dac~] in ELSE (actually I have already, just to test these things). The abstraction uses [clone] internally and uses yet another abstraction with [dac~] inside, so the user just needs to call the abstraction name. With what we have, someone can make a library with all internals and whatever more externals they like in a similar fashion. It's great that the doors are opened for this and that we can go crazy. It would also be nice that we didn't have to worry about this and have our "wrapper object". If not into [clone], maybe a new object, why not call it [mc~]? I think such a new object is needed because it might be hard to expand [clone] to do more things than it's doing. this [mc~] object than takes object names as an argument, and further arguments according to the objects argument. This [mc~] object would be similar to [clone] and create inlets/outlets according to the given object name and we'd have a way to use them to set all copies or each of them. Maybe "mc.dac~" is a special case... let's think of a [lop~] object, we wouldn't really need to specify "$1" as an argument... it doesn't make much sense. It does make sense to maybe use a cutoff argument for all copies though, so you could have [mc~ lop~ 500] and all signal inputs get filter at 500hz. For [dac~], the special case, we could give it $1 as an argument and it would mean instance number, and a similar flag '-s 1' could set it, so we'd have [mc~ -s 1 dac~ $1].
well, I guess that's it, I'm tired and going to bed
cheers and good night
Em qua., 18 de jan. de 2023 às 11:45, Dan Wilcox danomatika@gmail.com escreveu:
I can't answer you as I haven't looked at Miller's implementation. I can *imagine* that if [clone] is able to load an internal class then it follows it would be able to open an external class which is loaded. I didn't mean to imply that it can *now* but more than it *might* be able to if it can loaded internal objects.
On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox danomatika@gmail.com escreveu:
Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
Hmm, I am still missing what is Pd's approach to load an existing external into a mc mechanism...
I'm understanding that [clone] may be able to load internal objects (and abstractions of course) into a new multi-channel paradigm, but not externals. Please enlighten me.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
On 1/19/23 07:02, Alexandre Torres Porres wrote:
So, being able to call internal objects inside [clone] saves us the need to write a simple abstraction for this or any other object, which is good, but how would I be able to set the argument of [dac~] in [clone] and have it receive the instance number? That's something to think about, because simply calling "dac~" instead of an abstraction name doesn't or shouldn't do it.
i'm not actually sure i can follow your problems here. how would an [mc~] wrapper make live any simpler than [clone]?
could you please rephrase your elaborate examples for decaffeinated 5 year old with concrete examples?
e.g. you are saying that for creating a multichannel aware [dac~]:
In clone, I need a damn simple abstraction with [inlet~] going into [dac~ $1]
so afaict the idea is to get rid of this abstraction altogether, and be able to just use [clone -di -s 1 dac~ 16]
so you give a counter-example (instead of the "special-case [dac~]"):
let's think of a [lop~] object, we wouldn't really need to specify "$1" as an argument... it doesn't make much sense. It does make sense to maybe use a cutoff argument for all copies though, so you could have [mc~ lop~ 500] and all signal inputs get filter at 500hz.
again, i don't see why we couldn't juse use [clone -x -d lop~ 500]
how could that be different from your [mc~]? (well: apart from having to remember the actual incantation)
mgfadsr IOhannes
Em qui., 19 de jan. de 2023 às 05:04, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
afaict the idea is to get rid of this abstraction altogether, and be able to just use [clone -di -s 1 dac~ 16]
yeah I guess it was pretty late and I was tired and I couldn't see how this could actually make [dac~] get arguments from the instance number. I was looking at the abstraction and had a hard time adapting to the new concept.
again, i don't see why we couldn't juse use [clone -x -d lop~ 500]
yup, forgot about the -x flag, so yeah, [clone] would cover both cases easily! Sorry I was thinking clearly and through. I am just rather hesitant in believing [clone] can actually solve all the problems without any modification :) and even now I am still insecure. But anyway, in the case we find something in the way and it needs modification, we could have a modified alternative with another name, that's all, but I guess I may eventually get confident it doesn't need anything new, let me think through and see ;)
thanks
Without reading your reply in depth, it calls to mind my feeling that it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …]
This is probably another discussion, however.
enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com
On Jan 19, 2023, at 7:02 AM, Alexandre Torres Porres porres@gmail.com wrote:
but anyway, I have a few doubts how [clone] would deal with internals, and this is just a rough idea so far, and we'll have to better discuss this when time is right...
for instance, how would someone deal with arguments?
Like, I made a simple abstraction to mimic somewhat MAX's [mc.dac~], which takes multichannel signals and distributes them from channel 1.
In clone, I need a damn simple abstraction with [inlet~] going into [dac~ $1], and I use the '-di' flag to distribute multichannel input and '-s 1' so '$1' gets values starting from 1. It works great, I also have an argument in [clone] for the number of abstractions that in this case represents maximum channels.
So, being able to call internal objects inside [clone] saves us the need to write a simple abstraction for this or any other object, which is good, but how would I be able to set the argument of [dac~] in [clone] and have it receive the instance number? That's something to think about, because simply calling "dac~" instead of an abstraction name doesn't or shouldn't do it.
Now, I can and will gladly code an abstraction that mimics MAX's [mc.dac~] in ELSE (actually I have already, just to test these things). The abstraction uses [clone] internally and uses yet another abstraction with [dac~] inside, so the user just needs to call the abstraction name. With what we have, someone can make a library with all internals and whatever more externals they like in a similar fashion. It's great that the doors are opened for this and that we can go crazy. It would also be nice that we didn't have to worry about this and have our "wrapper object". If not into [clone], maybe a new object, why not call it [mc~]? I think such a new object is needed because it might be hard to expand [clone] to do more things than it's doing. this [mc~] object than takes object names as an argument, and further arguments according to the objects argument. This [mc~] object would be similar to [clone] and create inlets/outlets according to the given object name and we'd have a way to use them to set all copies or each of them. Maybe "mc.dac~" is a special case... let's think of a [lop~] object, we wouldn't really need to specify "$1" as an argument... it doesn't make much sense. It does make sense to maybe use a cutoff argument for all copies though, so you could have [mc~ lop~ 500] and all signal inputs get filter at 500hz. For [dac~], the special case, we could give it $1 as an argument and it would mean instance number, and a similar flag '-s 1' could set it, so we'd have [mc~ -s 1 dac~ $1].
well, I guess that's it, I'm tired and going to bed
cheers and good night
Em qua., 18 de jan. de 2023 às 11:45, Dan Wilcox danomatika@gmail.com escreveu: I can't answer you as I haven't looked at Miller's implementation. I can *imagine* that if [clone] is able to load an internal class then it follows it would be able to open an external class which is loaded. I didn't mean to imply that it can *now* but more than it *might* be able to if it can loaded internal objects.
On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox danomatika@gmail.com escreveu:
Also similar to Miller's approach, there appears to be a way to load existing mono externals in the mc mechanism. So yeah, same problem, similar technical solution, different implementation.
Hmm, I am still missing what is Pd's approach to load an existing external into a mc mechanism...
I'm understanding that [clone] may be able to load internal objects (and abstractions of course) into a new multi-channel paradigm, but not externals. Please enlighten me.
cheers
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling that it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the patch counter and user-provided args) - as per the "definition" of subpatches (aka "[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is probably not so complicated: subpatches within [clone] could just use an implicit "dummy-abstraction" that wraps the subpatch even though it technically is stored in the patch file that contains the [clone] object. arguments are visible in the subpatches as they are passed to [clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop 500], where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious what the [clone] instance is used for), and $3="500" (e.g. the curoff frequency). all the subpatches share the same $0, but this is distinct from the $0 in the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently from ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and the way this is handled with [clone] is via $1. this however would overwrite any $1 passed to the abstraction containing the [clone] object. therefore the other dollargs for the abstraction (including $0) shouldn't propagate to the [clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
Well, maybe not orthogonal depending on how it's done. I've been thinking for
10 years about allowing patches to cache a store of dependencies in the form
of abstractions associated with names that can then be called by name. The same mechanism could: 1) allow you to say "clone osc~" by creating an anonymous patch that just has an osc~ and inlets/outlets; 2) allow "clone -" or something that would allow you to edit the clonee on the fly (this is Dan's idea, which hadn't occirred to me yet) 3) allow you to publish in a single ".pd" file a patch with its abstraction dependencies included, saving possible search-path confusion. 4) maybe also somehow avoid the embarassing necessity for invisible "float" and "floatarray" canvases. Probably someone has named a patch "float" and suffered for it.
The main thing I was thinking about was (3) - because beginners are always copying patches out of the doc/... examples and then wondering why "output~" doesn't appear. If output~ were encapsulated in the patch itself that would save a lot of newbies a headache or two.
cheers Miller
On Thu, Jan 19, 2023 at 03:04:02PM +0100, IOhannes m zmoelnig wrote:
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling that it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the patch counter and user-provided args) - as per the "definition" of subpatches (aka "[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is probably not so complicated: subpatches within [clone] could just use an implicit "dummy-abstraction" that wraps the subpatch even though it technically is stored in the patch file that contains the [clone] object. arguments are visible in the subpatches as they are passed to [clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop 500], where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious what the [clone] instance is used for), and $3="500" (e.g. the curoff frequency). all the subpatches share the same $0, but this is distinct from the $0 in the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently from ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and the way this is handled with [clone] is via $1. this however would overwrite any $1 passed to the abstraction containing the [clone] object. therefore the other dollargs for the abstraction (including $0) shouldn't propagate to the [clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em qui., 19 de jan. de 2023 às 15:36, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
The main thing I was thinking about was (3) - because beginners are always copying patches out of the doc/... examples and then wondering why "output~" doesn't appear. If output~ were encapsulated in the patch itself that would save a lot of newbies a headache or two.
Well, the thing is that now [output~] is an abstraction in 'extra', so Pd should find it now :)
But I think I see what you mean, and maybe Purr Data has implemented something similar. They have this [ab] object. For reference: "*The [ab] object is accompanied by a number of supplemental objects (abinfo, abdefs, abclone) which let you inspect and clone private abstractions. There’s also an “Abstractions” dialog which can be accessed via the Window menu. This will give you a quick overview of the private abstractions contained in a patch. Also, it will show you private abstractions which aren’t currently being used (i.e., don’t have any instances), so that you can select and then delete them if they aren’t needed any more*." (from https://agraef.github.io/purr-data-intro/Purr-Data-Intro.pdf )
This "private abstraction" is then a subpatch that is saved with the patch file. It can have arguments and they have their own "$0". There's [abclone] that can clone them too...
I like this idea as I have a few external objects that are abstractions which use [clone] and I need yet another abstraction to call inside clone. This would make things much simpler as many times you don't really want to create and clone a "real abstraction" (one you'd have for different purposes other than using in a particular [clone] object in your patch).
cheers
cheers Miller
On Thu, Jan 19, 2023 at 03:04:02PM +0100, IOhannes m zmoelnig wrote:
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling that
it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the patch counter and user-provided args) - as per the "definition" of subpatches
(aka
"[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is
probably
not so complicated: subpatches within [clone] could just use an implicit "dummy-abstraction" that wraps the subpatch even though it technically is stored in the patch file that contains the [clone] object. arguments are visible in the subpatches as they are passed to [clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop 500], where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious what
the
[clone] instance is used for), and $3="500" (e.g. the curoff frequency). all the subpatches share the same $0, but this is distinct from the $0 in the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently
from
ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and the
way
this is handled with [clone] is via $1. this however would overwrite any
$1
passed to the abstraction containing the [clone] object. therefore the
other
dollargs for the abstraction (including $0) shouldn't propagate to the [clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
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
Hmm, I didn't notice that output~ got moved into extra... I think we should put it back in doc! The DB-based way of setting levels is wrong-headed and confusing.
cheers Miller
On Thu, Jan 19, 2023 at 04:18:53PM -0300, Alexandre Torres Porres wrote:
Em qui., 19 de jan. de 2023 às 15:36, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
The main thing I was thinking about was (3) - because beginners are always copying patches out of the doc/... examples and then wondering why "output~" doesn't appear. If output~ were encapsulated in the patch itself that would save a lot of newbies a headache or two.
Well, the thing is that now [output~] is an abstraction in 'extra', so Pd should find it now :)
But I think I see what you mean, and maybe Purr Data has implemented something similar. They have this [ab] object. For reference: "*The [ab] object is accompanied by a number of supplemental objects (abinfo, abdefs, abclone) which let you inspect and clone private abstractions. There’s also an “Abstractions” dialog which can be accessed via the Window menu. This will give you a quick overview of the private abstractions contained in a patch. Also, it will show you private abstractions which aren’t currently being used (i.e., don’t have any instances), so that you can select and then delete them if they aren’t needed any more*." (from https://urldefense.com/v3/__https://agraef.github.io/purr-data-intro/Purr-Da... )
This "private abstraction" is then a subpatch that is saved with the patch file. It can have arguments and they have their own "$0". There's [abclone] that can clone them too...
I like this idea as I have a few external objects that are abstractions which use [clone] and I need yet another abstraction to call inside clone. This would make things much simpler as many times you don't really want to create and clone a "real abstraction" (one you'd have for different purposes other than using in a particular [clone] object in your patch).
cheers
cheers Miller
On Thu, Jan 19, 2023 at 03:04:02PM +0100, IOhannes m zmoelnig wrote:
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling that
it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the patch counter and user-provided args) - as per the "definition" of subpatches
(aka
"[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is
probably
not so complicated: subpatches within [clone] could just use an implicit "dummy-abstraction" that wraps the subpatch even though it technically is stored in the patch file that contains the [clone] object. arguments are visible in the subpatches as they are passed to [clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop 500], where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious what
the
[clone] instance is used for), and $3="500" (e.g. the curoff frequency). all the subpatches share the same $0, but this is distinct from the $0 in the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently
from
ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and the
way
this is handled with [clone] is via $1. this however would overwrite any
$1
passed to the abstraction containing the [clone] object. therefore the
other
dollargs for the abstraction (including $0) shouldn't propagate to the [clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Em qui., 19 de jan. de 2023 às 16:51, Miller Puckette msp@ucsd.edu escreveu:
Hmm, I didn't notice that output~ got moved into extra... I think we should put it back in doc! The DB-based way of setting levels is wrong-headed and confusing.
Oops, sorry you missed that. I did it for Pd 0.52 and the reasoning was that we actually had like three copies of it in different places, and we were also trying to use it in yet other places. It just felt reasonable to me to keep it in a single place ('extra') and call it there. As I say in its help file "*This is a simple abstraction that's widely used in Pd's documentation (help files and examples). It is included here in 'extra' just for convenience.*"
I also don't like setting the amplitude level with 'dB' by the way, and wouldn't mind if it got removed from 'extra'. I never use it myself, but it'd be good to try and keep just a single copy of it.
I actually like the idea this is offered so other people can use it if they want to keep things Vanilla. Something like this is quite useful for documentation of external libraries. I would actually like to use it in Cyclone's documentation. Also, some external's documentation were made using a similar abstraction called [output~] because it was available in Pd extended. If used now in Vanilla, a replaceable abstraction is found.
What if we design a new simple abstraction like that without the dB setting? I usually use the quartic curve you also suggest and we could just use a slider, it could still be called [output~].
cheers
cheers Miller
On Thu, Jan 19, 2023 at 04:18:53PM -0300, Alexandre Torres Porres wrote:
Em qui., 19 de jan. de 2023 às 15:36, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
The main thing I was thinking about was (3) - because beginners are
always
copying patches out of the doc/... examples and then wondering why "output~" doesn't appear. If output~ were encapsulated in the patch
itself
that would save a lot of newbies a headache or two.
Well, the thing is that now [output~] is an abstraction in 'extra', so Pd should find it now :)
But I think I see what you mean, and maybe Purr Data has implemented something similar. They have this [ab] object. For reference: "*The [ab] object is accompanied by a number of supplemental objects (abinfo,
abdefs,
abclone) which let you inspect and clone private abstractions. There’s
also
an “Abstractions” dialog which can be accessed via the Window menu. This will give you a quick overview of the private abstractions contained in a patch. Also, it will show you private abstractions which aren’t currently being used (i.e., don’t have any instances), so that you can select and then delete them if they aren’t needed any more*." (from
https://urldefense.com/v3/__https://agraef.github.io/purr-data-intro/Purr-Da... )
This "private abstraction" is then a subpatch that is saved with the
patch
file. It can have arguments and they have their own "$0". There's
[abclone]
that can clone them too...
I like this idea as I have a few external objects that are abstractions which use [clone] and I need yet another abstraction to call inside
clone.
This would make things much simpler as many times you don't really want
to
create and clone a "real abstraction" (one you'd have for different purposes other than using in a particular [clone] object in
your
patch).
cheers
cheers Miller
On Thu, Jan 19, 2023 at 03:04:02PM +0100, IOhannes m zmoelnig wrote:
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling
that
it would be *nice* if somehow clone supported subpatches natively to
avoid
requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other
stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the
patch
counter and user-provided args) - as per the "definition" of
subpatches
(aka
"[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is
probably
not so complicated: subpatches within [clone] could just use an implicit
"dummy-abstraction"
that wraps the subpatch even though it technically is stored in the
patch
file that contains the [clone] object. arguments are visible in the subpatches as they are passed to
[clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop
500],
where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious
what
the
[clone] instance is used for), and $3="500" (e.g. the curoff
frequency).
all the subpatches share the same $0, but this is distinct from the
$0 in
the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently
from
ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and
the
way
this is handled with [clone] is via $1. this however would overwrite
any
$1
passed to the abstraction containing the [clone] object. therefore
the
other
dollargs for the abstraction (including $0) shouldn't propagate to
the
[clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Aha, yes, let's do that. It would be sort-of compatible with existing patches (just the control would be different.)
One thing I never figured out was how to: (1) offer mono and stereo operation int he same object; and (2) allow the level to be changed externally without havin to add another (confusing) inlet. So it's the lack of an all-around "best" way to do it that's held me back from putting something in "extra" so far.
But meanwhile, I think someday I should go ahead and split "extra" into true necessities (sigmund~, bonk~, and a couple of stupid compatibility objects) and things that are "useful" (such as the reverberators). Again I've been held back by not having a clear definition of what I think those things should be :)
M
On Thu, Jan 19, 2023 at 05:08:01PM -0300, Alexandre Torres Porres wrote:
Em qui., 19 de jan. de 2023 às 16:51, Miller Puckette msp@ucsd.edu escreveu:
Hmm, I didn't notice that output~ got moved into extra... I think we should put it back in doc! The DB-based way of setting levels is wrong-headed and confusing.
Oops, sorry you missed that. I did it for Pd 0.52 and the reasoning was that we actually had like three copies of it in different places, and we were also trying to use it in yet other places. It just felt reasonable to me to keep it in a single place ('extra') and call it there. As I say in its help file "*This is a simple abstraction that's widely used in Pd's documentation (help files and examples). It is included here in 'extra' just for convenience.*"
I also don't like setting the amplitude level with 'dB' by the way, and wouldn't mind if it got removed from 'extra'. I never use it myself, but it'd be good to try and keep just a single copy of it.
I actually like the idea this is offered so other people can use it if they want to keep things Vanilla. Something like this is quite useful for documentation of external libraries. I would actually like to use it in Cyclone's documentation. Also, some external's documentation were made using a similar abstraction called [output~] because it was available in Pd extended. If used now in Vanilla, a replaceable abstraction is found.
What if we design a new simple abstraction like that without the dB setting? I usually use the quartic curve you also suggest and we could just use a slider, it could still be called [output~].
cheers
cheers Miller
On Thu, Jan 19, 2023 at 04:18:53PM -0300, Alexandre Torres Porres wrote:
Em qui., 19 de jan. de 2023 às 15:36, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
The main thing I was thinking about was (3) - because beginners are
always
copying patches out of the doc/... examples and then wondering why "output~" doesn't appear. If output~ were encapsulated in the patch
itself
that would save a lot of newbies a headache or two.
Well, the thing is that now [output~] is an abstraction in 'extra', so Pd should find it now :)
But I think I see what you mean, and maybe Purr Data has implemented something similar. They have this [ab] object. For reference: "*The [ab] object is accompanied by a number of supplemental objects (abinfo,
abdefs,
abclone) which let you inspect and clone private abstractions. There’s
also
an “Abstractions” dialog which can be accessed via the Window menu. This will give you a quick overview of the private abstractions contained in a patch. Also, it will show you private abstractions which aren’t currently being used (i.e., don’t have any instances), so that you can select and then delete them if they aren’t needed any more*." (from
https://urldefense.com/v3/__https://agraef.github.io/purr-data-intro/Purr-Da... )
This "private abstraction" is then a subpatch that is saved with the
patch
file. It can have arguments and they have their own "$0". There's
[abclone]
that can clone them too...
I like this idea as I have a few external objects that are abstractions which use [clone] and I need yet another abstraction to call inside
clone.
This would make things much simpler as many times you don't really want
to
create and clone a "real abstraction" (one you'd have for different purposes other than using in a particular [clone] object in
your
patch).
cheers
cheers Miller
On Thu, Jan 19, 2023 at 03:04:02PM +0100, IOhannes m zmoelnig wrote:
On 1/19/23 13:00, Dan Wilcox wrote:
Without reading your reply in depth, it calls to mind my feeling
that
it would be *nice* if somehow clone supported subpatches natively to
avoid
requiring abstractions for simple things ala:
[clone pd …]
right. though i think this is somewhat orthogonal to the "other
stuff".
i thought about going to open a feature request along your suggestion (though my idea would have been to just drop the entire object specification, as in [clone 10], in order to be able to create cloned "subpatches".
i didn't do it because I wondered how to handle arguments (both the
patch
counter and user-provided args) - as per the "definition" of
subpatches
(aka
"[pd]"), they inherit all the args from the parent canvas.
in the meantime i have changed my mind and i now think that it is
probably
not so complicated: subpatches within [clone] could just use an implicit
"dummy-abstraction"
that wraps the subpatch even though it technically is stored in the
patch
file that contains the [clone] object. arguments are visible in the subpatches as they are passed to
[clone].
consider [clone pd 10 lop 500]. clicking on the [clone] object would open up a subpatch [pd 0 lop
500],
where you can reference the 3 arguments, with $1="0" (that is: the clone-index), $2="lop" (which i only put there to make it obvious
what
the
[clone] instance is used for), and $3="500" (e.g. the curoff
frequency).
all the subpatches share the same $0, but this is distinct from the
$0 in
the patch that contains the [clone] object.
the reason for this is mostly to separate the [clone pd] consistently
from
ordinary [pd] subpatches. (we do want *some* way to get the clone index into the subpatch, and
the
way
this is handled with [clone] is via $1. this however would overwrite
any
$1
passed to the abstraction containing the [clone] object. therefore
the
other
dollargs for the abstraction (including $0) shouldn't propagate to
the
[clone pd] either, as this would be most confusing)
probably i will create a feature request for this.
gdmasr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Em qui., 19 de jan. de 2023 às 17:14, Miller Puckette msp@ucsd.edu escreveu:
Aha, yes, let's do that. It would be sort-of compatible with existing patches (just the control would be different.)
One thing I never figured out was how to: (1) offer mono and stereo operation int he same object; and
Not sure what you mean, but I do have a hack that allows me to distribute a mono input in the left inlet to both left and right output. I use it in my [else/out~] abstraction.
Because [inlet~] now has an inlet for default value, I give it a ridiculous default value of '10000', so when no signal is connected to the right inlet, it outputs this stupid number and I check for it, it is equal to it I do assume we have a mono input and route the left inlet to both channels. Sounds good? Find attached a new object I'm starting from scratch with this hack.
(2) allow the level to be changed externally without havin to add another (confusing) inlet.
Well, [inlet~ fwd] allows us to do that now and in fact I have already implemented it in the existing [output~] abstraction so it takes a 'level message' to control the output level. I also use a bang message to control the mute logic.
So it's the lack of an all-around "best" way to do it that's held me back from putting something in "extra" so far.
Ok, let me continue to work on this one now then.
cheers
But meanwhile, I think someday I should go ahead and split "extra" into true necessities (sigmund~, bonk~, and a couple of stupid compatibility objects) and things that are "useful" (such as the reverberators). Again I've been held back by not having a clear definition of what I think those things should be :)
M
Ok, here's a newly design [output~] abstraction. If there's only a mono input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function instead of db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the case it was off.
I kept the same control messages as the current [output~] object, a bang message is still there to mute/unmute. A 'level' message is also still there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button that visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value, set it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute toggle is still on :)
I then added two more messages for external control 'mute' and 'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really useful for day to day usage. See screenshot below and find the patch attached. Please give me feedback to see if I'm going in the right direction. If it is ok I will make a PR and update the documentation.
[image: Screen Shot 2023-01-19 at 21.07.18.png]
Cheers~
Feature-creep! :)
On 20.01.23 01:08, Alexandre Torres Porres wrote:
Ok, here's a newly design [output~] abstraction. If there's only a mono input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function instead of db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the case it was off.
I kept the same control messages as the current [output~] object, a bang message is still there to mute/unmute. A 'level' message is also still there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button that visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value, set it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute toggle is still on :)
I then added two more messages for external control 'mute' and 'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really useful for day to day usage. See screenshot below and find the patch attached. Please give me feedback to see if I'm going in the right direction. If it is ok I will make a PR and update the documentation.
Screen Shot 2023-01-19 at 21.07.18.png
Cheers~
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
So, I talked to MAX in private, he mentioned he'd expect a mute message as in "mute 0" / "mute 1". That makes sense. I was keeping the bang button to alter the state for backwards compatibility since the last one had a bang instead, but maybe I shouldn't bother with it as I doubt people were using any external controls at all with this, as I also think people will not use it much in the future. So I changed the mute message and removed the bang for the sake of simplicity and to make it less "feature-creep" :)
Find new version attached with a help file (see screenshot below as well). If no other objection is made I can upload this to my documentation branch soon.
[image: Screen Shot 2023-01-20 at 13.40.19.png]
Em sex., 20 de jan. de 2023 às 07:26, Max abonnements@revolwear.com escreveu:
Feature-creep! :)
On 20.01.23 01:08, Alexandre Torres Porres wrote:
Ok, here's a newly design [output~] abstraction. If there's only a mono input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function instead of db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the case it was off.
I kept the same control messages as the current [output~] object, a bang message is still there to mute/unmute. A 'level' message is also still there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button that visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value, set it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute toggle is still on :)
I then added two more messages for external control 'mute' and 'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really useful for day to day usage. See screenshot below and find the patch attached. Please give me feedback to see if I'm going in the right direction. If it is ok I will make a PR and update the documentation.
Screen Shot 2023-01-19 at 21.07.18.png
Cheers~
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
Actually, personally I use the "mute" button all the time. Perhaps some people don't need it, but me, I often have 3 or 4 different output~ objects in a patch and want to turn them on and off selectively. (I also see sound engineers doing this all the time).
cheers Miller
On Fri, Jan 20, 2023 at 01:41:12PM -0300, Alexandre Torres Porres wrote:
So, I talked to MAX in private, he mentioned he'd expect a mute message as in "mute 0" / "mute 1". That makes sense. I was keeping the bang button to alter the state for backwards compatibility since the last one had a bang instead, but maybe I shouldn't bother with it as I doubt people were using any external controls at all with this, as I also think people will not use it much in the future. So I changed the mute message and removed the bang for the sake of simplicity and to make it less "feature-creep" :)
Find new version attached with a help file (see screenshot below as well). If no other objection is made I can upload this to my documentation branch soon.
[image: Screen Shot 2023-01-20 at 13.40.19.png]
Em sex., 20 de jan. de 2023 Ã s 07:26, Max abonnements@revolwear.com escreveu:
Feature-creep! :)
On 20.01.23 01:08, Alexandre Torres Porres wrote:
Ok, here's a newly design [output~] abstraction. If there's only a mono input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function instead of db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the case it was off.
I kept the same control messages as the current [output~] object, a bang message is still there to mute/unmute. A 'level' message is also still there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button that visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value, set it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute toggle is still on :)
I then added two more messages for external control 'mute' and 'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really useful for day to day usage. See screenshot below and find the patch attached. Please give me feedback to see if I'm going in the right direction. If it is ok I will make a PR and update the documentation.
Screen Shot 2023-01-19 at 21.07.18.png
Cheers~
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
I use it all the time as well, but I'm not sure what you mean. You say you want the bang button instead of a toggle? You say you want me to keep the bang message into it to it changes the state of the toggle?
What I said is that I doubt people were using external controls via messages into the object to make me bother and keep the bang message.
what do you say?
cheers
Em sex., 20 de jan. de 2023 às 13:46, Miller Puckette msp@ucsd.edu escreveu:
Actually, personally I use the "mute" button all the time. Perhaps some people don't need it, but me, I often have 3 or 4 different output~ objects in a patch and want to turn them on and off selectively. (I also see sound engineers doing this all the time).
cheers Miller
On Fri, Jan 20, 2023 at 01:41:12PM -0300, Alexandre Torres Porres wrote:
So, I talked to MAX in private, he mentioned he'd expect a mute message
as
in "mute 0" / "mute 1". That makes sense. I was keeping the bang button
to
alter the state for backwards compatibility since the last one had a bang instead, but maybe I shouldn't bother with it as I doubt people were
using
any external controls at all with this, as I also think people will not
use
it much in the future. So I changed the mute message and removed the
bang
for the sake of simplicity and to make it less "feature-creep" :)
Find new version attached with a help file (see screenshot below as
well).
If no other objection is made I can upload this to my documentation
branch
soon.
[image: Screen Shot 2023-01-20 at 13.40.19.png]
Em sex., 20 de jan. de 2023 às 07:26, Max abonnements@revolwear.com escreveu:
Feature-creep! :)
On 20.01.23 01:08, Alexandre Torres Porres wrote:
Ok, here's a newly design [output~] abstraction. If there's only a
mono
input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function
instead of
db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the
case
it was off.
I kept the same control messages as the current [output~] object, a
bang
message is still there to mute/unmute. A 'level' message is also
still
there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button
that
visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value,
set
it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute
toggle
is still on :)
I then added two more messages for external control 'mute' and
'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really
useful
for day to day usage. See screenshot below and find the patch
attached.
Please give me feedback to see if I'm going in the right direction.
If
it is ok I will make a PR and update the documentation.
Screen Shot 2023-01-19 at 21.07.18.png
Cheers~
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Oh, I misunderstood the last mail. I do think the panel can just be a slider+number box (or just a number box) plus a "mute" button that toggles mute on and off. (That could be a graphical toggle instead of a bang if people find that more intuitive - I hadn't thought of that).
By the way, I'm coming around to your idea just to 'detect' when a second audio inlet is disconnected and switch the object into mono mode in that case - that's pretty smart :)
cheers Miller
On Fri, Jan 20, 2023 at 01:49:24PM -0300, Alexandre Torres Porres wrote:
I use it all the time as well, but I'm not sure what you mean. You say you want the bang button instead of a toggle? You say you want me to keep the bang message into it to it changes the state of the toggle?
What I said is that I doubt people were using external controls via messages into the object to make me bother and keep the bang message.
what do you say?
cheers
Em sex., 20 de jan. de 2023 Ã s 13:46, Miller Puckette msp@ucsd.edu escreveu:
Actually, personally I use the "mute" button all the time. Perhaps some people don't need it, but me, I often have 3 or 4 different output~ objects in a patch and want to turn them on and off selectively. (I also see sound engineers doing this all the time).
cheers Miller
On Fri, Jan 20, 2023 at 01:41:12PM -0300, Alexandre Torres Porres wrote:
So, I talked to MAX in private, he mentioned he'd expect a mute message
as
in "mute 0" / "mute 1". That makes sense. I was keeping the bang button
to
alter the state for backwards compatibility since the last one had a bang instead, but maybe I shouldn't bother with it as I doubt people were
using
any external controls at all with this, as I also think people will not
use
it much in the future. So I changed the mute message and removed the
bang
for the sake of simplicity and to make it less "feature-creep" :)
Find new version attached with a help file (see screenshot below as
well).
If no other objection is made I can upload this to my documentation
branch
soon.
[image: Screen Shot 2023-01-20 at 13.40.19.png]
Em sex., 20 de jan. de 2023 Ã s 07:26, Max abonnements@revolwear.com escreveu:
Feature-creep! :)
On 20.01.23 01:08, Alexandre Torres Porres wrote:
Ok, here's a newly design [output~] abstraction. If there's only a
mono
input on the left inlet (and nothing on the right inlet), the mono signal gets distributed to both outputs. That's something new!
I have a slider now and the control is now a quartic function
instead of
db as discussed. As originally, whenever we move the slider, the abstraction sends a 'pd dsp 1' message to turn the audio on in the
case
it was off.
I kept the same control messages as the current [output~] object, a
bang
message is still there to mute/unmute. A 'level' message is also
still
there to control the volume from an external control (but the input range is now from 0 to 1 and sets the slider).
Now, I decided to propose a whole new approach for the mute logic. It seems much more reasonable and simpler to just use a toggle button
that
visually shows us when it is muted or not. The patch is much simpler this way and there's no complicated logic to store the slider value,
set
it to zero when muted and restore to the previous value when unmuted. The slider keeps at the same position when muted, and if you move the slider when muted, no sound is output because... well.. the mute
toggle
is still on :)
I then added two more messages for external control 'mute' and
'unmute'.
This seems simple, better and is more versatile and seems like a good candidate for a new Vanilla [output~] abstraction that is really
useful
for day to day usage. See screenshot below and find the patch
attached.
Please give me feedback to see if I'm going in the right direction.
If
it is ok I will make a PR and update the documentation.
Screen Shot 2023-01-19 at 21.07.18.png
Cheers~
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Em sex., 20 de jan. de 2023 às 13:56, Miller Puckette msp@ucsd.edu escreveu:
I do think the panel can just be a slider+number box (or just a number box)
plus a "mute" button that toggles mute on and off.
Ok, added a number box, it's useful to see what the actual value is and you can also use it to type in a value (which also sets the slider above). Find patch attached and help file screenshot below.
[image: Screen Shot 2023-01-20 at 15.40.34.png]
Em sex., 20 de jan. de 2023 às 13:56, Miller Puckette msp@ucsd.edu escreveu:
By the way, I'm coming around to your idea just to 'detect' when a second
audio inlet is disconnected and switch the object into mono mode in that case - that's pretty smart :)
Thanks, I don't remember now if it was all me :) it was discussed if we could have yet another output in [inlet~] to show number of connections, but it ended up being something too specific. This is the only use case for me.
Now...... I already have created my first multi-channel aware external, one that detects the number of channels in a multi-channel signal connection. I found it useful for my [else/out~] abstraction, which now can detect if on the left inlet we have a multi-channel signal. If there's one, then I distribute the channels to both outputs :) if we're doing a check to see if there's a mono input, we could also do this now in the new [output~] object since the next version will support all this ;)
So maybe I can propose we add such an object into Vanilla. This same object could maybe also show if a signal is connected, so we can plug the outlet of [inlet~] into this new object and we wouldn't need the 'clever hack' and also get number of channels. This object could be called [sigstatus~] or something.
My object only detects number of channels and it is called [nhcs~]. Here it is in action inside my [out~] abstraction. I don't have other examples but I think this could be useful for other stuff, maybe other can think of more use cases.
[image: Screen Shot 2023-01-20 at 15.45.06.png]
And here's the code: https://github.com/porres/pd-else/blob/master/Classes/Source/nchs~.c
cheers
ok, here's a (maybe stupid) idea, currently, this object I designed gives you a channel number of "1" if nothing is connected to an inlet~, not sure if possible but maybe "sp[0]->s_nchans" could give us "0" if nothing is connected to an inlet~, so this object could be used to also detect inlet~ connection...
Em sex., 20 de jan. de 2023 às 15:51, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 20 de jan. de 2023 às 13:56, Miller Puckette msp@ucsd.edu
escreveu:
By the way, I'm coming around to your idea just to 'detect' when a second
audio inlet is disconnected and switch the object into mono mode in that case - that's pretty smart :)
Thanks, I don't remember now if it was all me :) it was discussed if we could have yet another output in [inlet~] to show number of connections, but it ended up being something too specific. This is the only use case for me.
Now...... I already have created my first multi-channel aware external, one that detects the number of channels in a multi-channel signal connection. I found it useful for my [else/out~] abstraction, which now can detect if on the left inlet we have a multi-channel signal. If there's one, then I distribute the channels to both outputs :) if we're doing a check to see if there's a mono input, we could also do this now in the new [output~] object since the next version will support all this ;)
So maybe I can propose we add such an object into Vanilla. This same object could maybe also show if a signal is connected, so we can plug the outlet of [inlet~] into this new object and we wouldn't need the 'clever hack' and also get number of channels. This object could be called [sigstatus~] or something.
My object only detects number of channels and it is called [nhcs~]. Here it is in action inside my [out~] abstraction. I don't have other examples but I think this could be useful for other stuff, maybe other can think of more use cases.
[image: Screen Shot 2023-01-20 at 15.45.06.png]
And here's the code: https://github.com/porres/pd-else/blob/master/Classes/Source/nchs~.c
cheers
Am 20. Jänner 2023 20:47:53 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
ok, here's a (maybe stupid) idea, currently, this object I designed gives you a channel number of "1" if nothing is connected to an inlet~, not sure if possible but maybe "sp[0]->s_nchans" could give us "0" if nothing is connected to an inlet~, so this object could be used to also detect inlet~ connection...
Which inlet~? I see that your use-case is centered around connecting this object directly to [inlet~], but in general this just will not be the case, so i think we should disentangle the two objects conceptually. I don't think we have a precedent of a "companion object" that is only auxiliary to another go one.
Or put otherwise: do we want to an object that tells us how many connections the [osc~] object that connects to it has?
If this doesn't really work (and personally I'm not convinced that it does), merging the functionality into [inlet~] itself might make more sense...
mfg.sfg.jfd IOhannes
Em sex., 20 de jan. de 2023 às 17:48, IOhannes m zmölnig zmoelnig@iem.at escreveu:
do we want to an object that tells us how many connections the [osc~] object that connects to it has?
Maybe not, I'm not sure. I just didn't want to discard it, but yeah, so far my need is to be aware of how many channels we have inside an abstraction (hence, via [inlet~]). Besides being able to distribute a stereo channel, I also found use inside [clone] to know how many channels there are there, so I can switch extra copies of!
If this doesn't really work (and personally I'm not convinced that it does), merging the functionality into [inlet~] itself might make more sense...
maybe, and also allowing to check if there's a signal connected to it at all.
mfg.sfg.jfd IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Time to follow through with this, I had proposed this new design taking other's input. As it all got quiet, I'm now uploading and updating it in my documentation branch.
cheers
Em sex., 20 de jan. de 2023 às 15:41, Alexandre Torres Porres < porres@gmail.com> escreveu:
added a number box, it's useful to see what the actual value is and you can also use it to type in a value (which also sets the slider above). Find patch attached and help file screenshot below.
[image: Screen Shot 2023-01-20 at 15.40.34.png]
But I think I see what you mean, and maybe Purr Data has implemented something similar. They have this [ab] object. For reference: "*The [ab] object is accompanied by a number of supplemental objects (abinfo, abdefs, abclone) which let you inspect and clone private abstractions. There’s also an “Abstractions” dialog which can be accessed via the Window menu. This will give you a quick overview of the private abstractions contained in a patch. Also, it will show you private abstractions which aren’t currently being used (i.e., don’t have any instances), so that you can select and then delete them if they aren’t needed any more*." (from https://agraef.github.io/purr-data-intro/Purr-Data-Intro.pdf )
Yeah, that was a Google summer of code project I mentored two years ago or so. It would be great if it or something like it could propagate upstream to vanilla. It's been long enough now that I don't remember a lot about the code, but we worked really hard on it to make it work sanely with other stuff. One reason we didn't extend this feature to regular pd subpatches was that it turned out to be really useful to maintain a distinction between encapsulation types with global $0 locality on one hand and local $0 on the other.
-
Alexandre Torres Porres -
Dan Wilcox -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Matt Barber -
Max -
Miller Puckette