[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

[Jonathan Wilkes]

--- On Wed, 12/15/10, Mathieu Bouchard <matju at artengine.ca> wrote:

> From: Mathieu Bouchard <matju at artengine.ca>
> Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
> To: "João Pais" <jmmmpais at googlemail.com>
> Cc: pd-list at iem.at
> Date: Wednesday, December 15, 2010, 1:11 AM
> On Sun, 28 Nov 2010, João Pais
> wrote:
> 
> > I had a small look at [#many]. Do you think it would
> be better to use C-coded objects instead for this kind of
> "complex" gop abstractions?
> 
> Well, you see, Pd *has* to grow more means to solve
> problems using abstractions, so, I'm making the bet that I
> can solve this problem with abstractions. I don't know
> whether it'd really take less time with C code, and if I
> did, I wouldn't end up with more means to solve problems
> using abstractions. (I wrote small externals to support
> [#many]).
> 
> What makes you think that it would be better ?
> 
> > I use lots of abstractions with gop (from my library,
> specially [m-i] for midi input), and it seems to me that at
> some point I have so many abstractions, that my patches take
> longer to load. But I didn't do a real test to prove this.
> 
> It seems that Pd on Windows takes several times more time
> instantiating abstractions than on Linux and OSX, especially
> with a full-blown path of 40 folders or so. This could be
> mostly fixed if Claude's abstraction-cache had been included
> in Pd, which can dramatically speed up abstraction-loading
> on all platforms, but probably especially on Windows (but I
> didn't check).

Is this patch on the tracker?  I can't find it.

> 
> But this does not especially affect [#many], I'd guess. It
> would be a lot worse if [#many]'s elements could be
> abstractions, which is a planned feature. Then if you used a
> gop-abstraction name as the first arg of [#many], you'd
> trigger an insane number of lookups.
> 
> This might be mitigated by specifying the absolute path to
> the abstraction when instantiating. This wouldn't be a bad
> idea to have an external that can lookup that, because as it
> is, [#many foo 16 16] can't see foo.pd in the folder of the
> patch that has [#many foo 16 16] in it, and that's more than
> annoying, so, this issue has to be tackled anyway.
> 
> But apart from that... can you find any abstraction
> instances inside of [#many] ? I don't see any... so, it
> shouldn't be much longer to load.
> 
> GridFlow's three big abstractions are [doc_h] (9k), [#many]
> (10k), and [#camera] (12.5k), and among them, [#many] is the
> only to not load any other abstractions.
> 
> 
> _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ----
> Villeray, Montréal, QC
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Pd-list at iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>