Sabina

Does anyone know if it is possible to "embed" an abstraction's instance ?

I need that the instance would be independent of the original patcher, just like the embeded bpatchers.

I would appreciate any kind of help or cue.

Does anyone know if it is possible to "embed" an abstraction's instance ?
If yes, how can I do it? 

I need that the instance would be independent of the original patcher, just like the embeded bpatchers.
I would appreciate any kind of help or cue. 

is-possible-to-embed-an-abstraction

the concept behind abtractions is that they are not embedded, hence they can be instantiated multiple times.( To embed max-code use subpatchers.)

The solution is using a project for your work instead of a simple patcher.

The abtractions used inside the project will be listed in the project window. Right/ctrl click on an item and select "make local" - don't remember the exact wording...

This will make a copy of the abstraction inside your project folder. If it comes i.e. to sharing just zip the project folder and everything is together.

Hi Sabina,
the concept behind abtractions is that they are not embedded, hence they can be instantiated multiple times.( To embed max-code use subpatchers.)
The solution is using a project for your work instead of a simple patcher.
The abtractions used inside the project will be listed in the project window. Right/ctrl click on an item and select "make local" - don't remember the exact wording...
This will make a copy of the abstraction inside your project folder. If it comes i.e. to sharing just zip the project folder and everything is together.


I right clicked on my abstraction and I could not find anything like "make local " on the popUp menu displayed.

Do you know where could I read more about the idea , or how to make it possible, talking about the idea : "This will make a copy of the abstraction inside your project folder. If it comes i.e. to sharing just zip the project folder and everything is together."? please?

Hello Jan,
Thanks for your help.
I right clicked on my abstraction and I could not find anything like "make local " on the popUp menu displayed.
did you mean "save prototype"?
Do you know where could I read more   about the idea , or how to make it possible, talking about the idea : "This will make a copy of the abstraction inside your project folder. If it comes i.e. to sharing just zip the project folder and everything is together."? please? 

The function is in the project window listing, not with the absraction.

Not in front if Max now, but you can find infos about projects in the docs.

The function is in the project window listing, not with the absraction.
Not in front if Max now, but you can find infos about projects in the docs.

I don't know anything about projects and what Jan's talking about, but if I want to make an abstraction local I just de-encapsulte it, then, while all of its contents are still selected (and making a mess of your patch!), encapsulate it again.

i would just go inside an abstraction, click the little pencil left-bottom corner to "modify read only", unlock it, copy it, and paste it in a new sub patcher... then delete the abstraction instance so i don't accidentally edit the original.

working around abstraction initialization

 recently and your post just made me realize this very simple solution for my problem. I think it will work for you as well. Just place your abstraction in your patch using:

right click > object > new view of embedded patcher

@SAK
I've been working around abstraction initialization recently and your post just made me realize this very simple solution for my problem. I think it will work for you as well. Just place your abstraction in your patch using:

bpatcher @name (abstraction-patch-name) @args (n) @embed 1 

And if you want to open it, just right click > object > new view of embedded patcher

Cheers,
Omar

I haven't been following all the details of this thread or of your other linked thread, but...

It seems like maybe what you're seeking is just the 

 object. It's useful for encapsulating portions of a patch, just as an organizational measure. The contents of the 

 are unique to that instance. And, because it's a unique instance, there's no need for arguments.

It seems like maybe what you're seeking is just the patcher object. It's useful for encapsulating portions of a patch, just as an organizational measure. The contents of the patcher are unique to that instance. And, because it's a unique instance, there's no need for arguments.

 object, which allows you to use arguments with any patcher you create. :-)

...unless you want to add a patcherargs object, which allows you to use arguments with any patcher you create. :-)

If it's a unique instance, there's really no point in using "arguments". He can just hard code the value inside the 

 to send out the messages "4" and "myatt 5" inside the 

, but you could also just code that behavior inside the 

Yes, but...
If it's a unique instance, there's really no point in using "arguments". He can just hard code the value inside the patcher. The patcherargs object will still work inside a patcher, and one can make an object like patcher 4 @myatt 5 to send out the messages "4" and "myatt 5" inside the patcher, but you could also just code that behavior inside the patcher by any other means (such as loadmess myatt 5 or loadmess 4).

 object itself, which is terrific for use in an abstraction; I'm just pointing out that a 

 is a different beast from an abstraction, and that an attempt to use typed-in arguments in a 

I'm not deprecating the patcherargs object itself, which is terrific for use in an abstraction; I'm just pointing out that a patcher is a different beast from an abstraction, and that an attempt to use typed-in arguments in a patcher object is kinda pointless.

Right. Thank you for the wise input. Sometimes, (ok, most times) the simpler the better. (and I'm not referring to ableton's instrument) 

My educated guess is that arguments in a patcher would only seem reasonable if one would need to copy the patcher object multiple times - but even then, I'm not sure what's faster.

 (and I'm sorry for taking over SAK's thread) I do need arguments because I'm creating (scripting) inlets and outlets and other objects procedurally. Perhaps I should have clarified that I'm doing that in order to make the patch versatile and be able to distribute it. This is why I went with the abstractions. (And I was having issues with initialization, where patchcords would disconnect upon opening the main patch that uses my abstraction...)

This might sound like a very basic question: can you share a patcher object other than sharing a patch with that patcher object in it? I also need to take a look at snippets. Are those shareable?

Right. Thank you for the wise input. Sometimes, (ok, most times) the simpler the better. (and I'm not referring to ableton's instrument) 
My educated guess is that arguments in a patcher would only seem reasonable if one would need to copy the patcher object multiple times - but even then, I'm not sure what's faster.

In my case (and I'm sorry for taking over SAK's thread) I do need arguments because I'm creating (scripting) inlets and outlets and other objects procedurally. Perhaps I should have clarified that I'm doing that in order to make the patch  versatile and be able to distribute it. This is why I went with the abstractions. (And I was having issues with initialization, where patchcords would disconnect upon opening the main patch that uses my abstraction...)

This might sound like a very basic question: can you share a patcher object other than sharing a patch with that patcher object in it? I also need to take a look at snippets. Are those shareable?
Edit: it was a stupid question indeed.

Is it possible to embed an abstraction?