[PD] pd-msg

Luigi Rensinghoff luigi.rensinghoff at freenet.de
Sat Apr 26 00:57:46 CEST 2008


Well...

not yet...but if you post the patch, or the part with th 200 or more  
wires...

i would test the difference.

I am surprised where this discussion is going...many useful tips so far.

I personally dont like that $0 $1 confusion somehow, but thats just  
because i dont remeber what i did when i open
the patch many months later or so..

Wires are somehow more "haptic" and its a part of pd that i like,  
sort of the typical pd-character, but
as in the 24 24 matrix thing - when you have to do more than 100  
connections in one patch, then its kind of silly, this weaving
so dynamic object creation or just "automated" connecting seems to be  
a good way..

To come to a little bit more practical example..

I am facing the problem - again with the mapping library - and this  
is, where it does not work with abstractions - i would like to have one
abstraction with a mapping object inside, but not always the same...

i post the example, later - where i am now experimenting with this  
message-thing

basically its like that..

lets say you have an abstraction:

transfer.pd

inside of that there is the core-math object like

exponential_curve or exponential_sigmoid

so it would be cool to just send the argument "expoential_curve" to  
the abstraction so this object is created..

well...not very clear i guess..

but i will post it later
......................

What about the

route audio~ float  - object ....

did nobody ever have the same problem ??

good night luigi



Am 26.04.2008 um 00:06 schrieb Mike McGonagle:

> Just curious, but has anyone tried to test the performance differences
> between sending messages as compared to actually connecting things up
> with wires?
>
> I am curious weather or not one of my patches would work with
> messages, as I want to instantiate close to 200 oscillators, with each
> taking about 7 or 8 parameters per grain.
>
> Mike
>
>
> On 4/25/08, Roman Haefeli <reduzierer at yahoo.de> wrote:
>> On Fri, 2008-04-25 at 20:09 +0200, Frank Barknecht wrote:
>>> Hallo,
>>> Mike McGonagle hat gesagt: // Mike McGonagle wrote:
>>>
>>>> And yes, while this is possible, it just seems very "difficult"  
>>>> at best, to
>>>> be able to create a patch and lay it out in such a way that you  
>>>> can make
>>>> those sorts of selections. LOTS of planning would need to go  
>>>> into such a
>>>> thing.
>>>
>>> What I generally do *if* I'm doing dynamic patching is write as  
>>> much as
>>> possible into an abstraction and just create copies of that.  
>>> nqpoly4~
>>> may help with automating that.
>>>
>>> A very useful trick for these abstractions is to avoid doing  
>>> connections
>>> at all and just pass $0 as an argument. Then inside the  
>>> abstraction, use
>>> [r $1-inlet] receivers where $1 is the $0 of the parent as passed as
>>> argument instead of inlets, and [s $1-outlet] instead of outlets.  
>>> Outside of
>>> the patch use [s $0-inlet] to write to the fake inlet, and [r $0- 
>>> outlet]
>>> to read from the fake sender outlet. Do the same for signals with  
>>> r~/s~
>>> and throw~/catch~ pairs. Most dynamic connections can be avoided  
>>> by this
>>> approach.
>>>
>>> If you need to pass data from one dynamically created abstraction to
>>> another, use a similar approach with numbered arguments. Again  
>>> this can
>>> be seen in action in the redesign of nqpoly4~.pd that I once did and
>>> that's in svn/pd-extended as well, or in polypoly.pd.
>>
>>
>>
>> this is basically the approach, that probably all dynamic patches  
>> from
>>  netpd are based on. no connections are created or deleted  
>> dynamically
>>  (it's just too cumbersome and relies on undocumented features).
>>  parts that need to be deleted separately go into their own  
>> subpatch, so
>>  that they can be deleted simply by sending 'clear' to the  
>> appropriate
>>  subpatch.
>>
>>  however, there _are_ issues, that cannot solved that way. whenever
>>  signals are involved with dynamically created abstractions, it's  
>> likely
>>  to get one-block-delays due to the creation order of the
>>  [throw~]s/[catch~]es and [send~]s/[receive~]s. don't know how to  
>> deal
>>  with that yet.
>>
>>
>>  roman
>>
>>
>>
>>
>>  ___________________________________________________________
>>  Telefonate ohne weitere Kosten vom PC zum PC: http:// 
>> messenger.yahoo.de
>>
>>
>>
>>  _______________________________________________
>>  PD-list at iem.at mailing list
>>  UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>
>
>
> -- 
> Peace may sound simple—one beautiful word— but it requires everything
> we have, every quality, every strength, every dream, every high ideal.
> —Yehudi Menuhin (1916–1999), musician
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list
>

 >---------------------------------------<

Luigi Rensinghoff
luigi.rensinghoff at freenet.de
skype:gigischinke
ichat:gigicarlo




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080426/b74396b2/attachment.htm>


More information about the Pd-list mailing list