[PD-dev] poly library

[Hans-Christoph Steiner]

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>