[PD] pd-msg

[Mike McGonagle]

On 4/25/08, Luigi Rensinghoff <luigi.rensinghoff at freenet.de> wrote:
>  Well...
>
> not yet...but if you post the patch, or the part with th 200 or more
> wires...

Well, it is still something in "development". I would need to rework
it to use [nqpoly4], as that would be my alternative to doing it
programmatically.

> 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..

Well, actually, you don't need to worry about the $0 & $1, as those
are handled by [nqpoly4]. All you need do is instatiate an [nqpoly4]
with your object, and the number of instances (and a few more
things...) and that Abstraction handles everything else.

You should check out the patch, it is very instructional.

> 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..

at the same time, the first time you patch up 100 objects into a
patch, you get some sort of sense of accomplishment... but not so much
on the 2nd or 3rd... That is when things like [nqpoly4] are REAL NICE.

> 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...

Well, one of the things that you could find in [nqpoly4] is how to do
this. I attached a VERY SIMPLISTIC example of what I think you are
looking for...

thepatch.pd is the main patch to open. Inside that, it creates another
abstraction (which is where you might "wrap" the mapping stuff) called
'testing'. The arguments to that are the name of the "mapping"
abstraction you want to use. You would also need to include any
parameters to that particular mapping object you want to use.
>
> 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

Well, if you are looking to change the subpatch on the fly with a
message, I don't think that is possible. You could possibly expand on
[nqpoly4] and when you send it this message, it would destroy
everything that was previously created, and then recreate the new
subpatch you are looking for. But I wouldn't count on any "realtime"
performance, depending on how many objects you are creating.

Again, my example is VERY SIMPLISTIC, and doesn't do anything other
than show how to create a sub-patch within another patch.

Mike

> ......................
>
> 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
>
>
>
>
>


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simple.zip
Type: application/zip
Size: 634 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080425/d30d99d7/attachment.zip>