[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Mathieu Bouchard
matju at artengine.ca
Wed Dec 15 01:11:46 CET 2010
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).
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
More information about the Pd-list
mailing list