Yes, in my main performance patch as well, on rare occassion one of them bpatches won't initialize correctly. I've done the same, adding a delay, letting the file I/O initialize before bothering with dumping the file data into their respective bpatchers. It confuses me though. In isolation the bpatchers in question load fine with their internal loadbangs each time that I've opened them. So, i do believe I know what you speak of.
I would guess that the creation of new objects by scripting is a low
priority thing, as it implies assigning memory to the objects, etc. If
so it might be that you can not always trust right to left order. If I
am right on this, it would also make sense that the problem escalate as
your patches grow bigger.
A workaround might be to find a way to determine inside each of the
abstractions when scripting has completed, store incoming values (e.g.
using float, int, zl reg or similar) and then bang these objects when
scripting is complete just to make sure.
Another possibility would be to use loadbangs inside each abstractions
for creation, but use a separate and delayd initialization scheme on the
global level (e.g. send/receive init).
I would say it is not even a low priority thing. I'd say that loading patchers is done in a seperate thread (like opendialog, which on the other hand blocks until the dialog is closed). This means that the only way to know when the loading is done is to put a loadbang in the abstraction and to continue only after that bang fired. To make sure all the abstraction's loadbangs have fired before the abstraction says it's finished, you could put a deferlow after the loadbang that signals load done (assuming there are no other deferlows in the initialization of the abstraction).
I am working on exactly the same thing now, trying to make a huge patch a little smaller by adding functional parts only when they are needed.
Mattijs Kneppers wrote:
> I would say it is not even a low priority thing. I'd say that loading
> patchers is done in a seperate thread (like opendialog, which on the
> other hand blocks until the dialog is closed).
That might be an explanation, it just seems that there is no check if an
object had been loaded to go on with the next left event. In big
patchers loadtime seems to increase till its too long...
That would also explain why the way faster machine has more problems
with it. The trigger thread might be faster than the load thread and
hits before the object is loaded.
A comment from the c74 gurus would be nice...
Could you post an abstraction that is organized with scripting in such a
way that you might have it failing? If we had an example patch, it might
be easier to see if it is possible to find ways to work around it.
On Jun 16, 2006, at 12:18 AM, Stefan Tiedje wrote:
> A comment from the c74 gurus would be nice...
As *always*, stripped example which illustrates the issue, please.
Otherwise little we can offer.
Loading of patchers always happens in the main (low priority) thread.
Though if you're exploiting loadbangs + scripted objects, it sounds
like the scripted objects may no necessarily be instantiated when you
are loadbanging. Hard to tell without an explicit example, though.
Trond Lossius wrote:
> Could you post an abstraction that is organized with scripting in such a
> way that you might have it failing? If we had an example patch, it might
> be easier to see if it is possible to find ways to work around it.
The workaround for the moment is to deferlow the connection part of the
script, which seems to help on first sight.
I'll attach my ctlins abhaXion with that modification (the original is
just without the deferlow) you need to save it as ctlins, and load it
into a patch with midicontrolers as arguments.
Another issue which is much worse:
On that mentioned G5 double processor 2.5 GHz, 2 meg of RAM. The patch
which utilises a lot of scheduler events, creating lists, doing heavy
spatialisation (based on multiouts from GMEM) I have several time the
The patch runs fine, CPU ca. 20% but the activity monitor shows
something like 80%.
Sometimes, maybe caused by Midiinput (just a feeling, not sure) I get a
spinning wheel which will never go away, all visual feedback stops, Max
is hanging but the patch still runs without problem!!! I can still
control each detail which has a Midi connection very scary...
Only a force quit will get Max out of this state...
It seems just the user interface is completely stopped, everything else
I tried the same patch on my way slower Powerbook 1.5 GHz and I can run
the patch, CPU shows around 40% and the activity monitor also around
80%. There I don't get the sort of crash, but the userinterface gets
really slow (too slow)....
Any advice (beside the obvious, like stripping down the patch, get rid
of uneccascary parts...) is welcome. I don't know if its a Max isuue or
an OS issue, maybe both...
voila the ctlins