Brian H.

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?

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.

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?

best-practices-with-editing-abstractions

#2 and #3 make sense to me. If you don't save changes, you are not telling Max to instantiate a new version of your abstraction. It is still referring to the old one for things like [CMD + D].

As for #1, that sounds annoying, but I've never run into it. If you use CMD+double-click to edit the abstraction, you must be referring to a

type abstraction? That's an abstraction which is always individual. Even if 2 subpatchers have the same name, they are different subpatchers. If you save it to a file, then instantiate it as an object, then I'm not aware of a way to edit it within a separate-parent-patcher with CMD+doubleclick(if you can do this please let me know! that sounds great if the external file is just opened automatically and edited!). I'm pretty sure you'd have to open up the original file and after editing that file, it would definitely update any parent-patcher containing it which is already loaded and of course, load properly into any subsequently loaded parent-patchers. Maybe I've misunderstood but if you're using a subpatcher(the

object), then this is not really a 'modular-friendly' way of creating an abstraction.

Other than that, I don't have any problems with editing abstraction files or bpatcher-files. Max reloads all parent-patchers containing those external files instantly for me once they're saved. I'm using Max5 and MacOSX, maybe you're on something different?

As for #1, that sounds annoying, but I've never run into it. If you use CMD+double-click to edit the abstraction, you must be referring to a 

 type abstraction? That's an abstraction which is always individual. Even if 2 subpatchers have the same name, they are different subpatchers. If you save it to a file, then instantiate it as an object, then I'm not aware of a way to edit it within a separate-parent-patcher with CMD+doubleclick(if you can do this please let me know! that sounds great if the external file is just opened automatically and edited!). I'm pretty sure you'd have to open up the original file and after editing that file, it would definitely update any parent-patcher containing it which is already loaded and of course, load properly into any subsequently loaded parent-patchers. Maybe I've misunderstood but if you're using a subpatcher(the 

 object), then this is not really a 'modular-friendly' way of creating an abstraction.

Other than that, I don't have any problems with editing abstraction files or bpatcher-files. Max reloads all parent-patchers containing those external files instantly for me once they're saved. I'm using Max5 and MacOSX, maybe you're on something different?


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.

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.

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.

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.

That's weird. Test this attachment for me. When I open up tester.maxpat, I double-click on the object within which is located in the same folder as a separate abstraction. The window that comes up has brackets around the title indicating it's an instance rather than the original. When I attempt to unlock it there is no option to do so(i've never known such an option existed). Do you mean that if you click on the object in tester.maxpat here(i.e. while the patcher is locked you simply double-click on the TableLFO abstraction), and the window that pops up allows you to edit it? If so, let me know what I'm doing wrong. Or if somehow i've saved my abstraction wrong, let me know. 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? or else a bpatcher/poly/pfft type source file, etc.) (I also checked my preferences... not sure if there's something there but trying different settings doesn't seem to add that functionality for me)

[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)

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)

if that's not a technical definition, I'd say I understood all along what an abstraction is because that description fits basically what I was not-so-technically describing.

then it sounds like when Brian claims he can CMD+double-click on an instance of an abstraction and somehow end up editing the original in the instance's window, this is not actually happening?

because Roman just said that in order to do this you'd need to pull up the contextual menu(and that's the only other way I know how besides actually opening the original in the finder).

oh good, then i'm not missing something.


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.

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.

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? 

ah, sweet! you cleared it up(i wasn't using option+Cmd+M, ya learn something new everyday here!). that's going to speed up my workflow so much. thank you!

as for your abstraction question: i think the reason why it comes up read-only at first is because you would lose your place too easily if you opened up more than one of the same instance and they could all be edited. Try this: edit one instance in one window, another instance in another window, save the first, then the second. You'll end up losing your changes from the first; forcing you to choose the option to edit makes it an extra 'mentally-demarcating' task that will remind you to be aware of where you are.

As for having 2 things open which are named the same but are not the same: if I edit the instance and then I don't save, I will lose those changes when I close the parent patcher. I see it as though I am in the 'class-definition' or abstraction file to begin with but iterating through changes within a testing/debug environment which is the parent-patcher.

In other words, I don't think in terms of editing instances(changes must always be saved in order to be committed to any patcher and any changes which are committed to a patcher in these cases are committed to the original abstraction patcher/file).

but that's just my way of thinking about it... and it might not clear up your question but i hope it helps... thanks again for pointing me to a new keyboard shortcut I had completely missed!

As for having 2 things open which are named the same but are not the same: if I edit the instance and then I don't save, I will lose those changes when I close the parent patcher. I see it as though I am in the 'class-definition' or abstraction file to begin with but iterating through changes within a testing/debug environment which is the parent-patcher.
In other words, I don't think in terms of editing instances(changes must always be saved in order to be committed to any patcher and any changes which are committed to a patcher in these cases are committed to the original abstraction patcher/file).

but that's just my way of thinking about it... and it might not clear up your question but i hope it helps... thanks again for pointing me to a new keyboard shortcut I had completely missed!


Best-Practices with editing abstractions?