Hello. I'm working on a composition project that uses probability (markov chains) approach + more stuff.
I was trying to build a 'generic' object that would consist of 3 tables (arrays actually) which hold (pitch #, velocity #, duration #).
Suppose I name this object (patch) 'pattern'
Now, when I create new project (new pd patch), I can insert the newly created object using the 'pattern p1' 'pattern p2' etc technique.
To make sure that the table names in each 'pattern' instantiated do not conflict, I used the $1 technique as part of array names. ($1-pitch, $1-velocity etc). Now, when I set up all the 'patterns' and play things work fine.
Problem is, how to store what I did set up, esp. taking into consideration that there may be 15 patterns instantiated.
I attempted to write to files the contents of arrays using the message object, however, when I reference $1-pitch.txt inside a message box (as a filename I wish to write to), there's a problem. $1 no longer pertains to the name I gave to the 'paattern', it pertains to the message context itself (I'm not exactly sure to what).
Is there a way to get around this context issue? How to pass the the message box the name of patch this message box resides in?
I'm trying to build a generic object that I may reuse. Of course, quick fix is to make all array names distinct numerically (array1 array2 etc) - however - in a long term, that solution is not very professional (headache).
thanx for suggestions Regards Jarek
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
- Albert Einstein
On Sun, 18 Aug 2002 22:28:02 -0400 (EDT) JaReK myszewsk@cse.Buffalo.EDU wrote:
I attempted to write to files the contents of arrays using the message object, however, when I reference $1-pitch.txt inside a message box (as a filename I wish to write to), there's a problem. $1 no longer pertains to the name I gave to the 'paattern', it pertains to the message context itself (I'm not exactly sure to what).
Is there a way to get around this context issue? How to pass the the message box the name of patch this message box resides in?
see attachments.
HTH.
JaReK hat gesagt: // JaReK wrote:
I attempted to write to files the contents of arrays using the message object, however, when I reference $1-pitch.txt inside a message box (as a filename I wish to write to), there's a problem. $1 no longer pertains to the name I gave to the 'paattern', it pertains to the message context itself (I'm not exactly sure to what).
$dollars in messages and $dollars in objects inside of an abstraction (pattern.pd) are two different things. $1,$2,$3.. in a message always get the values of incoming messages.
[Hi Jarek( ---> [$2 $1(---> [print] prints Jarek Hi
The solution is to store the abstractions argument in a float or symbol object and send this one to the write message.
Frank Barknecht _ ______footils.org__
On Mon, 19 Aug 2002 09:00:22 +0200 Frank Barknecht barknech@ph-cip.uni-koeln.de wrote:
$dollars in messages and $dollars in objects inside of an abstraction (pattern.pd) are two different things. $1,$2,$3.. in a message always get the values of incoming messages.
This is a long-term question but... seeing that this has tripped up several of us, would it make sense to come up with a different notation for one or the other? Could it be done in a way that wouldn't break legacy scripts?
I suppose only Miller can decide this, but it might be worth considering.
I think it might be unwise... The "$" meanings in objects and messages are actually the same; the text is simply interpeted in different contexts.
I explain this sketchily in the "14.dollarsigns.pd" tutorial in 2.control.examples -- but perhaps should belabor it some more...
cheers Miller
On Mon, Aug 19, 2002 at 12:48:29AM -0700, Joseph Zitt wrote:
On Mon, 19 Aug 2002 09:00:22 +0200 Frank Barknecht barknech@ph-cip.uni-koeln.de wrote:
$dollars in messages and $dollars in objects inside of an abstraction (pattern.pd) are two different things. $1,$2,$3.. in a message always get the values of incoming messages.
This is a long-term question but... seeing that this has tripped up several of us, would it make sense to come up with a different notation for one or the other? Could it be done in a way that wouldn't break legacy scripts?
I suppose only Miller can decide this, but it might be worth considering.
-- | josephzitt@josephzitt.com http://www.josephzitt.com/ | | http://www.metatronpress.com/jzitt/ http://www.mp3.com/josephzitt/ | | == New book: Surprise Me with Beauty: the Music of Human Systems == | | Comma / Gray Code Silence: the John Cage Discussion List |
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Mon, 19 Aug 2002 09:43:29 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
I think it might be unwise... The "$" meanings in objects and messages are actually the same; the text is simply interpeted in different contexts.
Well, I think what we may be hitting here is the frequent gap between programmer and end-user perceptions. By saying that they "are actually the same", I suspect that you're coming from seeing that they share the same code (I'm not sure, not being quite able to interpret the code itself). However, from the viewpoint of someone using the program without knowledge of the innards of the source, they are quite different and behave quite differently. I believe I've seen this issue come up a few times; in such cases, I've found that changing the documentation tends to be less effective than enhancing the interface.
What would you suggest as an alternative to $1 in object boxes? $1 works the same as in MAX for messages, what does MAX use in object boxes?
I'm happy about how it works now, and not really in the mood to change all my patches! ;)
Ben
On Mon, 19 Aug 2002, Joseph Zitt wrote:
On Mon, 19 Aug 2002 09:43:29 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
I think it might be unwise... The "$" meanings in objects and messages are actually the same; the text is simply interpeted in different contexts.
Well, I think what we may be hitting here is the frequent gap between programmer and end-user perceptions. By saying that they "are actually the same", I suspect that you're coming from seeing that they share the same code (I'm not sure, not being quite able to interpret the code itself). However, from the viewpoint of someone using the program without knowledge of the innards of the source, they are quite different and behave quite differently. I believe I've seen this issue come up a few times; in such cases, I've found that changing the documentation tends to be less effective than enhancing the interface.
-- | josephzitt@josephzitt.com http://www.josephzitt.com/ | | http://www.metatronpress.com/jzitt/ http://www.mp3.com/josephzitt/ | | == New book: Surprise Me with Beauty: the Music of Human Systems == | | Comma / Gray Code Silence: the John Cage Discussion List |
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
yeah, its really just another arbitrary aspect of a programming language (remember folks, pd is a programming language, not fruity loops or cakewalk :)
other examples of weird rules you just have to read up on and memorize:
so while it took me quite a while to get comforable with $1's, it does make a certain sense. programming is a bitch :)
now, i think the notation could be changed to reflect arguments to the parent patch and arguments to the object, but it would break compatability across _all_ pd, max and jmax patches ever made... kind of a high cost :)
-josh
Ben Bogart - FMPM/F1999 wrote:
What would you suggest as an alternative to $1 in object boxes? $1 works the same as in MAX for messages, what does MAX use in object boxes?
I'm happy about how it works now, and not really in the mood to change all my patches! ;)
Ben
On Mon, 19 Aug 2002, Joseph Zitt wrote:
On Mon, 19 Aug 2002 09:43:29 -0700 Miller Puckette mpuckett@man104-1.ucsd.edu wrote:
I think it might be unwise... The "$" meanings in objects and messages are actually the same; the text is simply interpeted in different contexts.
Well, I think what we may be hitting here is the frequent gap between programmer and end-user perceptions. By saying that they "are actually the same", I suspect that you're coming from seeing that they share the same code (I'm not sure, not being quite able to interpret the code itself). However, from the viewpoint of someone using the program without knowledge of the innards of the source, they are quite different and behave quite differently. I believe I've seen this issue come up a few times; in such cases, I've found that changing the documentation tends to be less effective than enhancing the interface.
-- | josephzitt@josephzitt.com http://www.josephzitt.com/ | | http://www.metatronpress.com/jzitt/ http://www.mp3.com/josephzitt/ | | == New book: Surprise Me with Beauty: the Music of Human Systems == | | Comma / Gray Code Silence: the John Cage Discussion List |
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
B. Bogart
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
While we're on the topic of the semantics and uses of dollar signs
in Pd...
I'm always surprised whenever I try to create a subpatch (not
abstraction) with dollar-signs and arguments and it doesn't work. Is there a reason that dollar-sign creation variables don't work with subpatches?
. . David McCallum . Queen's University Electronic Music Studio Manager . and Noise Maker . http://mentalfloss.ca/sintheta/ .
I'm always surprised whenever I try to create a subpatch (not
abstraction) with dollar-signs and arguments and it doesn't work. Is there a reason that dollar-sign creation variables don't work with subpatches?
I don't know what's the philosophy behind that, but it's just the same in Max/MSP. A subpatcher gets the same arguments as it's parent abstraction. I'd also like to have arguments for subpatchers, though... among many other things....
greetings, T
David N G McCallum hat gesagt: // David N G McCallum wrote:
While we're on the topic of the semantics and uses of dollar signs in Pd...
I'm always surprised whenever I try to create a subpatch (not abstraction) with dollar-signs and arguments and it doesn't work. Is there a reason that dollar-sign creation variables don't work with subpatches?
As I see it, subpatches are an almost full blown part of the surrounding patch. A subpatch is like a curtain that hides part of a room, but someone standing on the other side of the curtain still is in the same room as you and the two can talk.
Frank Barknecht _ ______footils.org__
Does Max behave this way as well?
I think this method probably works fine if the parent patch is an
abstraction where creation aguments have been specified. But if the parent isn't an abstraction then there are no arguments for the subpatch to take. So it would be nice in this case to specify subpatch arguments on creation of the subpatch.
The reason that I bring this all up is that if I want to do
repetitive tasks in a patch without using external abstractions I would just like to create a subpatch that I can copy/paste with different arguments.
But, actually, if there are more elegant ways to go about this
then I'm all ears. :)
. . David McCallum . Queen's University Electronic Music Studio Manager . and Noise Maker . http://mentalfloss.ca/sintheta/ .
On Tue, 20 Aug 2002, Frank Barknecht wrote:
As I see it, subpatches are an almost full blown part of the surrounding patch. A subpatch is like a curtain that hides part of a room, but someone standing on the other side of the curtain still is in the same room as you and the two can talk.
Hi, David N G McCallum hat gesagt: // David N G McCallum wrote:
The reason that I bring this all up is that if I want to do repetitive tasks in a patch without using external abstractions I would just like to create a subpatch that I can copy/paste with different arguments.
In my view, to copy/paste with different arguments is a case for an abstraction. Subpatches are there to hide things and to share the sends and receives of the surrounding patch even when using $0-named sends. I rely on this fact quite often.
Especially with regard to the $0-variables subpatches are invaluable the way they are. $0 is mostly used for local variables, sends and receives. They are not seen in an abstraction, that has its own $0, but they are seen in a subpatch. Also the $1, $2, ... variables of a surrounding patch are seen in the subpatch right away, but they don't mess around in an abstraction, that keeps its own set of $1, $2, ...
There are usages for both and I'm glad, that subpatches and abstractions are different in this regard. Where I want to send local in a patch but still want to reach hidden receives, I use a subpatch, and where I don't want this I use an abstraction.
Instead of changing the subpatch behaviour I would much rather like all sends and receives to be local, because almost all my s and r names start with $0-...
What about this?
Frank Barknecht _ ______footils.org__