I just thought of one more advantage of not using a wrap patch: when you modify an instance, the dirty flag gets set on the nqpoly patch rather than all of the nqpwrap instances.  This is a huge advantage for debugging.

.hc

On Nov 16, 2008, at 5:19 PM, Hans-Christoph Steiner wrote:


On Nov 16, 2008, at 4:17 PM, Frank Barknecht wrote:

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

I didn't think of changing the behavior by using different wrappers,
that makes sense.  I guess with nqpoly4 vs polypoly the main
difference in the wrapper.  I think there are a couple advantages to
not using a wrapper:

- makes it easier and more transparent to find instances when
debugging, [$1 $2 $3 $4 $5 $6 $7 $8 $9] is a strange construct to see

Yep, that's true, but OTOH a wrapper is just a Pd patch, which is much easier
to change than a dynamic patching construct. That has to be taken into
account when it comes to longer-term maintainability. Generally less dynamic
patching is better.

I used to think that, but some recent improvements have made dynamic patching much easier.  First, your idea of using a subpatch and send/receives is super helpful.  Also, the settable send makes things much easier to follow.  Building on your work, I think I've managed to get these polys to be pretty simple and straightforward.  They could even fit all on one patch without subpatches.

- it should make it much easier to make the *poly objectclass behave
like a normal objectclass, with one file being in extra, but usable
anywhere.  This would require [ggee/getdir], but it should be pretty
straightforward from there.

You mean getdir for finding the objects to instantiate? Maybe you can
elaborate this a bit... The big problem of all *polys so far is that
it's hard for them to finde the objects to instantiate. At first I had
hoped that your solution of omitting the wrapper would be an easy fix,
but in my tests it showed the same issue.

Yes, I am thinking of using [getdir] to get the path of the parent patch, then adding that path to the *poly's subpatch using [declare].

.hc

I am not a fan of huge routes, unless they are being dynamically
generated.  It makes some really nice line drawings when you have 30
or more instances :)

Yep, it looks really cool. ;)

Is there any real difference in efficiency  between one big route and
many small ones?

I don't think so. I'd guess that small ones are a tiny bit less
efficient because of the additional inlets, but I wouldn't care about
this.

Ciao
-- 
Frank

_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev



----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.  It's about as sensible to say we declare war on night attacks and expect we're going to win that war.  We're not going to win the war on terrorism.        - retired U.S. Army general, William Odom









----------------------------------------------------------------------------

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.  It's about as sensible to say we declare war on night attacks and expect we're going to win that war.  We're not going to win the war on terrorism.        - retired U.S. Army general, William Odom