Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
In Pd-l2ork, you can do [filename(---[canvasinfo].
But I'm still working on that interface. For example, itgives you the name without the extension ".pd". But maybe it should include that extention, too.
In Pd-extended, I'm not sure how to do that. There's [iemguts/canvasname], but it doesn't give return anything for a toplevel patch.
-Jonathan
On Monday, March 3, 2014 9:11 AM, Kaj Ailomaa zequence@mousike.me wrote:
Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hello,
On 03/03/14 21:55, Kaj Ailomaa wrote:
Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch].
Cheers,
Chris.
On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:
Hello,
On 03/03/14 21:55, Kaj Ailomaa wrote:
Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch].
Thanks, but this won't work for me, as the name has to be the actual patch name.
I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch.
The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way.
I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem.
On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:
On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:
Hello,
On 03/03/14 21:55, Kaj Ailomaa wrote:
Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch].
Thanks, but this won't work for me, as the name has to be the actual patch name.
I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch.
The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way.
I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem.
Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
...and [patch_name] external (again pd-l2ork only) that outputs the filepath out of the left outlet and the patch filename out of the right outlet. On Mar 4, 2014 12:47 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:
On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:
Hello,
On 03/03/14 21:55, Kaj Ailomaa wrote:
Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch].
Thanks, but this won't work for me, as the name has to be the actual
patch name.
I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch.
The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way.
I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem.
Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 03/04/2014 01:15 PM, Ivica Bukvic wrote:
...and [patch_name] external (again pd-l2ork only) that outputs the filepath out of the left outlet and the patch filename out of the right outlet.
There's also
[patchname $1( | [duplicate_effort]
Just fill $1 with the name of the object you want to create, and [duplicate_effort] will automatically compile another class with that name and with the functionality you want.
Currently [duplicate_effort] supports the following methods:
patchname dollarargs abs~ pow~ bandlimited_grabbag arraysize mousecoords count string duplicate_effort
Each class created is guaranteed to be unique so you can use it to create private keys. You can also give it an extra float argument to specify help patch quality. (All values default to zero.)
To download a copy, start a repo in github and code up another version of it.
-Jonathan
On Mar 4, 2014 12:47 PM, "Jonathan Wilkes" <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
On 03/04/2014 03:00 AM, Kaj Ailomaa wrote: On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote: Hello, On 03/03/14 21:55, Kaj Ailomaa wrote: Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this? I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch]. Thanks, but this won't work for me, as the name has to be the actual patch name. I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch. The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way. I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem. Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork. -Jonathan _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Except that in this case patch_name precedes canvasinfo... On Mar 4, 2014 3:01 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 03/04/2014 01:15 PM, Ivica Bukvic wrote:
...and [patch_name] external (again pd-l2ork only) that outputs the filepath out of the left outlet and the patch filename out of the right outlet.
There's also
[patchname $1( | [duplicate_effort]
Just fill $1 with the name of the object you want to create, and [duplicate_effort] will automatically compile another class with that name and with the functionality you want.
Currently [duplicate_effort] supports the following methods:
patchname dollarargs abs~ pow~ bandlimited_grabbag arraysize mousecoords count string duplicate_effort
Each class created is guaranteed to be unique so you can use it to create private keys. You can also give it an extra float argument to specify help patch quality. (All values default to zero.)
To download a copy, start a repo in github and code up another version of it.
-Jonathan
On Mar 4, 2014 12:47 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:
On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:
Hello,
On 03/03/14 21:55, Kaj Ailomaa wrote:
Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this?
I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch].
Thanks, but this won't work for me, as the name has to be the actual
patch name.
I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch.
The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way.
I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem.
Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
But it also precedes the search-plugin.
-Jonathan
On Tuesday, March 4, 2014 3:59 PM, Ivica Bukvic ico@vt.edu wrote:
Except that in this case patch_name precedes canvasinfo... On Mar 4, 2014 3:01 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 03/04/2014 01:15 PM, Ivica Bukvic wrote:
...and [patch_name] external (again pd-l2ork only) that outputs the filepath out of the left outlet and the patch filename out of the right outlet. There's also
[patchname $1( | [duplicate_effort]
Just fill $1 with the name of the object you want to create, and
[duplicate_effort] will automatically compile another class with
that name and with the functionality you want.
Currently [duplicate_effort] supports the following methods:
patchname dollarargs abs~ pow~ bandlimited_grabbag arraysize mousecoords count string duplicate_effort
Each class created is guaranteed to be unique so you can use it to
create private keys. You can also give it an extra float argument
to specify help patch quality. (All values default to zero.)
To download a copy, start a repo in github and code up another
version of it.
-Jonathan
On Mar 4, 2014 12:47 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
On 03/04/2014 03:00 AM, Kaj Ailomaa wrote:
On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote:
Hello,
On 03/03/14 21:55, Kaj Ailomaa wrote:
Hi. I've been googling a bit and looking through the library of objects
that comes with pd-extended, but can't seem to find a
way to get the
name of the patch from within the patch. Anyone know of
a nice method to
do this?
I would use [namecanvas] for this. For example you could have an object
like [namecanvas $0-mypatch] and then you can send
messages to the patch
using e.g. [s $0-mypatch].
Thanks, but this won't work for me, as the name has to be the actual
patch name.
I've understood that there might be a fix in the svn version
of
[canvasname], apart of iemguts, which would allow getting
the name of
the top level patch.
The reason I had for this is I wanted to have uniquely named
patches
that have a common save mechanism, which looks up the
savefile based on
the unique patch name. I was always going to create these uniquely named patches in
another top
level patch, so I can get around this problems by adding an
argument for
the patch, which is the same as the patchname, and let the
save
mechanism look up the filename that way.
I initially would have wanted the uniquely named patch to be
able to be
opened as is, but that's not a major problem.
Currently I think the only way to do this is
[filename(---[canvasinfo], which is only in Pd-l2ork.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
Ivica Bukvic -
Jonathan Wilkes -
Kaj Ailomaa