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 <[EMAIL PROTECTED]> 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@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@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
>---------------------------------------<
Luigi Rensinghoff
[EMAIL PROTECTED]
skype:gigischinke
ichat:gigicarlo
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
