could you add an example? i am not sure how you try to open the file:
- via the file->open menu?
- via a message?
- as abstraction?
- ...?
what is the expected behaviour in the light of the extended $arg-expansion?
(e.g is it related to the [parent$0] problem? there won't be a solution for this until we there is an escaping mechanism)
i am not sure i can reproduce any problem with the attached file on 0.40-1: it downloads as "array" (without extension), so i had to rename it to array.pd; but i guess this has exactly undone the problem you described.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
so this time to concentrate on objects with "$0" in them, e.g. [parent$0] or [array-with-$0]
these do not load anymore on recent versions of pd, since the $0 is expanded at runtime, therefore pd is in fact looking for an object e.g. [parent1004] (which it cannot find).
i do not see any solution for this, unless you do not want in-symbol expansion of $args (which i think we all agreed is a good thing to have).
obviously one could make a special rule for $0 in object names (this is: the 0th argument of an object box; all other arguments should be treated "normally"); but i do think that this is counterproductive ($args are complicated to understand anyhow; adding exception rules will make things only worse)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you move the $0 in the filename to the front of the filename like $0-file.pd, then no version of Pd I know of can open them from the menu, including pd-extended. All Pd-versions open the file using the command line quite okay, but even then saving the file still doesn't work.
Ths isn't restricted to $0, the same also happens for other dollar-variables like $1-file.pd.
Maybe the more interesting question is: How should Pd deal with these filenames? $1 for example is treated as a variable in object names, that is replaced by the abstraction argument. If I use an abstraction [$1-file] then in fact I'm trying to load a file depending on the value of $1 in Pd-space, for example "0-file.pd". To be able to actually use the dollar in the object name, we'd need a more general escaping mechanism which would allow using an abstraction with an escaped dollar sign, for example [\$1-file]. This however is a much bigger problem to solve in a smart (or in a stupid) way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The original example file should be called "array with $0.pd".
As for how to handle these, I don't think we should do anything special for abstractions, they can be left as is, otherwise it'll induce confusion, IMHO. I am just thinking that people's patches might have something like "this patch earned me $2.pd" and they would like to be able to open it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=564396
Originator: NO
could you add an example? i am not sure how you try to open the file:
- via the file->open menu?
- via a message?
- as abstraction?
- ...?
what is the expected behaviour in the light of the extended $arg-expansion?
(e.g is it related to the [parent$0] problem? there won't be a solution for this until we there is an escaping mechanism)
i am not sure i can reproduce any problem with the attached file on 0.40-1: it downloads as "array" (without extension), so i had to rename it to array.pd; but i guess this has exactly undone the problem you described.
Logged In: YES
user_id=564396
Originator: NO
so this time to concentrate on objects with "$0" in them, e.g. [parent$0] or [array-with-$0]
these do not load anymore on recent versions of pd, since the $0 is expanded at runtime, therefore pd is in fact looking for an object e.g. [parent1004] (which it cannot find).
i do not see any solution for this, unless you do not want in-symbol expansion of $args (which i think we all agreed is a good thing to have).
obviously one could make a special rule for $0 in object names (this is: the 0th argument of an object box; all other arguments should be treated "normally"); but i do think that this is counterproductive ($args are complicated to understand anyhow; adding exception rules will make things only worse)
Logged In: YES
user_id=569446
Originator: NO
If you move the $0 in the filename to the front of the filename like $0-file.pd, then no version of Pd I know of can open them from the menu, including pd-extended. All Pd-versions open the file using the command line quite okay, but even then saving the file still doesn't work.
Ths isn't restricted to $0, the same also happens for other dollar-variables like $1-file.pd.
Maybe the more interesting question is: How should Pd deal with these filenames? $1 for example is treated as a variable in object names, that is replaced by the abstraction argument. If I use an abstraction [$1-file] then in fact I'm trying to load a file depending on the value of $1 in Pd-space, for example "0-file.pd". To be able to actually use the dollar in the object name, we'd need a more general escaping mechanism which would allow using an abstraction with an escaped dollar sign, for example [\$1-file]. This however is a much bigger problem to solve in a smart (or in a stupid) way.
Logged In: YES
user_id=27104
Originator: YES
The original example file should be called "array with $0.pd".
As for how to handle these, I don't think we should do anything special for abstractions, they can be left as is, otherwise it'll induce confusion, IMHO. I am just thinking that people's patches might have something like "this patch earned me $2.pd" and they would like to be able to open it.