I'm experiencing some instability with a patch that is very large.
Basically, I have an abstraction that does some calculations between a send and receive, whose names are controlled by the creation arguments of the abstraction.
I made a little patch to create 68x68 of these (yes, I really need that many), and correctly place them on the canvas so that they don't overlap graphically. As far as I can tell, they all created fine and I even managed to save the patch. I did use a text editor to manually increase the size of the canvas, since message based object creation will not automatically resize the canvas if something will be past the bounds of the canvas.
I've been getting inconsistant problems (crashing) with what I can only assume is an issue with a patch this large (4624 objects). If I understand things correctly, these abstractions do not have any DSP objects and should not be consuming large quantities of system resources if they're just hanging around, waiting to be used. I suspect the problem may mainly be linked to actually looking at the patch, which I don't need to do, but I don't feel confident using a patch that is always cheating death. If I don't look at the patch and just load it as an abstraction in another patch, it seems much more stable, but still takes a long time to create, delete, open, or close.
Has anyone else seen this problem and am I crazy for trying to do this? In Max I probably would have tried to approach this using poly~, but I don't know any objects in pd that have similar methods of creating several instances of an abstraction. If this is simply a problem of having a very large canvas, I could compartmentalize the abstractions to solve that.
Thanks to anyone who puts in their 2cents.
-Stephen
There are a bunch of poly objects for Pd, I use nqpoly4 all the time,
then there is polypoly~ and others. I've certainly used patches with
500-1000 abstraction instances without problem, I guess I haven't
tried 4600.
.hc
On Nov 30, 2009, at 1:09 PM, Stephen Lucas wrote:
I'm experiencing some instability with a patch that is very large.
Basically, I have an abstraction that does some calculations between
a send and receive, whose names are controlled by the creation
arguments of the abstraction.I made a little patch to create 68x68 of these (yes, I really need
that many), and correctly place them on the canvas so that they
don't overlap graphically. As far as I can tell, they all created
fine and I even managed to save the patch. I did use a text editor
to manually increase the size of the canvas, since message based
object creation will not automatically resize the canvas if
something will be past the bounds of the canvas.I've been getting inconsistant problems (crashing) with what I can
only assume is an issue with a patch this large (4624 objects). If I
understand things correctly, these abstractions do not have any DSP
objects and should not be consuming large quantities of system
resources if they're just hanging around, waiting to be used. I
suspect the problem may mainly be linked to actually looking at the
patch, which I don't need to do, but I don't feel confident using a
patch that is always cheating death. If I don't look at the patch
and just load it as an abstraction in another patch, it seems much
more stable, but still takes a long time to create, delete, open, or
close.Has anyone else seen this problem and am I crazy for trying to do
this? In Max I probably would have tried to approach this using
poly~, but I don't know any objects in pd that have similar methods
of creating several instances of an abstraction. If this is simply a
problem of having a very large canvas, I could compartmentalize the
abstractions to solve that.Thanks to anyone who puts in their 2cents.
-Stephen _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
hello,
i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. but if your are patient, pd vanilla is solid like a rock.
Cyrille
Stephen Lucas a écrit :
I'm experiencing some instability with a patch that is very large.
Basically, I have an abstraction that does some calculations between a send and receive, whose names are controlled by the creation arguments of the abstraction.
I made a little patch to create 68x68 of these (yes, I really need that many), and correctly place them on the canvas so that they don't overlap graphically. As far as I can tell, they all created fine and I even managed to save the patch. I did use a text editor to manually increase the size of the canvas, since message based object creation will not automatically resize the canvas if something will be past the bounds of the canvas.
I've been getting inconsistant problems (crashing) with what I can only assume is an issue with a patch this large (4624 objects). If I understand things correctly, these abstractions do not have any DSP objects and should not be consuming large quantities of system resources if they're just hanging around, waiting to be used. I suspect the problem may mainly be linked to actually looking at the patch, which I don't need to do, but I don't feel confident using a patch that is always cheating death. If I don't look at the patch and just load it as an abstraction in another patch, it seems much more stable, but still takes a long time to create, delete, open, or close.
Has anyone else seen this problem and am I crazy for trying to do this? In Max I probably would have tried to approach this using poly~, but I don't know any objects in pd that have similar methods of creating several instances of an abstraction. If this is simply a problem of having a very large canvas, I could compartmentalize the abstractions to solve that.
Thanks to anyone who puts in their 2cents.
-Stephen
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm currently working heavy on a patch that has 100ish abstractions
that loads 1.1gigs of samples into memory, and it hasn't crashed yet.
It does certainly take a couple minutes to load tho. But once it
loads, I can work for days without restarting the patch, even thru
putting the computer to sleep. I'm running Pd-extended 0.42.5-20091112.
One thing I have noticed is that there was no feedback that the patch
is loading. Pd just stops responding while loading the patch. This
could be interpreted as a crash, but its not. Wait, and it'll
eventually load. And I added a "watch" mouse cursor for Pd-extended
when its loading, so that should help communicate that Pd is busy
loading.
As for shortening load times, Claude wrote code for caching
abstractions which dramatically speeds things up, that would be nice
to have, but it is also tricky to do. What's more important, faster
load times or less bugs? That's my concern.
.hc
On Dec 2, 2009, at 6:51 AM, cyrille henry wrote:
hello,
i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save. but if your are patient, pd vanilla is solid like a rock.
Cyrille
Stephen Lucas a écrit :
I'm experiencing some instability with a patch that is very large. Basically, I have an abstraction that does some calculations
between a send and receive, whose names are controlled by the
creation arguments of the abstraction. I made a little patch to create 68x68 of these (yes, I really need
that many), and correctly place them on the canvas so that they
don't overlap graphically. As far as I can tell, they all created
fine and I even managed to save the patch. I did use a text editor
to manually increase the size of the canvas, since message based
object creation will not automatically resize the canvas if
something will be past the bounds of the canvas. I've been getting inconsistant problems (crashing) with what I can
only assume is an issue with a patch this large (4624 objects). If
I understand things correctly, these abstractions do not have any
DSP objects and should not be consuming large quantities of system
resources if they're just hanging around, waiting to be used. I
suspect the problem may mainly be linked to actually looking at the
patch, which I don't need to do, but I don't feel confident using a
patch that is always cheating death. If I don't look at the patch
and just load it as an abstraction in another patch, it seems much
more stable, but still takes a long time to create, delete, open,
or close. Has anyone else seen this problem and am I crazy for trying to do
this? In Max I probably would have tried to approach this using
poly~, but I don't know any objects in pd that have similar methods
of creating several instances of an abstraction. If this is simply
a problem of having a very large canvas, I could compartmentalize
the abstractions to solve that. Thanks to anyone who puts in their 2cents.-Stephen
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Thu, 3 Dec 2009, hard off wrote:
What's more important, faster load times or less bugs? That's my
concern.<< less bugs. every time.
You don't even know what are those bugs and whether they even exist.
I'm not sure whether Hans knows either.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 2 Dec 2009, Hans-Christoph Steiner wrote:
As for shortening load times, Claude wrote code for caching abstractions which dramatically speeds things up, that would be nice to have, but it is also tricky to do. What's more important, faster load times or less bugs? That's my concern.
What are the bugs in Claude's code?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Dec 2, 2009, at 3:25 PM, Mathieu Bouchard wrote:
On Wed, 2 Dec 2009, Hans-Christoph Steiner wrote:
As for shortening load times, Claude wrote code for caching
abstractions which dramatically speeds things up, that would be
nice to have, but it is also tricky to do. What's more important,
faster load times or less bugs? That's my concern.What are the bugs in Claude's code?
I don't know if there are any. I am just saying new code has new
bugs. Plus I think caching is tricky to nail down.
.hc
Access to computers should be unlimited and total. - the hacker ethic
On Wed, 2 Dec 2009, cyrille henry wrote:
i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save.
What can make any patch longer to save than to load? I'd like to know. Normally, using abstractions makes it much longer to load a patch than to save it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard a écrit :
On Wed, 2 Dec 2009, cyrille henry wrote:
i made some patch that use 98454 abstractions. it certainly is very long to load, and almost impossible to save.
What can make any patch longer to save than to load? I'd like to know. Normally, using abstractions makes it much longer to load a patch than to save it.
in the patch i made that use so many abstraction, i have : abstraction_1 that have about 10 abstraction_2 inside. abstraction_2 use about 10 abstraction_3 ... abstraction_5 use about 10 abstraction_6
if you save abstraction_2, then pd will have to reload all abstraction_2
this is lot's longer than loading the patch.
anyway, in order to reload abstractions, pd have to remove the old and create a new. this is longer than only create a new.
Cyrille
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--- On Wed, 12/2/09, cyrille henry ch@chnry.net wrote:
From: cyrille henry ch@chnry.net Subject: Re: [PD] Very large patches unstable? To: "Mathieu Bouchard" matju@artengine.ca Cc: "PD-List" pd-list@iem.at Date: Wednesday, December 2, 2009, 9:36 PM
Mathieu Bouchard a écrit :
On Wed, 2 Dec 2009, cyrille henry wrote:
i made some patch that use 98454 abstractions. it
certainly is very long to load, and almost impossible to save.
What can make any patch longer to save than to load?
I'd like to know. Normally, using abstractions makes it much longer to load a patch than to save it.
in the patch i made that use so many abstraction, i have : abstraction_1 that have about 10 abstraction_2 inside. abstraction_2 use about 10 abstraction_3 ... abstraction_5 use about 10 abstraction_6
if you save abstraction_2, then pd will have to reload all abstraction_2
this is lot's longer than loading the patch.
anyway, in order to reload abstractions, pd have to remove the old and create a new. this is longer than only create a new.
But saving the parent patch that holds all of these abstractions should take very little time. I thought that's what you were talking about.
-Jonathan
Cyrille
_ _ __ ___ _____ ________ _____________
_____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone:
+1.514.383.3801
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2 Dec 2009, Jonathan Wilkes wrote:
On Wed, 12/2/09, cyrille henry ch@chnry.net wrote:
anyway, in order to reload abstractions, pd have to remove the old and create a new. this is longer than only create a new.
But saving the parent patch that holds all of these abstractions should take very little time. I thought that's what you were talking about.
That's also what I thought it was. Cyrille only mentioned saving a patch containing over 66666 abstraction instances, not saving an abstraction that has to be reloaded.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
cyrille henry -
Hans-Christoph Steiner -
hard off -
Jonathan Wilkes -
Mathieu Bouchard -
Stephen Lucas