Dan Nigrin

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.

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. 

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.

load-picture-problems

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 !

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?

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

i know problems with custom source files too and all i could

suggest is include them for your test builds too

i know problems with custom source files too and all i could
suggest is include them for your test builds too


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 

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

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
http://www.jackosx.com


i got you are loading files from the pluggo runtime folder.

do the problems appear when loading pictures from the

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*


At 10:12 AM -0600 6/14/06, Roman Thilenius wrote:

>i got you are loading files from the pluggo runtime folder.

>do the problems appear when loading pictures from the

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 

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?

At 10:12 AM -0600 6/14/06, Roman Thilenius wrote:
>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*

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

but above you said -43, which would mean "file not found"

both is a weird error on an attempt to load a piture 

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.


Thanks Roman (BTW, where did you find those codes?).

The 43 was a mistake, I was typing it from memory. It's always been 

I will continue to try and figure it out... Unless someone at 

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!

-- 
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
http://www.jackosx.com


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.

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.


Thanks - I did a bit of searching, and found these (for OS 9) here:

http://docs.info.apple.com/article.html?artnum=9805

http://docs.info.apple.com/article.html?artnum=9804

http://docs.info.apple.com/article.html?artnum=9806

"-47 fBsyErr File is busy (delete); Section doing I/O"

0 to -261
http://docs.info.apple.com/article.html?artnum=9805

-299 to -5553
http://docs.info.apple.com/article.html?artnum=9804

1 to 32767
http://docs.info.apple.com/article.html?artnum=9806

"-47 fBsyErr  File is busy (delete); Section doing I/O"

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:

http://www.macosxhints.com/article.php?story=200306032205546

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 

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:

  http://www.macosxhints.com/article.php?story=200306032205546 90

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!

Windows sure. We use uncompressed pcts, they seem to be the only ones QT will allow.

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.

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

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.

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 

>Windows sure. We use uncompressed pcts, they seem to be the only 

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 

I'll try to see if I can create a stripped down test patch for people to try.

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.

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

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

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 

Nor do I (I use Live for most of my work and testing). But users of 

my Pluggo certainly will want to use Logic!

>knowledge is not enough/science is not enough/Love is dreaming this equation

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.  :-(

Nor do I (I use Live for most of my work and testing).  But users of 
my Pluggo certainly will want to use Logic!

>
>--
>knowledge is not enough/science is not enough/Love is dreaming this equation

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 

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 

>> Windows sure. We use uncompressed pcts, they seem to be the only 

> 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 

> I'll try to see if I can create a stripped down test patch for 

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

> 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


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

> 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 

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

> 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

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


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 

Of course, thus far today my attempts at creating a new stripped down 

patch that demonstrates the behavior have failed (as is always the 

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.

>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 

>>>Windows sure. We use uncompressed pcts, they seem to be the only 

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

>>I'll try to see if I can create a stripped down test patch for people to try.

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.

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
>

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?]

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 ?

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

load picture problems