embedding bpatcher to make it unreadable
Sorri if this is a repost...
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.
Thanx.
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?
Thanx.
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...
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
way to turn down any interest to zero...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
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. :)
Thanx.
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...)
something like this:
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
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.