On 8/14/01 12:38 PM, "Yves Degoyon*" ydegoyon@audientia.com wrote:
Well, hello, hope you had your third coffee now because I think Nicolas meant making a table with a $1 in its name
( I know Nicolas a little bit ).
Unfortunately I left the house after only one coffee.... Don't ask about the consequences....
On 8/14/01 6:08 PM, "Yves Degoyon" degoyon@freesurf.fr wrote:
Hi, Miller,
I tried to follow your instructions but although the names correctly expands when used as variables in tabwrite~, tabread~,... they don't expand when referring to the array name itself, e.g. var expands to "1001-bigsample" but array name expands to "0-bigsample" although what's written in the patdh is
X array $0-bigsample 100 float 1;
it wouldn't work with :
X array $0-bigsample 100 float 1;
which really means "$0-bigsample", o' course.
Any hint ??
Yeah. I tested your patches... I think this works if you create the array inside the table object: [table $0-bigsample] (it didn't work for me as well when creating simply an array named $0-bigsample).
The tabwrite~ objects inside that patch need to have $0-bigsample argument as well.
Attached is a solution to your problem (note that I added adc~ for testing). Lemme know if it works...
Also, in this case you don't need to add arguments your abstractions as your arrays get named automatically.
However, I don't know of a way of supplying creation arguments to messages (is there a way???) so your message will not work as you expected. Therefore, AFAIK, the bang to the [openpanel] will not work as expected (in fact, when I was playing with this pd has returned an error saying "inlet: no method for symbol". I moved the openpanel into the abstraction (I did that while replying to the message so this change is not in the attachment, should I have included it?) and then it worked when sending bang into the inlet). So my suggestion is to make an argument $1-bigsample where you supply an argument and everything gets named after that argument (you gave an argument anyways...) and you can use that little trick with symbol->makefilename to make sure the message gets sent properly. If there's a more elegant way of doing this I'd be interested in it.
./MiS
"To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "Just do it!" - NIKE "It" - Stephen King
On 8/15/01 12:44 AM, "Michal Seta" mis@music.mcgill.ca wrote: [snip]
I moved the openpanel into the abstraction (I did that while replying to the message so this change is not in the attachment, should I have included it?) and then it worked when sending bang into the
[snip]
In fact I have included the whole solution....
Michal Seta wrote:
Attached is a solution to your problem (note that I added adc~ for testing). Lemme know if it works...
What you did works fine, thanks a lot !!!
Also, in this case you don't need to add arguments your abstractions as your arrays get named automatically.
However, I don't know of a way of supplying creation arguments to messages (is there a way???) so your message will not work as you expected. Therefore, AFAIK, the bang to the [openpanel] will not work as expected (in fact, when I was playing with this pd has returned an error saying "inlet: no method for symbol". I moved the openpanel into the abstraction (I did that while replying to the message so this change is not in the attachment, should I have included it?) and then it worked when sending bang into the inlet). So my suggestion is to make an argument $1-bigsample where you supply an argument and everything gets named after that argument (you gave an argument anyways...) and you can use that little trick with symbol->makefilename to make sure the message gets sent properly. If there's a more elegant way of doing this I'd be interested in it.
Still, 2 features are surprising to me :
a/
building patch = build objects + expand their arguments
not : expand (objects+arguments) + build them
rem : this would be a too severe patch.
b/
$n means :
"nth patch argument in an object" "nth run-time incoming value in a message"
this would be clearer to me if creation arguments would be referred as "$$n" or "£n", but this would break a lot of patches, right ??
So, keep things this way.
Thanks for your very fast reply.
Regards,
Yves Degoyon.
On 8/15/01 5:50 PM, "Yves Degoyon" degoyon@freesurf.fr wrote:
Still, 2 features are surprising to me :
a/
building patch = build objects + expand their arguments
not : expand (objects+arguments) + build them
rem : this would be a too severe patch.
Sorry but I don't understand what you mean.... I will take a stab at it anyways and you tell me if I'm going in the right direction:
It is a good habit, in OOP, to reuse classes/objects. PD is like an OOP environment. Like in OOP you can take existing objects and build new objects out of them (abstractions). Now, some objects don't require any creation arguments and you can feed them messages or floats or whatever to change parameters when you need them. Other objects (like tabwrite~ and tabread~ in you example) need arguments. If you're building an abstraction it's because you intend to reuse it at some point and perhaps even you will several copies of it in the same patch (program). Things like tables (arrays) and objects referring to them need unique names so by putting a variable name you ensure that by providing a unique name to each INSTANCE of your abstraction they will not get confused. So objects contained within your abstraction INHERIT the arguments (is this what you mean by "expanding" arguments?).
You will also want to use variable args in patches where you want control the creation args of objects contained within. But if you're, say, building a reverb and you have tested all parameters of delays and filters and you know what you want you can simply give them the tested parameters and, optionally, provide a way of tweeking it in real time. And that can be done through inlets and float boxes, but that's too simple :) ... And too silly, in fact. I find it efficient to communicate with my abstractions through send-receive pairs so I end up giving my receives within abstractions variable arguments so I can specify later which instance I am sending data to.
Am I making any sense?
But all this depends on what you're doing. You can put stuff into subpatches and not worry about $n crap. For some things I don't even bother making abstractions. But I do like reuse some ideas and some things I use more than once in the same patch and that's when it's worth to put it into a separate file and deal with it on that level.
Now I'm lost...
b/
$n means :
"nth patch argument in an object" "nth run-time incoming value in a message"
this would be clearer to me if creation arguments would be referred as "$$n" or "£n", but this would break a lot of patches, right ??
I like to think of $n as a variable... I can understand your confusion if you come from Max background where arguments and variables in messages are different. But I like the simplicity of PD in this domain (if only a variable name within an abstraction the message could also inherit the creation argument...). So a variable is a variable regardless of where you put/find it. Just keep in mind that creation arguments are inherited only by objects contained within your abstraction (which in turn is an object, too) and not the messages.
Hope this helps a bit.
./MiS
"To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "Just do it!" - NIKE "It" - Stephen King
-
Michal Seta -
Yves Degoyon