V.J.

If I have a patch[1] embedded in a bpatcher[2] that is emedded in a patcher, is there any way that patcher[1] could be edited (Open Original patcher) and used?

I assume that if all bpatchers were embedded in the main patch, it is then impossible for someone to open the original patch[1].

I'm trying to make an abstraction that is unable to be edited and this is my methodology. I've attached a sample patch in case my description is unclear.

embedding-bpatcher-to-make-it-unreadable

> I'm trying to make an abstraction that is unable to be edited and

> this is my methodology. I've attached a sample patch in case my

If you want to make a patch uneditable, the only thing to do is: hide 

all subpatchers and save it as collective....

VJ Manzo schrieb:
> I'm trying to make an abstraction that is unable to be edited and
> this is my methodology. I've attached a sample patch in case my
> description is unclear.

If you want to make a patch uneditable, the only thing to do is: hide 
all subpatchers and save it as collective....

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


I know how to make a standalone exe. I'm making an abstraction object that others can use in their patches. I just need to know that if I embedd a patcher in bpatcher and save it in the main patch, if there is any way that someone could edit my embedded patch.

By the looks of what I've read on these forums, the answer is no. Am I right in believing this?

> I know how to make a standalone exe. I'm making an abstraction object

> that others can use in their patches. I just need to know that if I

> embedd a patcher in bpatcher and save it in the main patch, if there

> is any way that someone could edit my embedded patch.

Others can use a collective in their patch. If you save it just as 

patch, the embedded bpatcher is there as part of it. You can open it as 

text, copy the part of the bpatcher and would have the source. Though 

anybody who would be able to do that would have less hassle to just 

reimplement you abstraction with her own ideas....

I think in general its not such a good idea to hide the source of an 

abstraction. You might underestimate the simplicity of your own 

creations. Its a different issue with complete applications. If you want 

to sell your stuff, you would have to deal with customers which would 

only buy and pay if they get the source... There is a good reason why 

Peter Castine for example offers the source code to his collection for 

any paying customer. It will broaden his customer base. If the idea you 

want to hide is something complex, anybody would likely want to hire you 

as the knowledgeable expert, even more if the source is open. If the 

idea is not complex, there is nothing to hide, every decent patcher 

But still, if you want to hide it, distribute it as collective...

You can send a patch with an embedded bpatcher to this thread, and I 

will return you the content of it as patch...

By the way, the main thing anyone would want to change with your 

bpatcher is the user interface, it would prevent the distribution of 

your abstraction completely if you would not allow this. Its the best 

VJ Manzo schrieb:
> I know how to make a standalone exe. I'm making an abstraction object
> that others can use in their patches. I just need to know that if I
> embedd a patcher in bpatcher and save it in the main patch, if there
> is any way that someone could edit my embedded patch.

Others can use a collective in their patch. If you save it just as 
patch, the embedded bpatcher is there as part of it. You can open it as 
text, copy the part of the bpatcher and would have the source. Though 
anybody who would be able to do that would have less hassle to just 
reimplement you abstraction with her own ideas....

I think in general its not such a good idea to hide the source of an 
abstraction. You might underestimate the simplicity of your own 
creations. Its a different issue with complete applications. If you want 
to sell your stuff, you would have to deal with customers which would 
only buy and pay if they get the source... There is a good reason why 
Peter Castine for example offers the source code to his collection for 
any paying customer. It will broaden his customer base. If the idea you 
want to hide is something complex, anybody would likely want to hire you 
as the knowledgeable expert, even more if the source is open. If the 
idea is not complex, there is nothing to hide, every decent patcher 
would be able to do it all herself...

You can send a patch with an embedded bpatcher to this thread, and I 
will return you the content of it as patch...

By the way, the main thing anyone would want to change with your 
bpatcher is the user interface, it would prevent the distribution of 
your abstraction completely if you would not allow this. Its the best 
way to turn down any interest to zero...

Thanks for the reply and the sound advice. I've been working on this abstraction for many months now. Its a giant patch now with two inlets and 8 outlets. I have it embedded in a bpatcher to hide its contents. When I need to implement it into a patch, I simply type in the name of the patch and I'm able to use it as if it were an external object written in C or C++ because it's in my Max file search path.

If I make it a collective, I will lose the ability to let this abstraction function as an object. Am I right? What I need is a way to convert this .pat to a .mxe, but it's my understanding that the SDK only supports making mxe's from C, C++ and now Javascript.

Any suggestions? if not, I can live with it. :)

> If I make it a collective, I will lose the ability to let this

> abstraction function as an object. Am I right?

You can load it as an object, but not as something you could load into a 

bpatcher. You'd loose the UI part. The solution would be to seperate the 

UI and the function. that way you can distribute just the functional 

object as collective, and provide the UI as example. Then the user could 

load the UI patch into a bpatcher, but the internal functionality would 

be hidden within the collective... (And it would be simple for the user 

VJ Manzo schrieb:
> If I make it a collective, I will lose the ability to let this
> abstraction function as an object. Am I right?

You can load it as an object, but not as something you could load into a 
bpatcher. You'd loose the UI part. The solution would be to seperate the 
UI and the function. that way you can distribute just the functional 
object as collective, and provide the UI as example. Then the user could 
load the UI patch into a bpatcher, but the internal functionality would 
be hidden within the collective... (And it would be simple for the user 
to create her own UI...)

Thanx so much. That was a really big help.

For a while, I was looking for a way to embed an mxf, but to no avail. I appreciate the assistance.

Thanx so much. That was a really big help. 

For a while, I was looking for a way to embed an mxf, but to no avail. I appreciate the assistance.


embedding bpatcher to make it unreadable