[PD] suggestion... or question

[IOhannes m zmoelnig]

Federico wrote:
> zmoelnig at iem.at wrote:
> 
>> Zitat von Federico <xaero at inwind.it>:
>>
>>> hello list,
>>> I'm wondering if there is the need of a new object in pd....
>>>
>> ...
>>
>>
>> i usually deal with this problem by using send/receive instead of
>> patch cords.
>> i seldomly experience problems with the order of execution when
>> dealing with many instances of an object (they tend to work in
>> parallel and not interfere with each other - at least not where
>> execution order is a problem).
>>
>> you can interact with each object separately either via special
>> receive-names ("$1_my_param" where $1==1..N) or via special messages
>> to a "global" (could be localized with $0) receiver and the use of
>> [route] (msg "$1 <parm>" to "my_param" and then do a [route $1])) 
> 
> 
> uhm...
> you mean that [apart creating gui objects, and renaming their
> send/receive symbols], receiving their values it's just a
> message/route/send work?!? no additional patching would be required?
> (i.e. expanding number of sliders from 128 to 512 would not affect the
> logic code, but only copying and pasting and renaming 512 sliders?)

i only described how I deal with multiple instances of objects without
getting into too much connection fiddling.
i am not saying that it works "out of the box".

however, i daresay that a lot of patches as you describe would involve
to only a copy'n'paste of your 512 sliders and 512 instances of logic.
(matju, that was for you)

> 
> 
> however my point wasn't only this...
> more generally i would say: repetition of objects, groups, or instances,
> is a common pattern in pd. and there are certain ways to do it (select,
> route, multiple inlets, and so on), but all of them require a lot of
> patching (proportional to the number of instances you want).

i cannot follow you here. i think that you can do most of this tasks
with a constant(!) patching overhead instead of an overhead proportional
to the number of instances.
however, the overhead might be big and sub-optimal.

> why souldn't exists an object which does this for you?

i haven't said that it would be a bad idea. i just tried to explain my
workarounds.

and the reason is most likely: time, money, and more important things to
do :-)



mfg.asdr.
IOhannes