terenceformer

Here's my scenario: I have a main patch that creates and names objects (abstractions) via scripting. If the main patch is saved and reopened, those objects get created again (over top the previous ones, and named objectname[1] etc), which is no good. I can't script delete them on the patch being freed in case a user of the main patch is prompted to save (it'll save the state with those patcher objects existing before freebang gets called). I can't do anything on the patch loading (e.g. search for those objects and delete them right away) because the objects will already exist, and if the abstraction files they depend upon aren't found there'll be errors.

This seems like it would be a relatively common scenario but I can't find anything that would help me figure it out. I must be overlooking something?!? Thanks for any help :}

Here's my scenario: I have a main patch that creates and names objects (abstractions) via scripting. If the main patch is saved and reopened, those objects get created again (over top the previous ones, and named objectname[1] etc), which is no good. I can't script delete them on the patch being freed in case a user of the main patch is prompted to save (it'll save the state with those patcher objects existing before freebang gets called). I can't do anything on the patch loading (e.g. search for those objects and delete them right away) because the objects will already exist, and if the abstraction files they depend upon aren't found there'll be errors. 

This seems like it would be a relatively common scenario but I can't find anything that would help me figure it out. I must be overlooking something?!? Thanks for any help :}


how-to-deal-with-script-created-objects-if-a-patch-is-saved

Ah, thanks for the suggestion, but it doesn't quite do it for me. Actually creating abstractions with scripting doesn't even set the dirty flag. But in any case, the abstractions will still be there and get saved with the patch if I do any other work on it.

s instead of regular abstractions to take advantage of 

of the abstraction to load. They would still get saved with the overall patch, but the hope was that they would load empty and therefore not cause problems. Unfortunately they still remembered the patcher file from the last session on load, so I guess that's not what 

So far I have had to settle for creating a button that deletes all the abstractions to manually press every time before I save the patch. Pretty annoying, because it's easy to forget and if I do all these bugs start popping up the next time I use it. I've wasted hours before only to realize I had forgotten to delete those damn abstractions…

I thought I might be able to create bpatchers instead of regular abstractions to take advantage of embed 0. I tried scripting in empty bpatchers and subsequently script sending the name of the abstraction to load. They would still get saved with the overall patch, but the hope was that they would load empty and therefore not cause problems. Unfortunately they still remembered the patcher file from the last session on load, so I guess that's not what embed does.

maybe you could delete first, then create, on init?

actually does come through before the save)

@Roman, that is what I was doing actually, but the abstractions still load (adding to load time) and any number of things inside them also initialize, throwing things off, even if they're deleted a moment later

Yes! Savebang does it (the bang actually does come through before the save)

be absolutely threadsafe. but bpatcher is a troublemaker. :(


old style scripting should be absolutely threadsafe. but bpatcher is a troublemaker. :(

How to deal with script created objects if a patch is saved?