Best-Practices with editing abstractions?
Hi,
I'm finding the potential for some confusion when dealing with multiple copies of abstractions that get added and editing over different points of patch development.
Just to verify what I found by trying it:
1. If I edit an abstraction in a patch with CMD+double click and save changes, the stand-alone abstraction on the disk is modified (i.e. the Max patch that is the abstraction). This affects any NEW instances of that abstraction in patches, but not previous ones.
2. If I edit and don't save changes, the edits stick for that instance of the abstraction, but nothing else, and the patch file is not modified.
3. If I duplicate any existing instance (CMD+D), the 'duplicate' is the current patch file at that time-- which is not neccesarily a literal duplicate of the abstraction I ran the duplicate command on (due to #2).
Question #1: So is there a way to create a bunch of instances and 'link' them to the abstraction file so that they all change when it changes?
Question #2: This all seems a bit confusing and like it could create some headaches over the course of developing some larger. Are there any suggestions/workflows/rules for keeping it all straight? Or is it somehow much simpler and I'm missing it?
Thanks,
Brian
behaviour #1 and question #1 should not exist. any patcher, bpatcher, poly or fft in an open parent patcher should be
updated as soon as the old file is overwritten, no matter how its written and where - except you are accidentialy saving a new copy or outside the max search path.
-110
Hi,
Thanks for the quick replies!
RabidRaja...Indeed, these are abstractions and not subpatchers. I can cmd + double-click (if unlocked) or just double-click (if locked) and get a new window with the abstraction, from which I can do #2 in my first post if I like. Can you not? Running 5.0.6 under 10.5.6.
110...You are correct and this is working for me. I'm not sure how it wasn't earlier. But it seems one of the tricks here is knowing which instances you edit without overwriting the file, thereby 'disconnecting' them from the others and any changes that are made to the file. Intuition from my experience with different software than Max would point the need for an auto-naming option so that these can be differentiated...But maybe that's just me.
Thanks very much,
Brian
[quote ]Or if I'm clueless as to what an abstraction is, don't hesitate to let me know that, too! (i thought it was a patcher you save as a separate file and instantiate within a parent-patcher as an object? [/quote]
well the idea behind "abstractions" is that it is a patch which
follows the paradigm of (compiled) objects, so that it can be used like objects: first input is the main input, eventually inputs are named and descripted, and so on. furthermore their job is a "frequently asked" and not something which you only one time in your life. as a result, "abstractions" are often worth to share with others.
but all this is just common sense, not something tecnical. technically it is just a normal patch; it can be called like any other patch, works the same way, and may be anywhere in your search path in order to function.
that max does not allow you to edit patchers in patcher make absolutely sense, because of the possibilty to have more than one instance open - the "edit original" function which is accessible via contextmenu should be all you need in a situation where you really want to edit an abstraction coming from an open instances object box.
what you eventually should take into account is that when a patcher has been saved - and running copies of it are loded new - these new instances of the new version of the (sub)patcher are of course initialised (i.e. you might have lost the filter settings or whatever)
Hi,
Well, I hope I didn't mislead anyone...
If I open an abstraction from a main patch, it has brackets, as you suggest. Now I can make the abstraction modifiable by using File > Modify Read-Only (opt+cmd+M)-- It sounds like maybe this step was not something you were doing? I have no idea why it comes up read-only initially (but I'm curious if anyone cares to enlighten). Now I can unlock it and modify (cmd+E). This was the behavior of your patch for me.
So as I gather it, you need to be careful about what happens with the changes you make. if you close the abstraction window, it will ask if you want to save changes-- If you say yes, the original file on the disk and all other uses of it will be modified. If you say no, then it ends up you're editing only this instance of that abstraction, and it is "disconnected" from the original file. This means going back to that original file to make a change will NOT change this edited instance.
I guess my point of confusion (and maybe I'm not using the logic of programmer here) is that now we have 2 things that are called exactly the same thing, but they're not the same.
So, having figured that all out, my basic question was: Is there some workflow or 'rules' one would use to keep straight what's what? Like how to tell if an abstraction has been made into an independent instance by an edit or not? Or is this just not something you guys even have to think about?
I understand this is all pretty basic, but for me it's a question of getting process and a true understanding of the fundamentals.
Thanks,
Brian