I suspect Mathieu may have the right idea about the wraparound, but I'll have to do more testing to be sure. Because of the scale of things, I can't eyeball the exact problem and will probably need to make a separate patch to clarify the problem.
'many' lib looks interesting for simplifying abstraction creation with common inputs. I'm not quite getting if it's relevant to deleting the abstractions, which is more pertinent to accurately keeping track of visual canvas location. In my current situation, it's no critical to delete them individually; I have a separate creation/deletion patch where I delete individual abstractions, but it's dealing with smaller amounts and I use [poly] to maintain low value graphical dimensions.
It occurred to me that graph on parent with a very small visual representation (like a small square) would help optimize/reduce the canvas size needed and make x/y dimensions consistant. This is similar to how I've dealt with keeping track of and deleting scalars in the past. I'm not sure if this treatment of graph on parent would produce its own problems; has anyone used it for this purpose?
Is there any intrinsic problem with leaving things like [soundfiler] and tables in dynamically created abstractions when they only create/run on startup and are not deleted. Of course it's kind of clunky if it occurred in the middle of operation; however, I was under the impression that [soundfiler] or anything involving array resize will cause issues if run in the middle of audio. Even though it's working on startup, I can't see any benefit to my way other than it being simpler to make initially.
Thanks, -Stephen
On Tue, Nov 15, 2011 at 10:50 AM, Hans-Christoph Steiner hans@at.or.atwrote:
Have you checked out the 'many' lib? It includes a bunch of techniques for creating 1000s of copies of abstractions.
http://puredata.info/downloads/many
When I've done this kind of thing involving tables, I generally try to make only one soundfiler object load all of the tables. Or depending on what I'm doing, I'll ahve the tables also not in the abstractions. I find it useful to make the abstractions to be multiplied as simple as possible.
.hc
On Nov 13, 2011, at 2:27 AM, Stephen Lucas wrote:
This may have come up before, but I didn't see a clear answer to this on
searches.
I've been doing more work involving the dynamic creation of abstractions
numbering greater than 1000; these involve using [soundfiler], so I've been putting [del 1] between each creation message. This may be extraneous, but I'm attempting to reduce errors in loading (I doubt this is causing the problem, but it may be related). My typical MO in dynamic object creation recently is to treat Y canvas position as product of abstraction register, which usually is a multiplication by enough for them not to overlap in the Y dimension with the automatic line break (depending on how many line breaks I expect pd to make).
I've experienced some anomalies with dynamically creating objects into
this much Y space, which at something like maybe 50000 pixels, I'm getting some sort of wraparound, which oddly enough, is wrapping back to 25000 or so pixels. After the wraparound point, there is no randomness.
Is there a maximum canvas size and does dynamic object creation beyond
those limits have a predictable ramification? Is there some kludge to prevent this? Has anyone experimented with some way of consolidating character number / line break length / canvas size into something cohesive for working with this issue?
Thanks for any input, -Stephen _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
If you are not part of the solution, you are part of the problem.