[PD-dev] poly library
Hans-Christoph Steiner
hans at eds.org
Mon Nov 17 05:46:24 CET 2008
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20081116/5135cce0/attachment.htm>
More information about the Pd-dev
mailing list