strange loading behaviour...


    Jun 14 2006 | 10:47 pm

    • Jun 15 2006 | 2:51 am
      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
    • Jun 15 2006 | 10:39 am
      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
    • Jun 15 2006 | 11:25 am
      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.
    • Jun 16 2006 | 7:18 am
      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
    • Jun 16 2006 | 7:35 am
      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
    • Jun 16 2006 | 8:06 am
      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
    • Jun 16 2006 | 1:18 pm
      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
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com