So I'm using an abstraction that takes an argument [int].

That argument creates a number of instances of a couple objects, including inlets and outlets, via scripting "thispatcher".

loadbang > [message box] #1 > uzi > counter > sprintf script newobject inlet @varname inlet_%ld

I create my top level patch, with this abstraction in place (say with the argument "4" , thus 4 inlets), and all other objects connected. Save it.

patcher: patchcord inlet out of range: deleting patchcord

I guess it's because it is trying to load the top level patch and all its connections and only then my abstraction and its procedural way of actually creating inlets.

Is there a way to force max to load my abstraction first or to defer loading my top level patch connections? 

(my only alternative so far is to also script the top level patch... :/)

So I'm using an abstraction that takes an argument [int].
That argument creates a number of instances of a couple objects, including inlets and outlets, via scripting "thispatcher".

/*something like:
loadbang >  [message box]  #1 > uzi > counter > sprintf script newobject inlet @varname inlet_%ld
*/

I create my top level patch, with this abstraction in place (say with the argument "4" , thus 4 inlets), and all other objects connected. Save it.

When I open  the patch I get the error:

Is there a way to force max to load my abstraction first or to defer loading my top level patch connections? 

(my only alternative so far is to also script the top level patch... :/)

So I'm using an abstraction that takes an argument [int].
That argument creates a number of instances of a couple objects, including inlets 

load-abstraction-first

ok, found a much more clean (and simple) solution.

ok, found a much more clean (and simple) solution.
initialize my abstraction with:

bpatcher @name (abstraction-patch-name) @args (n) @embed 1

Hi, i'm having a similar issue at the moment. I don't quite understand your solution, could you try to explain again or post an example patch please? Much appreciated

@Ben, attached is an example of what he means(@Omar, hope you don't mind if i explain for ya, i like your solution so much i just had to try it). Go into the "TryItHere" patch and see my comment there. Hope it makes sense.

bpatchauto_test.zip

Hi, I'm working on an abstraction to repack/ individually output items from a coll. The arguments specify the coll name (#1), then the elements to output in order (#2-#9) and script required outlets and patching accordingly.

This all works fine and i can save and reload the patch okay but when I duplicate the project, for example, it seems that the abstractions are loaded before the elements are specified, meaning that the scripting goes wrong and the object unpatches.

Does imbedding the abstraction in the bpatcher ensure that the elements are specified before loading?

Hi, I'm working on an abstraction to repack/ individually output items from a coll. The arguments specify the coll name (#1), then the elements to output in order (#2-#9) and script required outlets and patching accordingly. 

This all works fine and i can save and reload the patch okay but when I duplicate the project, for example, it seems that the abstractions are loaded before the elements are specified, meaning that the scripting goes wrong and the object unpatches. 

No problem. Though, when I opened your patch, the ghostly jbogus threw me for a loop - I though halloween was over ;D

I hope this clarifies it. Simply put, we are using bpatcher to embed an abstraction. Which arguably kinda defeats the purpose of an abstraction in a way. But hey, at least it works and you don't have to rewrite all the code, copy and paste a bunch of patcher objects, or script the hell out of your main patch ;)

@  👽R∆J∆ THE RESIDENT ∆LIEN👽 
No problem. Though, when I opened your patch, the ghostly jbogus threw me for a loop - I though halloween was over ;D
@Bent
I hope this clarifies it. Simply put, we are using bpatcher to embed an abstraction. Which arguably kinda defeats the purpose of an abstraction in a way. But hey, at least it works and you don't have to rewrite all the code, copy and paste a bunch of patcher objects, or script the hell out of your main patch ;)

I didn't get the " duplicate the project " part.

Do you mean duplicate the object that is calling the abstraction?

@Ben
I didn't get the " duplicate the project " part.
Do you mean duplicate the object that is calling the abstraction?

I should have explained further. I found that the abstractions loaded fine and remained patched normally, but when i hit "save project as" to save a version of the project im working on elsewhere, the abstractions brought up the error message of "patcher: patchcord inlet out of range: deleting patchcord."

right, it seems that you are having the exact same issue that I was having.

And don't forget to also programatically get rid of your loadbang/mess, as they might try to create objects/patch cords that already exist.

right, it seems that you are having the exact same issue that I was having.
try the bpatcher trick.
And don't forget to also programatically get rid of your loadbang/mess, as they might try to create objects/patch cords that already exist.
let us know how it went.

I embedded my abstraction in a bpatcher as suggested and it has worked, though it is a pain to patch with. As it is a bpatcher I cant't change the arguments while patching as you would with a standard object/ abstraction. Of course this isn't really an issue unless i want to change arguments later while i continue patching...

On another note, rather than scripting [loadbang] to delete after the patch loads i scripted it to disconnect its patchchord, i got thoroughly irritated by having to remake the object whenever i opened the patch...

@Omar 
I embedded my abstraction in a bpatcher as suggested and it has worked, though it is a pain to patch with. As it is a bpatcher I cant't change the arguments while patching as you would with a standard object/ abstraction. Of course this isn't really an issue unless i want to change arguments later while i continue patching... 

load abstraction first