Patches item #1403917, was opened at 2006-01-12 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: bind abtraction-canvas to full classname
Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd";
however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd"
this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd")
the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar"
caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows.
what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917...
is this of any use to anybody?
if so i would like it very much in the upcoming release... (it shouldn't break anything, but you never know)
mfg.asd.f IOhannes
SourceForge.net wrote:
Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd";
however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd"
this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd")
the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar"
caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows.
what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name.
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
This is funny, I used a workaround in PixelTANGO to get around this, striping the file path so that the abstractions can be created properly from the directory listing.
Of course I'd have to update my patches after this change, but I guess it would also be needed if I decided to search for my abstractions in multiple directories.
.b..
IOhannes m zmoelnig wrote:
is this of any use to anybody?
if so i would like it very much in the upcoming release... (it shouldn't break anything, but you never know)
mfg.asd.f IOhannes
SourceForge.net wrote:
Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd";
however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd"
this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd")
the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar"
caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows.
what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name.
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1403917...
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
B. Bogart wrote:
This is funny, I used a workaround in PixelTANGO to get around this, striping the file path so that the abstractions can be created properly from the directory listing.
i am not sure whether this is the problem i addressed with the patch. it is really just about the receive-name of the canvas attached to the abstraction. this is: you still can _not_ create an abstraction [foo/bar.pd] but now you can send "vis 1" to "pd-foo/bar" (and "pd-pizza/bar")
(or do i totally misunderstand your workaround)
Of course I'd have to update my patches after this change, but I guess it would also be needed if I decided to search for my abstractions in multiple directories.
i don't think you would have to change anything. it really should be an added feature (without interfering with anything)
but then i don't know enough about pixelTANGO
mfg.asdr. IOhannes
Yes! This is another step towards a fully functional namespace. I fully support this work. I am not sure about the .pd suffix issue. Isn't that the distinction between subpatches' and abstractions' receive symbols? I don't know if it matters tho.
.hc
On Jan 12, 2006, at 9:32 AM, IOhannes m zmoelnig wrote:
is this of any use to anybody?
if so i would like it very much in the upcoming release... (it shouldn't break anything, but you never know)
mfg.asd.f IOhannes
SourceForge.net wrote:
Initial Comment: each abstraction-canvas is bound to a receive-symbol, based on the abstraction name, which enables you to send special messages to the canvas (like "vis 1") e.g. [foo] will be bound to "pd-foo.pd"; however, when the abstraction is created with a path-name, this is not reflected. e.g. [foo/bar] will be bound to "pd-bar.pd" this is unfortunate if you are using multiple abstractions of the same name within different directories, like [foo/bar] and [task/bar] (both will listen to "pd-bar.pd") the attached patch will modify g_canvas.c and m_class.c to additionally bind the abstraction's canvas to the full classname of the abstraction, with "pd-" prepended in the given example this means, that [foo/bar] will be bound to "pd-foo/bar" and [task/bar] will be bound to "pd-task/bar" caveat: no ".pd" is suffixed, since the full classname does not hold any file-suffixes. i do not consider this too bad, but who knows. what for?: i need this for a general framework where people can write their own modules that will be saved within a directory; the entry-point to each module is an abstraction with the same name.
You can respond by visiting: https://sourceforge.net/tracker/? func=detail&atid=478072&aid=1403917&group_id=55736 _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
Hans-Christoph Steiner wrote:
fully support this work. I am not sure about the .pd suffix issue. Isn't that the distinction between subpatches' and abstractions'
yes, that's the main problem is see (or at least: this is the point where i expect problems if there are any)
receive symbols? I don't know if it matters tho.
so that is why i was asking ;-)
mfga.sdr. IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
fully support this work. I am not sure about the .pd suffix issue. Isn't that the distinction between subpatches' and abstractions'
yes, that's the main problem is see (or at least: this is the point where i expect problems if there are any)
Hm, it indeed might become a problem. I'm already very careful with subpatch names and protect them with $0 wherever possible from becoming an unintended target, because I use data structures and thus "pd-x" receivers a lot (including the "clear" message of course), also in abstractions where I cannot see the subpatch's name immediatly.
As abstractions cannot use $0 in their name, they cannot be protected this way. I guess I would prefer to keep the .pd in the receiver because of this. I probably will never be extra careful with sending "clear" to something ending in ".pd".
Or am I misunderstanding your change?
Ciao
Frank Barknecht wrote:
Hallo,
Hm, it indeed might become a problem. I'm already very careful with subpatch names and protect them with $0 wherever possible from becoming an unintended target, because I use data structures and thus "pd-x" receivers a lot (including the "clear" message of course), also in abstractions where I cannot see the subpatch's name immediatly.
As abstractions cannot use $0 in their name, they cannot be protected this way. I guess I would prefer to keep the .pd in the receiver because of this. I probably will never be extra careful with sending "clear" to something ending in ".pd".
Or am I misunderstanding your change?
no i fear you are quite right. i guess there really should be a separation between subpatches (esp. with data-structures) and abstractions. the main point why i didn't do it was, because i did not want to generate _another_ symbol (when loading an abstraction [foo/bar] pd automatically generates the symbols "foo/bar", "bar.pd", and "/path/to/my/foo") but probably there is no way around.
btw, does foo.pat bind to "pd-foo.pat"? (i think so).
mfg.adr IOhannes
IOhannes m zmoelnig wrote:
but probably there is no way around.
so i have re-submitted a patch to the patch-tracker. the new version now appends ".pd" to the receiver-name (using the pd-function addfileextent() which i just stumbled across and which seems to do what i need)
so now [foo/bar] will bind to "pd-foo/bar.pd" (and for compatibility to "pd-bar.pd".
currently ".pd" is always suffixed (regardless of the actual file-extension). probably this could be done in a cleaner (more complicated) way, that respects the actual file-extension.
so this should fix most concerns.
the new patch is called "bind2classname.pd.diff" and i deleted the old one (which, btw, contained leftovers like m_class.c~...)
mfg.adsr. IOhannes
On Jan 13, 2006, at 4:17 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
but probably there is no way around.
so i have re-submitted a patch to the patch-tracker. the new version now appends ".pd" to the receiver-name (using the pd-function addfileextent() which i just stumbled across and which seems to do what i need)
so now [foo/bar] will bind to "pd-foo/bar.pd" (and for compatibility to "pd-bar.pd".
I am glad the .pd issue worked out easily.
I just thought of one thing. The "pd-bar.pd" compatibility binding for [foo/bar] might not be the best thing to have. If you had [foo/bar] and [bar], you would not be able to insure that you are independently sending messages to [bar] with the symbol "pd-bar.pd" since both [foo/bar] and [bar] would listen to pd-bar.pd.
I vote for clean implementation over backwards compatibility. (it is still pd 0.* 8-)
.hc
currently ".pd" is always suffixed (regardless of the actual file-extension). probably this could be done in a cleaner (more complicated) way, that respects the actual file-extension.
so this should fix most concerns.
the new patch is called "bind2classname.pd.diff" and i deleted the old one (which, btw, contained leftovers like m_class.c~...)
mfg.adsr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
I am glad the .pd issue worked out easily.
I just thought of one thing. The "pd-bar.pd" compatibility binding for [foo/bar] might not be the best thing to have. If you had [foo/bar] and [bar], you would not be able to insure that you are independently sending messages to [bar] with the symbol "pd-bar.pd" since both [foo/bar] and [bar] would listen to pd-bar.pd.
I vote for clean implementation over backwards compatibility. (it is still pd 0.* 8-)
i totally agree
(however, i didn't dare to do it)
i have added a note to the sf-tracker, so that whenever miller (or someone else) considers incorporating the patch, they should give the compatibility issue a quick thought. removing the compatibility binding is mainly deleting 2 consecutive lines (and modifying the 3rd), so it is fairly simple.
mfg.asdr IOhannes
Does this happen for all receives for abstractions or only ones which also contain the relative pathname?
Will this break old patches that communicate with a subpatch?
[pd array]
[vis 1< | [s pd-array]
Now I can't remember if its abstractions or subpatches that require the .pd extension... I guess they should be all consistant.
,b,
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
but probably there is no way around.
so i have re-submitted a patch to the patch-tracker. the new version now appends ".pd" to the receiver-name (using the pd-function addfileextent() which i just stumbled across and which seems to do what i need)
so now [foo/bar] will bind to "pd-foo/bar.pd" (and for compatibility to "pd-bar.pd".
currently ".pd" is always suffixed (regardless of the actual file-extension). probably this could be done in a cleaner (more complicated) way, that respects the actual file-extension.
so this should fix most concerns.
the new patch is called "bind2classname.pd.diff" and i deleted the old one (which, btw, contained leftovers like m_class.c~...)
mfg.adsr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
B. Bogart wrote:
Does this happen for all receives for abstractions or only ones which also contain the relative pathname?
Will this break old patches that communicate with a subpatch?
[pd array]
[vis 1< | [s pd-array]
no, this will stay untouched.
Now I can't remember if its abstractions or subpatches that require the .pd extension... I guess they should be all consistant.
abstractions require the .pd extension. with the 2nd patch i submitted a ".pd" is appended to the canvas-receiver of an _abstraction_. the "new" (currently: additional, but see the other mails on this topic) canvas-receiver consists of the classname (== relative-pathname + filename). there is no check whether the classname (how you call the object) contains a relative (or even absolute) pathname.
it would be nice if you could just test your patches with a patched version of pd.
fm.asdr IOhannes
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
abstractions require the .pd extension. with the 2nd patch i submitted a ".pd" is appended to the canvas-receiver of an _abstraction_. the "new" (currently: additional, but see the other mails on this topic) canvas-receiver consists of the classname (== relative-pathname + filename). there is no check whether the classname (how you call the object) contains a relative (or even absolute) pathname.
What's the use of being able to contact one (and only one) instance of an abstraction via a receive-symbol?
How do I know which instance I am contacting?
And then, why is [namecanvas] marked as obsolete?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
abstractions require the .pd extension. with the 2nd patch i submitted a ".pd" is appended to the canvas-receiver of an _abstraction_. the "new" (currently: additional, but see the other mails on this topic) canvas-receiver consists of the classname (== relative-pathname + filename). there is no check whether the classname (how you call the object) contains a relative (or even absolute) pathname.
What's the use of being able to contact one (and only one) instance of an abstraction via a receive-symbol?
do i guess this is a rhetoric question? btw, my patch does not contact one (and only one) _instance_ of an abstraction, but _all_ instances.
How do I know which instance I am contacting?
you don't. that is the nature of send. you do not know who is listening. (but of course you know that)
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
mfg.asdr. IOhannes
Hmmm,
I've tended to create dynamic arrays of abstractions using [constructor] which used to be part of pmpd...
Anyhow each abstraction gets an instance # when its being generated, and then I have a
[r local] | [route $1] | | local global
So that each abstraction only responds to messages with its ID prepended.
I never used namecanvas...
,b,
IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
abstractions require the .pd extension. with the 2nd patch i submitted a ".pd" is appended to the canvas-receiver of an _abstraction_. the "new" (currently: additional, but see the other mails on this topic) canvas-receiver consists of the classname (== relative-pathname + filename). there is no check whether the classname (how you call the object) contains a relative (or even absolute) pathname.
What's the use of being able to contact one (and only one) instance of an abstraction via a receive-symbol?
do i guess this is a rhetoric question? btw, my patch does not contact one (and only one) _instance_ of an abstraction, but _all_ instances.
How do I know which instance I am contacting?
you don't. that is the nature of send. you do not know who is listening. (but of course you know that)
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
mfg.asdr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
because the most likely use would be to send 'clear' and then to start adding stuff to make a dynamic patch of some sort... but oops, 'clear' deletes the namecanvas, which then probably will crash Pd. A safe mechanism is needed...
cheers Miller
mfg.asdr. IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Miller Puckette wrote:
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
because the most likely use would be to send 'clear' and then to start adding stuff to make a dynamic patch of some sort... but oops, 'clear' deletes the namecanvas, which then probably will crash Pd. A safe mechanism is needed...
good point.
maybe it would be a good idea, to be able to name a canvas via properties?
mfg.a.sdr IOhannes
This might be a good thing to add to the properties menu, but some mechanism is also needed to do it programmatically. For example, an abstraction might want to name itself and then send messages to inform other part of the patch of the name.
Perhaps this should be part of a larger "declaration" mechanism that would also allow patches to specify search paths and other startup needs. ISPW Max had a "declare" object so you could write "declare path=lib:../lib" to add to the search path. Somthing like that is also needed in Pd.
cheers Miller
On Sat, Jan 14, 2006 at 07:57:44PM +0100, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
because the most likely use would be to send 'clear' and then to start adding stuff to make a dynamic patch of some sort... but oops, 'clear' deletes the namecanvas, which then probably will crash Pd. A safe mechanism is needed...
good point.
maybe it would be a good idea, to be able to name a canvas via properties?
mfg.a.sdr IOhannes
Miller Puckette wrote:
This might be a good thing to add to the properties menu, but some mechanism is also needed to do it programmatically. For example, an abstraction might want to name itself and then send messages to inform other part of the patch of the name.
Perhaps this should be part of a larger "declaration" mechanism that would also allow patches to specify search paths and other startup needs. ISPW Max had a "declare" object so you could write "declare path=lib:../lib" to add to the search path. Somthing like that is also needed in Pd.
hmm, but using an object ([declare]) has the same problems as using another object ([namecanvas]).
probably it would be better to really store data (canvasname, paths,...,settings) in the "properties" of the canvas, AND make an object to talk to this properties. this could be an object [canvas] it would have one inlet to send messages like [vis 1( or [name $0-canvas( to ourselves (the canvas we are in). it would have one outlet, so we can get all messages sent to the canvas (no matter what its name may be)
the good thing would be, that the object would not hold the data by itself (nor give the user the illusion to do so). so if the canvas would be renamed to "idontplayguitar" (via a message to [canvas]) and then you would delete the [canvas] object, the canvas would still be called "idontplayguitar" (just like when you are deleting a [send] object, you do not undo all messages already sent through it).
btw, i even think it better to have an inlet (like the one in [canvas] to talk to a canvas than a send-name. this would (hopefully) demystify much of the magic that is currently done with "dynamic" patching (i put the "dynamic" in quotes, since i am talking more about "vis 1" than "clear").
what do you think?
mf.as.dr IOhannes
On Jan 15, 2006, at 4:18 AM, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
This might be a good thing to add to the properties menu, but some mechanism is also needed to do it programmatically. For example, an abstraction might want to name itself and then send messages to inform other part of the patch of the name. Perhaps this should be part of a larger "declaration" mechanism that would also allow patches to specify search paths and other startup needs. ISPW Max had a "declare" object so you could write "declare path=lib:../lib" to add to the search path. Somthing like that is also needed in Pd.
hmm, but using an object ([declare]) has the same problems as using another object ([namecanvas]).
probably it would be better to really store data (canvasname, paths,...,settings) in the "properties" of the canvas, AND make an object to talk to this properties. this could be an object [canvas] it would have one inlet to send messages like [vis 1( or [name $0-canvas( to ourselves (the canvas we are in). it would have one outlet, so we can get all messages sent to the canvas (no matter what its name may be)
the good thing would be, that the object would not hold the data by itself (nor give the user the illusion to do so). so if the canvas would be renamed to "idontplayguitar" (via a message to [canvas]) and then you would delete the [canvas] object, the canvas would still be called "idontplayguitar" (just like when you are deleting a [send] object, you do not undo all messages already sent through it).
btw, i even think it better to have an inlet (like the one in [canvas] to talk to a canvas than a send-name. this would (hopefully) demystify much of the magic that is currently done with "dynamic" patching (i put the "dynamic" in quotes, since i am talking more about "vis 1" than "clear").
So it seems between canvas names and namespace declarations/lib path need to be some kind of patch meta data which is able to be controlled from patch space and the properties panel.
Perhaps this meta data can be stored in as part of the patch itself and stored in the .pd file with the addition of a #N meta line. Then this data could be viewed and edited from the patch's properties panel, and objects like [namecanvas], [declare], [import]/[using] would be able to manipulate this data as well.
In this situation, the meta data object would have an inlet to set the data, and an outlet to fetch the data. This could be done with a [meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
.hc
________________________________________________________________________ ____
Hans-Christoph Steiner wrote:
So it seems between canvas names and namespace declarations/lib path need to be some kind of patch meta data which is able to be controlled from patch space and the properties panel.
Perhaps this meta data can be stored in as part of the patch itself and stored in the .pd file with the addition of a #N meta line. Then this data could be viewed and edited from the patch's properties panel, and objects like [namecanvas], [declare], [import]/[using] would be able to manipulate this data as well.
In this situation, the meta data object would have an inlet to set the data, and an outlet to fetch the data. This could be done with a
that's what i was trying to explain, though i was calling it [canvas] instead of [meta].
[meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
hmm, well; i don't see clearly how this should work. the [meta] in an abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while you intend it to refer to the parent's meta-data. so we would need something like a macro! - no we better not...
mfg..fwer IOhannes
On Jan 15, 2006, at 12:09 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So it seems between canvas names and namespace declarations/lib path need to be some kind of patch meta data which is able to be controlled from patch space and the properties panel. Perhaps this meta data can be stored in as part of the patch itself and stored in the .pd file with the addition of a #N meta line. Then this data could be viewed and edited from the patch's properties panel, and objects like [namecanvas], [declare], [import]/[using] would be able to manipulate this data as well. In this situation, the meta data object would have an inlet to set the data, and an outlet to fetch the data. This could be done with a
that's what i was trying to explain, though i was calling it [canvas] instead of [meta].
Ah ok. I think that [meta] is a clearer distinction since we are talking about meta data for a patch, not necessarily data relating to just the canvas. I see it more as meta data to the patch, with #N canvas also being a kind of meta data for the patch, specifying the display size of the window and whether its visible or not. It doesn't entirely makes sense to me to have the #N canvas represent the patch.
Plus, [canvas] would be easily confused with controlling [cnv] data.
[meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
hmm, well; i don't see clearly how this should work. the [meta] in an abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while you intend it to refer to the parent's meta-data. so we would need something like a macro! - no we better not...
To solve this, the classname and the instance ID could be optional arguments to [meta]. Then [meta] could be used from any patch to control the meta data for any patch. The default behavior for [meta] with no arguments would then be to control the current patch.
I am not entirely sure about instance ID. That would only be needed if there was instance-specific meta data, which currently there is not.
.hc
________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
... and this is close to the same spirit as the 'declare' idea:
Ah ok. I think that [meta] is a clearer distinction since we are talking about meta data for a patch, not necessarily data relating to just the canvas. I see it more as meta data to the patch, with #N canvas also being a kind of meta data for the patch, specifying the display size of the window and whether its visible or not. It doesn't entirely makes sense to me to have the #N canvas represent the patch.
.hc
Hans-Christoph Steiner wrote:
Plus, [canvas] would be easily confused with controlling [cnv] data.
i am pretty sure, that whenever miller will implement something like this, it will be called neither [canvas] not [meta], though it might still have some logic...idle reasoning...
[meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
hmm, well; i don't see clearly how this should work. the [meta] in an abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while you intend it to refer to the parent's meta-data. so we would need something like a macro! - no we better not...
To solve this, the classname and the instance ID could be optional arguments to [meta]. Then [meta] could be used from any patch to control the meta data for any patch. The default behavior for [meta] with no arguments would then be to control the current patch.
but only if we _knew_ classname (simple) and instanceID (hard) beforehand.
I am not entirely sure about instance ID. That would only be needed if there was instance-specific meta data, which currently there is not.
well, for me instance ID is something like $0 currently is. (it doesn't matter whether my ID is uniq just within the class or across the whole session). --and i guess $0 has proven to be useful and indispensable to access...-- oops, seems like i am mixing the access to meta-data (setting the canvas-receiver) with the meta-data itself (the canvas' receivename). however, if you want to set the canvas receiver to (e.g.) "$0-subpatch" you either need proper escaping (in order to literally set "$0-subpatch") or you are in trouble (setting all receivers to "1009-subpatch" is rather coarse...) (i have to) read frank's mail on this
mfg.gtre IOhannes
Well, it's not safe either to set the name of a canvas, nor would it work to set its search path, after it has been instantiated. Even 'loadbang time' is too late... so the mechanism has to be somehow outside the regular functionality of a patch. The old 'declare' object did this, by inserting in the saved patch some 'declarations' which afected the environment in which the patch was loaded. A patch that contained a "declare path=lib" object would actually save as:
#N canvas 282 166 521 402 10; #X declare path=lib; #X obj 10 10 abstraction-in-the-library ...; #X obj 20 20 declare path=lib; ...
in other words, the declare object is created in teh usual "obj" way (line 4) but would magically insert a _message_ "declare" to go to the canvas before creating anything (line 2).
It's not ideal because changing the "declare" object would not take effect until the next time the patch was loaded. Perhaps changing a "declare" should automatically provoke a reload in th esame way that saving an abstraction does...
cheers Miller
On Sun, Jan 15, 2006 at 06:09:05PM +0100, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So it seems between canvas names and namespace declarations/lib path need to be some kind of patch meta data which is able to be controlled from patch space and the properties panel.
Perhaps this meta data can be stored in as part of the patch itself and stored in the .pd file with the addition of a #N meta line. Then this data could be viewed and edited from the patch's properties panel, and objects like [namecanvas], [declare], [import]/[using] would be able to manipulate this data as well.
In this situation, the meta data object would have an inlet to set the data, and an outlet to fetch the data. This could be done with a
that's what i was trying to explain, though i was calling it [canvas] instead of [meta].
[meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
hmm, well; i don't see clearly how this should work. the [meta] in an abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while you intend it to refer to the parent's meta-data. so we would need something like a macro! - no we better not...
mfg..fwer IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I was just thinking about this, I think that the object controlling the meta data is a bit weird. I think that it would make more sense to be able to query the classname itself to set and get the meta data. This would be analogous to how you communicate with pd itself. The instance meta data doesn't currently exist and it'd be hard to do, so I say we can deal with that when it comes up.
All of this meta data would also be viewable and editable in the Properties panel. The receiver and classpath should be changable without a patch reload, since [namecanvas] can already change the meta "receive" name and [import], [using], and the Path preferences panel can change the path without a reload.
In addition to the properties panel, the meta data could be set with a message:
[;pd-mypatch.pd set classpath cyclone maxlib oscx zexy( [;pd-mypatch.pd set receive myname(
And retrieved with a message:
[;pd-mypatch.pd get classpath( [;pd-mypatch.pd get receive(
This would require some way of receiving the data. It wouldn't be essential, but it might come in handy. I don't have a clear idea of how best to do this. Maybe it could also be another meta type, you set a meta "send" name, then you can receive the messages. There could be a default, like "pd-meta". Like this:
[;pd-mypatch.pd set send mypatch-( [;pd-mypatch.pd get send(
The meta data could be stored like declare, then it would exist outside of the object loading order. It could then be stored in the file like this:
#N canvas 12 42 234 235 1; #X meta classpath cyclone maxlib oscx zexy; #X meta receive myname; #X meta send my-patch-meta; #X obj osc~; etc....
.hc
On Jan 15, 2006, at 12:38 PM, Miller Puckette wrote:
Well, it's not safe either to set the name of a canvas, nor would it work to set its search path, after it has been instantiated. Even 'loadbang time' is too late... so the mechanism has to be somehow outside the regular functionality of a patch. The old 'declare' object did this, by inserting in the saved patch some 'declarations' which afected the environment in which the patch was loaded. A patch that contained a "declare path=lib" object would actually save as:
#N canvas 282 166 521 402 10; #X declare path=lib; #X obj 10 10 abstraction-in-the-library ...; #X obj 20 20 declare path=lib; ...
in other words, the declare object is created in teh usual "obj" way (line 4) but would magically insert a _message_ "declare" to go to the canvas before creating anything (line 2).
It's not ideal because changing the "declare" object would not take effect until the next time the patch was loaded. Perhaps changing a "declare" should automatically provoke a reload in th esame way that saving an abstraction does...
cheers Miller
On Sun, Jan 15, 2006 at 06:09:05PM +0100, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So it seems between canvas names and namespace declarations/lib path need to be some kind of patch meta data which is able to be controlled from patch space and the properties panel.
Perhaps this meta data can be stored in as part of the patch itself and stored in the .pd file with the addition of a #N meta line. Then this data could be viewed and edited from the patch's properties panel, and objects like [namecanvas], [declare], [import]/[using] would be able to manipulate this data as well.
In this situation, the meta data object would have an inlet to set the data, and an outlet to fetch the data. This could be done with a
that's what i was trying to explain, though i was calling it [canvas] instead of [meta].
[meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
hmm, well; i don't see clearly how this should work. the [meta] in an abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while you intend it to refer to the parent's meta-data. so we would need something like a macro! - no we better not...
mfg..fwer IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
Hans-Christoph Steiner wrote:
I was just thinking about this, I think that the object controlling the meta data is a bit weird. I think that it would make more sense to be able to query the classname itself to set and get the meta data. This
...
yes, that's where the concepts of my [canvas] and your [meta] start to differ. probably my assumption that they are equivalent was wrong: [meta] aims to interface the class, while [canvas] should interface the instance.
they probably got confused, because in pd you usually modify the class via an instance: you create an abstraction (== instance of the class) and modify it and save it; only then the class will be changed.
[meta] (or rather your replacement) would act on all instances of a class simultaneously. i fear that this is very different from how pd usually deals with such things (which does not necessarily mean that it is worse)
mfg.asdr. IOhannes
On Sun, 15 Jan 2006, IOhannes m zmoelnig wrote:
hmm, well; i don't see clearly how this should work. the [meta] in an abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while you intend it to refer to the parent's meta-data. so we would need something like a macro! - no we better not...
if you have tcl man pages, try this:
man uplevel
and then transpose this concept to the nesting of abstraction-instances.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 14 Jan 2006, Miller Puckette wrote:
because the most likely use would be to send 'clear' and then to start adding stuff to make a dynamic patch of some sort... but oops, 'clear' deletes the namecanvas, which then probably will crash Pd. A safe mechanism is needed...
Wow. Why would it crash Pd ??? I don't understand. Because [namecanvas] is angry at being deleted and so decides to kill(getpid(),SIGSEGV) ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 14, 2006, at 1:02 PM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
abstractions require the .pd extension. with the 2nd patch i submitted a ".pd" is appended to the canvas-receiver of an _abstraction_. the "new" (currently: additional, but see the other mails on this topic) canvas-receiver consists of the classname (== relative-pathname + filename). there is no check whether the classname (how you call the object) contains a relative (or even absolute) pathname.
What's the use of being able to contact one (and only one) instance of an abstraction via a receive-symbol?
do i guess this is a rhetoric question? btw, my patch does not contact one (and only one) _instance_ of an abstraction, but _all_ instances.
How do I know which instance I am contacting?
you don't. that is the nature of send. you do not know who is listening. (but of course you know that)
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
Funny these two came in the same email. I was wondering what [namecanvas] provides beyond the automatically declared canvas-receiver. [namecanvas] would allow you to easily send messages to instances of an abstraction using [namecanvas $0-canvas]. Then you have to track $0 for each instance so you know what's what.
That's enough of a reason to keep [namecanvas] around.
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
On Sat, 14 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 14, 2006, at 1:02 PM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
How do I know which instance I am contacting?
you don't. that is the nature of send. you do not know who is listening. (but of course you know that)
And then, why is [namecanvas] marked as obsolete?
well, i keep asking this question since several years. (since i first discovered that [namecanvas] is marked obsolete.
Funny these two came in the same email.
It's not "funny", it's called "deliberate" and "on purpose".
[namecanvas] would allow you to easily send messages to instances of an abstraction using [namecanvas $0-canvas]. Then you have to track $0 for each instance so you know what's what. That's enough of a reason to keep [namecanvas] around.
Exactly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote: What's the use of being able to contact one (and only one) instance of an abstraction via a receive-symbol?
do i guess this is a rhetoric question? btw, my patch does not contact one (and only one) _instance_ of an abstraction, but _all_ instances.
D'oh. I wasn't awake yet. You are right.
But what are practical applications for that receive-symbol ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Sat, 14 Jan 2006, IOhannes m zmoelnig wrote: What's the use of being able to contact one (and only one) instance of an abstraction via a receive-symbol?
do i guess this is a rhetoric question? btw, my patch does not contact one (and only one) _instance_ of an abstraction, but _all_ instances.
D'oh. I wasn't awake yet. You are right.
But what are practical applications for that receive-symbol ?
For example [vis 1( ? That would actually be a possible usecase for addressing one and only one instance.
Ciao
-
B. Bogart -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
SourceForge.net