[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