personally, i wouldn't bother with saving the generated abstractions to a location on disk. i've revisited the patch i did a few months ago and what happens in my is that i have an abstraction that it set up to generate a subpatch on its own canvas (not the main patches canvas). so what happens is on the main patch, i create an instantiation of that abstraction with various creation arguments to make it unique. when that abstraction is instantiated, it goes through a sequence of events:

a. create the new subpatch on the abstraction's canvas. something like this:
[loadbang]
|
[symbol $1] ($1 is the name of the sub patch to be created)
| \
| [makefilename pd-%s] (you will need this symbol for referencing)
| |
[pack s s]
|
[ ; (
[ pd-abstraction.pd obj 83 500 pd-abstraction.pd $1; ( (create it)
[$2 vis 0 ( (hide it)

b. fill the subpatch with whatever it needs to function. e.g.

first you need to pack any parameters together that will govern how the subpatch is created. the only parameter you absolutely need is the name of the subpatch window prefixed by 'pd-'. you'll make this symbol as above with the makefilename object so it looks like pd-subpatch. other paremeters i used were a send/receive name, and one other numerical parameter. after you have your parameters packed, send them to a message like this ($1 is the window name, $2 and $3, are other parameters):

[pack s s f]
|
[ ; (
[pd-abstraction.pd vis 1, $1 vis 1 (
[$1 obj 10 10 r $2, obj 40 40 * $3; (
[$1 connect ....etc.... (
[ create and connect more objs (
[ $1 vis 0 (
[pd-abstraction.pd vis 0 (

note that i have included messages to show and hide windows. i don't know why it's necessary, but i ran into problems when the window wasn't visible. it probably has something to do with the coordinate system. another thing i did in my patch was before i sent this message, i ran a few messages to clear the contents of the subpatch just in case a subpatch with that name had already been created.

and that's about it. my actually patch was a little bit more complicated. i have simplified here for easier explanation. my patch had more complex naming conventions and more parameters were passed to the message box that created the contents of the new subpatch.

i hope this helps.

thanks for the reply,
by my understanding of your post, i think our ideas are quite similar. My patch has a global counter which assigns a number for the creation argument of the abstraction, so that when created, the array and any related objects will all be given a name/assignment of sample1 or sample2 etc. when the next abstraction is created, the global counter will then send the next sequential number, sample2, sample3 etc.

that part is working fine, the problem lies in that every instance of the abstraction that i create has been created in a cache somewhere, which i can only assume isn't on the scratch disc (since a search for the file yeilded no results), what i want to do is add a few lines to the creation code that will tell pd (much in the same way that it tells it to create a new abstraction, fill it, and open it) to save the file to a set location, with a unique name, and then create an instance of it on the original canvas, so that it can be used.
i have also written a simple delay loop object, and another patch based on a vst plugin that i use with audiomulch that overides the buffersize and samplesize of the soundcard which i would like to be able to create any number of.
Essentially my goal is to create a patch which, when opened, is blank save for a few message boxes, which when clicked will create my abstractions so that any number of instances can be linked together in any combination.
anyway, i hope that my reply was clear enough, and that you might be able to help me.
thanks
-sam