strange loading behaviour…

Jun 14, 2006 at 10:47pm

strange loading behaviour…

#26417
Jun 15, 2006 at 2:51am

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.

binez0r

#78975
Jun 15, 2006 at 10:39am

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).

Best,
Trond

#78976
Jun 15, 2006 at 11:25am

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.

#78977
Jun 16, 2006 at 7:18am

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…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#78978
Jun 16, 2006 at 7:35am

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.

Best,
Trond

#78979
Jun 16, 2006 at 8:06am

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.

-Joshua

#78980
Jun 16, 2006 at 1:18pm

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
following happening:
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
runs.

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

#P outlet 476 121 15 0;
#P objectname out[17];
#P outlet 448 121 15 0;
#P objectname out[16];
#P outlet 420 121 15 0;
#P objectname out[15];
#P outlet 392 121 15 0;
#P objectname out[14];
#P outlet 364 121 15 0;
#P objectname out[13];
#P outlet 336 121 15 0;
#P objectname out[12];
#P outlet 308 121 15 0;
#P objectname out[11];
#N comlet;
#P outlet 280 121 15 0;
#P objectname out[10];
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P hidden newex 28 148 61 196617 patcherargs;
#P objectname args;
#N vpatcher 207 325 963 671;
#P origin 16 -64;
#P window setfont “Sans Serif” 9.;
#P newex 103 146 50 196617 deferlow;
#P newex 468 244 113 196617 sprintf script new ctlin[%i] newex %i 70 26
196617 ctlin %i %i;
#P newex 563 39 50 196617 loadbang;
#P newex 468 102 36 196617 zl reg;
#P newex 468 83 45 196617 onebang;
#P outlet 528 294 15 0;
#P newex 528 83 45 196617 onebang;
#P newex 408 39 96 196617 t b l l;
#P newex 57 220 56 196617 sprintf script connect ctlin[%i] 1 out[%i] 0;
#P newex 57 200 44 196617 gate 1 1;
#P newex 508 39 50 196617 t b l l;
#P inlet 508 21 15 0;
#P inlet 408 21 15 0;
#P newex 408 59 130 196617 testnoargs;
#P newex 600 147 52 196617 t 17 3 i 0;
#P newex 548 147 51 196617 t 17 2 i 0;
#P newex 238 244 113 196617 sprintf script new ctlin[%i] newex %i 70 26
196617 ctlin %i;
#P newex 14 232 41 196617 sprintf script delete out[%i];
#P newex 238 223 240 196617 gate 3 1;
#P newex 468 186 78 196617 swap;
#P newex 548 122 104 196617 route ch ctl;
#P newex 353 244 113 196617 sprintf script new ctlin[%i] newex %i 70 26
196617 ctlin %i %i;
#P newex 14 172 32 196617 !- 16;
#P newex 14 192 32 196617 uzi;
#P newex 14 212 32 196617 !- 18;
#P newex 174 232 62 196617 sprintf script connect in 0 ctlin[%i] 0;
#P newex 57 172 44 196617 uzi;
#P newex 103 172 25 196617 + 1;
#P newex 115 220 57 196617 sprintf script connect ctlin[%i] 0 out[%i] 0;
#P newex 502 147 29 196617 * 28;
#P newex 468 122 78 196617 izi;
#P outlet 391 293 15 0;
#P fasten 31 0 9 0 108 165 19 165;
#P connect 9 0 8 0;
#P connect 8 2 7 0;
#P connect 7 0 14 0;
#P fasten 17 0 9 1 605 168 41 168;
#P fasten 16 0 9 1 553 168 41 168;
#P fasten 31 0 5 0 108 165 62 165;
#P fasten 17 3 22 0 647 191 62 191;
#P fasten 16 3 22 0 592 191 62 191;
#P connect 22 0 23 0;
#P connect 5 2 22 1;
#P fasten 1 1 31 0 507 142 108 142;
#P connect 31 0 4 0;
#P connect 4 0 23 1;
#P fasten 5 2 3 0 96 194 120 194;
#P fasten 5 2 3 1 96 194 167 194;
#P fasten 5 2 6 0 96 194 179 194;
#P fasten 17 1 13 0 619 176 243 176;
#P fasten 16 1 13 0 566 176 243 176;
#P connect 13 0 15 0;
#P fasten 2 0 15 1 507 180 294 180;
#P fasten 12 1 15 2 541 211 345 211;
#P connect 13 1 10 0;
#P fasten 2 0 10 1 507 180 392 180;
#P fasten 30 0 0 0 473 288 396 288;
#P fasten 6 0 0 0 179 288 396 288;
#P fasten 3 0 0 0 120 288 396 288;
#P fasten 14 0 0 0 19 288 396 288;
#P fasten 15 0 0 0 243 288 396 288;
#P fasten 10 0 0 0 358 288 396 288;
#P fasten 23 0 0 0 62 288 396 288;
#P connect 19 0 24 0;
#P connect 24 0 18 0;
#P fasten 12 1 10 2 541 211 426 211;
#P fasten 16 2 10 3 579 216 460 216;
#P connect 24 1 18 1;
#P fasten 21 0 27 0 513 67 473 67;
#P connect 18 1 27 0;
#P connect 27 0 28 0;
#P connect 28 0 1 0;
#P connect 1 0 12 0;
#P connect 12 0 13 1;
#P connect 13 2 30 0;
#P connect 24 2 28 1;
#P fasten 1 2 2 0 541 144 507 144;
#P connect 2 0 30 1;
#P connect 25 0 27 1;
#P connect 20 0 21 0;
#P connect 21 1 18 2;
#P connect 18 2 25 0;
#P connect 25 0 26 0;
#P connect 1 2 12 1;
#P fasten 17 2 30 2 633 226 541 226;
#P connect 21 2 11 0;
#P connect 11 0 16 0;
#P connect 29 0 25 1;
#P connect 12 1 30 3;
#P connect 11 1 17 0;
#P pop;
#P hidden newobj 28 168 61 196617 p scripts;
#P objectname scripts;
#N thispatcher;
#Q end;
#P hidden newobj 28 188 61 196617 thispatcher;
#P objectname this;
#P inlet 28 44 15 0;
#P objectname in;
#P outlet 252 121 15 0;
#P objectname out[9];
#P outlet 224 121 15 0;
#P objectname out[8];
#P outlet 196 121 15 0;
#P objectname out[7];
#P outlet 168 121 15 0;
#P objectname out[6];
#P outlet 140 121 15 0;
#P objectname out[5];
#P outlet 112 121 15 0;
#P objectname out[4];
#P outlet 84 121 15 0;
#P objectname out[3];
#P outlet 56 121 15 0;
#P objectname out[2];
#N comlet;
#P outlet 28 121 15 0;
#P objectname out[1];
#P hidden connect 12 1 11 1;
#P hidden connect 11 0 10 0;
#P hidden connect 12 0 11 0;
#P hidden connect 11 1 12 0;
#P window clipboard copycount 21;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#78981

You must be logged in to reply to this topic.