Hey guys, been lurking here a few weeks and posting for the first time. I'm trying to set up a patch such that I can run multiple instances of it at the same time without references getting mixed up. It's working out except for one detail: there is an array used for control in the main window of the patch I want to rename for every instance of the patch that I open. I'm trying to do this by calling it "g1" and then using

[loadbang]
|
[symbol $0-control]
|
[g1 rename $1(

to rename it as "1022-control" (or whatever) each time I open the patch. Thus if I open each instance of the patch one at a time, each array should have its own "10xx-control" name. This works EXCEPT: if I save the patch after opening and changing the array name, the array name gets saved as "1022-control" and the next time I open the patch I will get the obvious "error: no such array g1" error, as that array is stuck on the last $0 value before saving while everything else has updated!

Are there any workarounds for this, besides renaming the array to "g1" every time I change something with the patch and want to save? I also have an array I'm using as a buffer that gets renamed fine because it is in a

OK figured it out. Turns out creating an array in the main window with "$0-control" works, stupid me.

But now I have a different problem. Now I am using writesf~ to record a file, which is immediately "read -resize"d into the buffer array at the same time the [stop( message is banged. However the resizing of the buffer array always gives me an "error: resize failed" message. What's weirder is that if I bang the resize message again it works again, and a [print] object I've attached to the

[; read -resize(

message (above the comment "diagnostic purposes only" in the "pd input" subpatch) shows this message outputs the exact same message on both bangs. So why does it only work on the second bang?

Buggy patch attached for reference...

http://www.pdpatchrepo.info/hurleur/grainlooper-1c.pd

OK, fixed it by adding [delay 10] before the bang that eventually pushes the [; read -resize( message through. Best guess is the patch outraces the hard disk without this delay.

Wow, my first thread here turned into a soliloquy...sorry everyone

Yeah, when you stop [writesf~] you have to give it time to flush everything to the disk before you can open the file. I burn myself with this one all the time.

soliloquy is still good, because when other users search for similar issues in the future, they may find your findings useful.

hey,

concerning the first topic, i go around confusion with $0 using $1 etc with creation arguments for each patches in a masterpatch.
might help? completely off topic? ...