[PD] Dynamic object creation in relation to canvas dimensions

[Stephen Lucas]

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 at.or.at>wrote:

>
> 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 at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111115/d5652f59/attachment.htm>