load picture problems


    Jun 07 2006 | 1:28 am
    I have a Pluggo that works perfectly while still in Max/MSP, and *most* of the time it works perfectly as a Pluggo too. Problem is, sometimes when the plugin loads, it does not successfully load all the .pic files that are used in the patch. I get a bunch of "doPicture error -43" or some such similar error.
    If I just restart the host app, or even just dispose of the plugin instance and load up another one, it will either work correctly, or a different subset of pic's will not load.
    Some of the pic's are in the main patch, some are in bpatchers.
    Ideas? Do I have to slow down the loading of the plugin or something, so it has time to load all the pic's? They are all in fpic objects BTW, and there are quite a few - probably 10-15 or so.
    Thanks,
    Dan

    • Jun 07 2006 | 10:08 am
      I usually copy/paste the finished interface to photoshop, and then makes one pict file with the complete gui, which normally helps....
      but i've had this problem many times too, mainly in pluggos ?
      also sometimes, if i open one copy of a plugin is looks fine....if i open another instance, the pictures are missing making the whole thing look horrible !
    • Jun 07 2006 | 11:44 am
      That's exactly the problem - but it would be incredibly painful to have to "flatten" all my pics into one main pic, mainly because I am constantly making adjustments, and furthermore, I am concerned that even that one big main pic might not get loaded until we get to the root of the problem... Also, many of my pics are embedded in bpatchers, making the problem more complicated....
      Anyone have a solution or at least know the cause of the problem?
      Thanks,
      Dan
    • Jun 13 2006 | 3:53 pm
      Bump!
    • Jun 13 2006 | 6:46 pm
      i know problems with custom source files too and all i could
      suggest is include them for your test builds too
    • Jun 14 2006 | 12:39 am
      At 12:46 PM -0600 6/13/06, Roman Thilenius wrote:
      >i know problems with custom source files too and all i could
      >suggest is include them for your test builds too
      Roman, can you clarify what you mean by "include them for your test
      builds too"?
      Thanks,
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jun 14 2006 | 4:12 pm
      i got you are loading files from the pluggo runtime folder.
      arent you?
      do the problems appear when loading pictures from the
      within plug-in binary? *shocked*
    • Jun 14 2006 | 4:31 pm
      At 10:12 AM -0600 6/14/06, Roman Thilenius wrote:
      >i got you are loading files from the pluggo runtime folder.
      >arent you?
      No - see below.
      >do the problems appear when loading pictures from the
      >within plug-in binary? *shocked*
      Yes, that's what I'm experiencing. Note that there are many (~30)
      pictures, used in a variety of objects (matrixctrl, fpic, pictctrl).
      All of my patches and images are kept in a single folder on my HD.
      When I build my plugin using the Collective Editor, I don't manually
      add any of the pct's in the script, they are automatically found
      because they are in the same folder as the main patch. The Build
      finishes with no errors, and I can see in the Max window that all of
      the images are added successfully.
      I still think that this has something to do with startup timing -
      that the plugin get's initialized too quickly, and that the images
      don't have time to load... I can't think of any other reason that
      the images that are loaded successfully or not on each launch of the
      plugin would be different on different occasions...
      Does anyone know what "error -47" actually indicates?
      Thanks,
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jun 15 2006 | 8:57 pm
      that would be "file is busy".
      but above you said -43, which would mean "file not found"
      both is a weird error on an attempt to load a piture
      resouce from within a file.
    • Jun 15 2006 | 9:00 pm
      Thanks Roman (BTW, where did you find those codes?).
      The 43 was a mistake, I was typing it from memory. It's always been
      47. File is busy! That's weird....
      I will continue to try and figure it out... Unless someone at
      Cycling has ideas!
      Thanks,
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jun 16 2006 | 2:18 am
      i know these 2 and a few others by heart, but there
      are some little utilities out with error code explanations.
      dont know one for OS X but "easy errors" which is in my
      applemenu since 10 years runs in classic enviroment.
      the ~300 basic codes are the same ones since OS 7.
    • Jun 16 2006 | 11:32 am
      Thanks - I did a bit of searching, and found these (for OS 9) here:
      0 to -261
      -299 to -5553
      1 to 32767
      The official description for -47 is:
      "-47 fBsyErr File is busy (delete); Section doing I/O"
      Still puzzling....
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jun 16 2006 | 11:42 am
      And after a bit more searching, here is where to look for OS X error
      codes. This is the link where I found the info:
      Basically, it says that there is a list of Mac error codes in the
      Carbon CoreServices framework header file. It is located at
      /System/Library/Frameworks/CoreServices.framework/
      Versions/A/Frameworks/CarbonCore.framework/Headers/MacErrors .h
      Might be useful for future reference... Oh, and -47 means the same
      thing it did in OS 9!
      Dan
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jul 06 2006 | 3:39 pm
      I've not seen this sort of thing on Mac.
      Windows sure. We use uncompressed pcts, they seem to be the only ones QT will allow.
      -A
    • Jul 06 2006 | 4:29 pm
      Far be it from me to tell y'all what to do, but
      I never use bpatchers, *always* go with the
      single picture, and so on. While those *are*
      elective decisions, I don't seem to have as much
      trouble as you do, generally.
      Oh... and I don't use Logic. :-)
    • Jul 06 2006 | 7:31 pm
      At 8:39 AM -0700 7/6/06, Andrew Pask wrote:
      >I've not seen this sort of thing on Mac.
      Thanks Andrew - I am on a Mac, as is Roman and I think a few others
      who have posted similar problems..
      >Windows sure. We use uncompressed pcts, they seem to be the only
      >ones QT will allow.
      Uncompressed pcts is what I'm using...
      This issue is still bothering me - I'm having better luck now that
      I've significantly reduced the number of pcts that I'm using, but my
      UI has suffered as a result. It would be darn nice to get to the
      bottom of this, so that you guys could address it in an upcoming
      update. I'm pretty sure that it's a legitimate bug of a some sort,
      or at least a known limitation that needs to be worked around (and
      the best way to do so).
      I'll try to see if I can create a stripped down test patch for people to try.
      Dan
      >-A
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jul 06 2006 | 7:33 pm
      At 10:29 AM -0600 7/6/06, Gregory Taylor wrote:
      >Far be it from me to tell y'all what to do, but
      >I never use bpatchers, *always* go with the
      >single picture, and so on. While those *are*
      >elective decisions, I don't seem to have as much
      >trouble as you do, generally.
      Thanks Greg - still though, it would be nice if Cycling were to state
      so up front, so that people don't waste time making complex UI's for
      Pluggo's initially, only to have to reduce it all to a single
      patcher/picture in the end. :-(
      >Oh... and I don't use Logic. :-)
      Nor do I (I use Live for most of my work and testing). But users of
      my Pluggo certainly will want to use Logic!
      Best,
      Dan
      >
      >--
      >knowledge is not enough/science is not enough/Love is dreaming this equation
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jul 06 2006 | 7:47 pm
      Hipno uses a gazillion pct images - a different pct for every slider,
      widget, and various layers of bpatcher backgrounds. I've not noticed
      the problem in Hipno... So I''m not sure what the issue is that you
      are seeing - a patch would be great.
      -Tim
      On Jul 6, 2006, at 2:31 PM, Dan Nigrin wrote:
      > At 8:39 AM -0700 7/6/06, Andrew Pask wrote:
      >> I've not seen this sort of thing on Mac.
      >
      > Thanks Andrew - I am on a Mac, as is Roman and I think a few others
      > who have posted similar problems..
      >
      >> Windows sure. We use uncompressed pcts, they seem to be the only
      >> ones QT will allow.
      >
      > Uncompressed pcts is what I'm using...
      >
      > This issue is still bothering me - I'm having better luck now that
      > I've significantly reduced the number of pcts that I'm using, but
      > my UI has suffered as a result. It would be darn nice to get to
      > the bottom of this, so that you guys could address it in an
      > upcoming update. I'm pretty sure that it's a legitimate bug of a
      > some sort, or at least a known limitation that needs to be worked
      > around (and the best way to do so).
      >
      > I'll try to see if I can create a stripped down test patch for
      > people to try.
      >
      > Dan
    • Jul 06 2006 | 7:53 pm
      On Jul 6, 2006, at 2:33 PM, Dan Nigrin wrote:
      > At 10:29 AM -0600 7/6/06, Gregory Taylor wrote:
      >> Far be it from me to tell y'all what to do, but
      >> I never use bpatchers, *always* go with the
      >> single picture, and so on. While those *are*
      >> elective decisions, I don't seem to have as much
      >> trouble as you do, generally.
      >
      > Thanks Greg - still though, it would be nice if Cycling were to
      > state so up front, so that people don't waste time making complex
      > UI's for Pluggo's initially, only to have to reduce it all to a
      > single patcher/picture in the end. :-(
      I'm not speaking on behalf of the firm here - just
      stating my own experience, that's all. I realize
      that this must be confusing sometimes. It's a
      side-effect of my working and my performing
      lives overlapping here and there.
      >
      >> Oh... and I don't use Logic. :-)
      >
      > Nor do I (I use Live for most of my work and testing). But users
      > of my Pluggo certainly will want to use Logic!
      Indeed. Sorry to hear it, though. Logic really seems
      to have some issues with timing stuff that I don't
      really see much in the contexts in which I work [usually
      DP or radiaL].
    • Jul 06 2006 | 9:01 pm
      Thanks Tim - it's good to know that it's possible to have many pct's
      in a Pluggo with no problems, and that the problem is due to
      something specific in my patch and/or programming style. Since
      other's have experienced the behavior too, I'm guessing it's the
      latter...
      Of course, thus far today my attempts at creating a new stripped down
      patch that demonstrates the behavior have failed (as is always the
      case it seems!), but I'll keep at it.
      Thx,
      Dan
      At 2:47 PM -0500 7/6/06, Tim Place wrote:
      >Hipno uses a gazillion pct images - a different pct for every
      >slider, widget, and various layers of bpatcher backgrounds. I've
      >not noticed the problem in Hipno... So I''m not sure what the issue
      >is that you are seeing - a patch would be great.
      > -Tim
      >
      >
      >On Jul 6, 2006, at 2:31 PM, Dan Nigrin wrote:
      >
      >>At 8:39 AM -0700 7/6/06, Andrew Pask wrote:
      >>>I've not seen this sort of thing on Mac.
      >>
      >>Thanks Andrew - I am on a Mac, as is Roman and I think a few others
      >>who have posted similar problems..
      >>
      >>>Windows sure. We use uncompressed pcts, they seem to be the only
      >>>ones QT will allow.
      >>
      >>Uncompressed pcts is what I'm using...
      >>
      >>This issue is still bothering me - I'm having better luck now that
      >>I've significantly reduced the number of pcts that I'm using, but
      >>my UI has suffered as a result. It would be darn nice to get to
      >>the bottom of this, so that you guys could address it in an
      >>upcoming update. I'm pretty sure that it's a legitimate bug of a
      >>some sort, or at least a known limitation that needs to be worked
      >>around (and the best way to do so).
      >>
      >>I'll try to see if I can create a stripped down test patch for people to try.
      >>
      >>Dan
      >
      --
      Dan Nigrin
      Defective Records
      202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
      http://www.defectiverecords.com
    • Jul 13 2006 | 1:01 am
      I think maybe including it in the collective and then using an argument via a message box to load the picture maybe 2000ms after the patch has loaded [keep the fpics blank to start with] would probably solve the problem. Its probably something to do with delay compensation and quicktime along with pluggo initialization timing. try a 2-3 second delay before the UI elements load [low priority, remember?]
      james
    • Jul 14 2006 | 6:18 am
      well, i know this problem, but it not locked with the plugins`...
      i have a few plugins which works fine on one computer and has no pics on another ? (the picture files is included in the build and are not in the searchpath on both computers)
      btw, i have only noticed the problem with fpic, not with jitter, pictctrl or anything else i've used...
      Does Hipno load it's pictures in fpic ? i figure a lot of it must be jitter & pictctrl ?
    • Jul 14 2006 | 11:57 am
    • Jul 14 2006 | 12:36 pm
      hm, now i have a qeustion for you again in this context.
      before you tried delaying your pictures, did you "load"
      them anyway (as opposed to setting the source in the
      inspector)? if yes, maybe this is the reason for the
      issue?