[PD] some macro ideas

[Mathieu Bouchard]

On Tue, 3 Oct 2006, Frank Barknecht wrote:

> To those who program with text based languages: subpatches are code
> blocks, they are the "{...}" in Perl or C or the indented blocks in
> Python.

Yes; however, not all code blocks map to subpatches: most just map to 
patterns of wires.

> Abstractions however are functions. They are the "func" in the "int 
> func(arg){}" of C or in the "def func(arg):..." of Python.

They're more like objects, because they have state that survive the 
handling of a message; and because they have instances. (Some functions 
called "closures" have both of those characteristics, but they don't exist 
in C/C++ nor Python)

> IMO one should not try to dumb down a "func(arg)" into a "{}" at all.

BTW, in several popular languages, the "{}" do introduce closures: in Perl 
(only when preceded by "sub"), and in Ruby (in all cases). I'm not sure 
about SuperCollider but I'd assume that it's mostly as in Ruby.

> We would probably need to create a way to declare and define an embedded 
> abstraction in one place of the patch, maybe using a subpatch-like 
> object [def myEmbeddedAbstraction args]

I suggested [class myEmbeddedAbstraction] in the previous mail. The "args" 
part is unneeded for the reason that all normal info about args is already 
inside of that abstraction.

> But I guess that this is as tricky to implement as the [import] object 
> that was discussed recently on pd-dev. But maybe it isn't.

two words: multiple objectmakers. This simplifies both problems into just 
one problem by inserting an intermediate between the imports and the 
"physical representation" of the involved patches. Ok, it doesn't make it 
"just one problem" (depending on the way you look at it), but it's still 
simpler overall.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada