[PD] local arrays again...

[Michal Seta]

On 8/15/01 5:50 PM, "Yves Degoyon" <degoyon at 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