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