# Should I Lock Scripts in Commercial Libraries?



## Mike Greene (Nov 27, 2011)

My concern with leaving scripts unlocked is if it might somehow make Realivox easier to pirate. But I'm not sure that makes any difference, since the instruments and samples are the important part, and NI is taking care of that, since I'm paying for their Player. So I kinda doubt pirates would be trying to hack my scripts since it's such a tiny piece of the pie.

I suppose another concern would be that other legit developers might steal my ideas . . . but who am I kidding? I mean, I do like to think I have some good ideas in how I've conceived my instruments, but anyone who follows this forum knows that I'm no coding genius. Heck, half the stuff in my scripts is stuff you guys have helped me with! So it's not like my "competition" (which is basically my friends) is dying to know how Mike Greene made his Expression slider.

The main reason I'm thinking I might want to leave the scripts unlocked is that if I do an update that's script related only, the user can simply plug it in without me having to involve NI. (Since I'm paying for their Player, updates would normally involve them, so time delays will be involved, not to mention hassle.)

But are there reasons I still might want to have them locked?


----------



## paoling (Nov 27, 2011)

Mike, I suggest, if you haven't already done, to use the NILS Editor and switch on the "compact variables" function with "optimize code" and so..
Apart from speeding up your code, in Kontakt, they tend to transform your well written and undestandable code in a complex assembly of strange words, that is actually quite hard to understand. If your script is very complex, this could be quite enough to protect it. 
You can anyway lock the "edit" button with another trick...
I'm sending you a PM about an info.


----------



## mk282 (Nov 27, 2011)

You're likely using resource container to put all your graphics in there, right?

Use it to put your scripts in there, too, then link the scripts in the NKIs to the script files from resource container. Why? Because then if you update the scripts, you can just repack your NKR container, and send it off to the users as an update! All NKI files using the linked scripts will be updated automagically upon the next load. Very easy!


There's also an impenetrable method of locking the scripts that prevents even pirated versions of Kontakt to unlock them.


----------



## polypx (Nov 27, 2011)

I lock my scripts not because I'm a coding genius (I'm certainly NOT), but simply because of the amount of time I spent building them. 

If anyone wants to build scripts that do what mine do, all the information is freely available in this forum. I know, because I learned how to do it from this forum. I appreciate that very much, and try to give back some small amount of knowledge here occasionally, where I can.

But the spirit of sharing technique is not the same as the spirit of plagiarism. 


Also, like mk282 says, use a Resource container, it makes updating a library much simpler. Not only the scripts, but you can use it to fix samples, change graphics, etc
even AFTER the library is encoded by NI.


----------



## Mike Greene (Nov 28, 2011)

Thanks for the input guys.

I've been using the resource container for graphics, but I think I might stick the scripts in there as well. I'm wondering if this might solve my main reason for leaving them unlocked, which is that I can do scrip updates without involving NI. Tell me if I'm understanding this correctly:

I write my script (lets call it "Main"), then save it in the Resources folder and create the Resource Container. Then in the K5 script edit window, I use "Apply from" and choose "Main" from the resource container.

I then lock the "Edit" box.

Then I make a bunch of changes to "Main" in Nils' editor and save it under the same name and create a new Resource Container with this new version of "Main." (I assume keeping the title identical is essential.)

So when I reload this instrument, will Kontakt automatically load my new version of "Main," rather than using the old saved version that was pasted into its script editor? In other words, does Kontakt always "Apply from" and replace scripts every time it opens an instrument?

If so, I can indeed have the script editor locked, because the user won't need to access it for updates. (I was going to have them manually replace the scripts.)

By the way, I know it should be easy for me to just test this rather than asking here, but I'm on a Mac and when I compile with Nils' editor and save to a text doc, it isn't readable by Kontakt for some reason. It seems Text Edit adds invisible slashes at the end of each line, so I'll have to do this part on my PC.


----------



## ScoringFilm (Nov 28, 2011)

Mike,

Correct to all your assumptions regarding script updating (i.e. as long as the file name is consistent).

Justin


----------



## Mike Greene (Nov 28, 2011)

Well, in that case, I'm lockin' these suckers! :mrgreen:


----------



## mk282 (Nov 28, 2011)

Mike Greene @ 28.11.2011 said:


> So when I reload this instrument, will Kontakt automatically load my new version of "Main," rather than using the old saved version that was pasted into its script editor? In other words, does Kontakt always "Apply from" and replace scripts every time it opens an instrument?



This is exactly correct!


There's another neat locking trick that you can do to permanently make editing unavailable to anyone, including any possible pirates. Steps involved:

1. You need to have one 100% transparent PNG image, dimensions 63x24, call it "lock.png".

2. The associated .txt file should look like so:


```
Has Alpha Channel: yes
Number of Animations: 1
Horizontal Animation: no
Vertical Resizable: yes
Horizontal Resizable: yes
Fixed Top: 0
Fixed Bottom: 0
Fixed Left: 0
Fixed Right: 0
```

3. I'm using this macro to set the height of the performance view area, and creating the locking ui_switch at the same time. You can save this as its own .txt script, then load it as a linked script in KScript via "import" keyword. Call this macro at the very beginning of the script (right after make_perfview), for example *SetHeight(350)*:


```
macro SetHeight(#height#)
	declare ui_switch ui_noopen
	set_control_par_str(get_ui_id(ui_noopen),CONTROL_PAR_PICTURE,"lock")
	set_control_par(get_ui_id(ui_noopen),CONTROL_PAR_WIDTH,64)
	set_text(ui_noopen,"")

	declare UI_HEIGHT := #height#
	declare LOCK_HEIGHT[9] := (0, 35, 71, 112, 156, 198, 240, 282, 324)

	if in_range(UI_HEIGHT,1,8)
		set_ui_height(UI_HEIGHT)
		move_control_px(ui_noopen,0,LOCK_HEIGHT[UI_HEIGHT])
	else
		if in_range(UI_HEIGHT,54,540)
			set_ui_height_px(UI_HEIGHT)
			move_control_px(ui_noopen,0,UI_HEIGHT-21)
		else
			move_control_px(ui_noopen,0,33)
		end if
	end if
end macro
```

Notice that this macro supports both set_ui_height and set_ui_height_px, depending on your #height# entry - if you enter 1-8 as a macro argument, it will use set_ui_height and appropriate values, if you enter a value from 54-540 (supports K5 too!), it will use set_ui_height_px. Also note that this macro expects you to have the image lock.png in your Resources folder. Otherwise you'll see the default ui_switch graphic instead.


Neat, huh?


----------



## Mike Greene (Nov 28, 2011)

Yes, that is a very cool and powerful trick. Even a little cruel! :mrgreen: 

Since this completely locks out the script, it might help strengthen an easy way to add watermarking. In the script, I could add:


```
declare $customer_number
declare ui_label $purchaser_id
set_text ($purchaser_id,"Licensed to:" & $customer_number)
```

$customer_number would be a unique number based on who purchased this copy.

I would position this in some out of the way place on the interface, maybe even on Tab 5. But it would still make a loud and clear statement of who purchased this copy. Heck, rather than $customer_number, I could even specify on my shopping cart page that they give me the _name_ they want displayed as purchaser.

Of course, this would mean a slightly different script (and therefore Resource Container as well) for each purchaser, but I don't think that would be that hard.


----------



## mk282 (Nov 28, 2011)

Good thinking with that. Here's the thing you could do to individually mark every user in any of the completely locked out scripts:


```
on init
	show_library_tab	{ enables the library tab }
	set_control_par_str($INST_LIB_PIC_ONE_ID,$CONTROL_PAR_PICTURE,"test_picture_one")	{ sets the top right picture }
	set_control_par_str($INST_LIB_PIC_TWO_ID,$CONTROL_PAR_PICTURE,"test_picture_two")	{ sets the bottom left picture }
	set_control_par_str($INST_LIB_COPYRIGHT_ID,$CONTROL_PAR_TEXT,"A5:90:CD:46:FF")	{ sets the copyright }
	set_control_par_str($INST_LIB_DESCRIPTION_ID,$CONTROL_PAR_TEXT,"Library description line one")
	set_control_par_str($INST_LIB_DESCRIPTION_ID,$CONTROL_PAR_TEXTLINE,"Library description line two etc.")	{ sets the library description }
end on
```

However, this would REALLY produce a lot of problems when doing updates. You would have to send out each individual update manually to every user... Pretty time consuming!


----------



## polypx (Nov 28, 2011)

That's the essential problem with watermarking, you have to compile a new product for each customer.


----------



## Mike Greene (Nov 28, 2011)

Well, hopefully I won't sell too many copies, so it won't be all that much work. Oh, wait a minute . . . 

:mrgreen:


----------



## ScoringFilm (Nov 29, 2011)

The other problem with this is that it won't work for multiscipts which leave a few pixels before x=0 therefore you can still click on the edit.


----------



## Big Bob (Nov 29, 2011)

Thanks Justin, that's good to know (I never thought to try it on MS). I hope NI doesn't decide to do something like that in the future with Instrument Scripts :( 

Rejoice,

Bob


----------



## paoling (Nov 29, 2011)

I'm wondering:

If we can import arrays from external files, and we can lock the main script...

What about a custom system to provide a "key" to the user in the form of a file with an array?

The key could be custom and could contain:
1) Some encoded numbers relative to the user.
2) A series of numbers just to say "OK, you can work!" to the main script.

The 2 numbers could be mixed together with some calculations to prevent a simple reverse-enginering of the main file.


----------



## paoling (Nov 29, 2011)

If it is possible, this method could provide a better protection than NI system. When Kontakt is cracked, every library based upon it is cracked.
But this system could really be different from a developer to an another, so the occasional cracker should study a specific solution to hack every single product.


----------



## mk282 (Nov 29, 2011)

That's a very good idea, Paoling!


----------



## paoling (Nov 29, 2011)

Thank you, mk282.

If this is possible.. let's go to work!


----------



## Big Bob (Nov 29, 2011)

Since you posted this almost an hour ago, I imagine that Mk282 already has it done :lol: 

But, aren't the .nka files open to anyone in that the Data folder contents are not compressed into the .nkr? And, doesn't this (like watermarking) require that each script be custom encoded before locking?

Maybe I'm missing something here (I often do :oops: ).

Rejoice,

Bob


----------



## paoling (Nov 29, 2011)

I don't know how array loading from file exactly works. 
From my point of view, if the library is open and not encoded by NI, this could be an alternative way to protect the library. If the library is encoded by NI I don't think they let something like this.

So when you sell the library "open", you can sell it without the key.

Then the developer should be able to provide the key for the user in a separate txt file that is custom for every user (and contains contact info and a code for enabling the instrument to work)

This solution could really be useful even to provide "demo" licenses, with a limited worktime or with some notes generated as a kind of "audiowatermark".
When you decide to register you can change the array text file, with the one provided by the developer.

Oh, this could be a successful way to protect the library only if it makes an intensive use of the scripting part. The groups are still avaiable for copying and the script can be removed, so this could work only for instruments where the samples alone are not worth the efforts of sharing the library.


----------



## Big Bob (Nov 29, 2011)

Hi Paolo,

I know I'm probably being very dense :oops: , but how do you make a 'common denominator' script without a key that then can be opened only with a custom .nka file? If only the .nka is customized for each user, how do you avoid requiring that the instrument/script also needs to contain something related the customized .nka?
It seems to me that you have to have as many variations of the script as you have of the .nka files.

For simplicity, let's just assume that we were doing something very simple like merely requiring that a number stored in the .nka *matches* a number stored in the script. I realize that one would make that more convoluted eventually (like usign some obscure mathematical relationship between these two numbers) but for now, let's deal with simple equality so we can focus in the area I'm puzzled about.

The only way I can visualize using a non-customized script (that nevertheless ends up being customized by the user in some way) would be something like requiring that the user enter a numerical code via a value-edit that then vanishes forever once a user enters his secret passcode. Is this the sort of thing you are thinking of?

Even with something like the foregoing, what is to prevent a pirate from simply copying the .nki once the passcode is entered. Then he just also copies the .nka key file you send him. Now, why won't that *pair of files *(that is the key .nka file and the saved .nki file) run for anyone he copies them for?

I still have the feeling that I'm missing something about what you are saying. Could you present a simplified example of what you are suggesting?

Rejoice,

Bob


----------



## paoling (Nov 29, 2011)

Hi Bob,

I'll make a very simple example.
Lets assume that I write in the NKA the result of this equation:

USER_ID_NUMBER*my_favourite_constant_number

The script reads that number and if it is divisible for my_favourite_constant_number it "unlocks" the functions in the patch.

The NKA is copyable, but its custom for every user. So like a simple serial code, it could eventually expose the identity of the pirate (and so discourage the piracy)

So this is not the ultimate protection, but it's a simple way to lock the identity of the user inside the program.
Paolo


----------



## Mike Greene (Nov 29, 2011)

If I'm understanding correctly, what Paolo is describing is a way for the user to watermark his copy. There would be countless unlock codes. The user would get one of these codes by email from the developer. Since it would different from the unlock code each other user gets, then once he uses it to unlock his copy, it watermarks it in the process.

It would still be easy to copy and upload to a torrent site, of course, but the added security measure is that the developer would know which user's copy is there. So it will discourage at least some purchasers from letting their friends "borrow" their copy, because they would worry what their friend might do that could get tracked back to them.

It would be nice if NI gave us some sort of built in machine variable that gave us a motherboard serial number, or hard drive size or processor speed or date stamp or *anything* that would be at least partly unique to a user's computer. Then we could write code that would personalize the unlock code specifically to that computer, and make copies useless on all (or at least most) computers other than the one we authorize it for. It would undoubtedly still be crackable, but since it would uniquely implemented on a developer by developer basis, cracks would be slow in coming.

I asked NI for this a few months ago. They were uninterested and told us our focus on piracy was misplaced and we should focus on sales and "value" instead.


----------



## Reegs (Nov 29, 2011)

Mike Greene @ Tue Nov 29 said:


> It would be nice if NI gave us some sort of built in machine variable that gave us a motherboard serial number, or hard drive size or processor speed or date stamp or *anything* that would be at least partly unique to a user's computer. Then we could write code that would personalize the unlock code specifically to that computer, and make copies useless on all (or at least most) computers other than the one we authorize it for. It would undoubtedly still be crackable, but since it would uniquely implemented on a developer by developer basis, cracks would be slow in coming.
> 
> I asked NI for this a few months ago. They were uninterested and told us our focus on piracy was misplaced and we should focus on sales and "value" instead.



But....doesn't NI service center rely on this sort of information for authorization??


----------



## Big Bob (Nov 30, 2011)

> The script reads that number and if it is divisible for my_favourite_constant_number it "unlocks" the functions in the patch.



I don't think we're on the same page here :lol: 

Evidentally you are providing only a means to perhaps trace back a copy to the legit unlocked user (but I thought that was what you guys meant by watermarking). I was thinking you wanted to render pirated copies unusable. 

It still seems to me that once I have your *generic script *plus any valid unlock key (in the nka file), that combination can be replicated without restriction and it will continue to function. So, are you talking about a single, generic script algorithm or, are you thinking of customizing each individual script some way?

Or maybe something in between like having 25 or 30 versions of the script that you distribute randomly and then you have to issue 25 or 30 .nka keys to the right recipients, or what? Apparently, I still don't have a clear picture of what you are proposing. :? 

I think what Mike is suggesting (somehow obtaining a hardware-specific piece of data) would offer more promise for making illegal copies unusable. However, the strength of most copy-protection schemes today relies on the fact that the user's hardware and a generic software product are 'tied together' by a 3rd party (inaccessible to the user). This is usually some software (or person) at the SW vendor's *website*. This 3rd party 'knows' both the product key and the license key relationship and can 'tie them' or 'sever them' as they wish.

Wouldn't it be nice if everyone was just completely honest :lol: I really tire of all the shackles I'm forced to wear because of the dishonesty of others :( Oh well, there's a 'new world' coming soon, hallelujah! :mrgreen: 

Rejoice,

Bob


----------



## paoling (Nov 30, 2011)

If the NKA is made by encoding the name in some way, maybe with numerical values for the letters of the name, the instrument could display something like "Welcome back, [NAME]"

This doesn't prevent someone to share the lib, but his name is shared too. If the name is false, I can have access to some other infos like e-mail and billing info.


----------



## Big Bob (Nov 30, 2011)

> If the NKA is made by encoding the name in some way, maybe with numerical values for the letters of the name, the instrument could display something like "Welcome back, [NAME]"



Sort of like a *Big Neon Sign *watermark :lol:


----------



## gh (Nov 30, 2011)

Hi Guys!

I have spent a couple of days on the script protection issue recently. I had - more or less - the same ideas as discussed in this thread. But - sorry to disappoint you - these measures are not secure at all. They may prevent that an unexperienced user fiddles around with the script but are no hurdle for someone with a bit deeper knowledge. For obvious reasons I will not tell how this can be done. If somebody wants more information please send me a PM.

Cheers
Günter


----------



## paoling (Nov 30, 2011)

Are you referring about removing, or changing the TXT of the invisible image that is placed over the EDIT button? 

Am I right? there're could be a trick even for preventing this.


----------



## mpalenik (Nov 30, 2011)

It seems to me that everyone is being a bit paranoid about their scripts. There's not much that any of these libraries do that's all THAT complicated. And did anybody notice by the way, whether intentional or not, the Cinebrass scripts aren't locked?

There's a lot of stuff out there that's a lot more complicated than a few simple Kontakt scripts that's given away freely, viewable by anyone, or open source.

Here are just a few of the things I routinely use that are like that:

Nwchem--a computational chemistry/quantum mechanics/molecular dynamics package. Literally thousands of man hours have gone into this package and it's open source. Anyone can download the code and view it.

Numerical recipes--These are highly optimized, efficient mathematical functions that do a lot of really neat things (finding eigen values, numerical integration, Fourier transforms, searches, etc.) Although you can purchase the book and the source code, the book is viewable online by anyone.

Linux

Granted I understand the desire to protect your work and that not every that most companies wouldn't give all of their source code away for free. But based on some of the questions on this forum--I mean, if these are the secrets you're trying to protect, well. . . some of these protection techniques seem a bit excessive. Anyone who is capable of cracking your password on a password protected script is probably more than capable of writing your script himself.


----------



## paoling (Dec 1, 2011)

I don't like when someone criticise the intentions.
Personally I'm not so much into protecting the script, since KSE compact variable function transforms the code in a so radical way, that variablese like
dniew:= ewccx+denz3 mod ce2c1
are hard to read for everyone.

What I find most interesting is to make a protection system that is like the old serial code system of thousand of shareware programs. 
But this isn't "paranoia". This is a challenge.

Look at Project Infinity by sonokinetic, the script is made by Blake Robinson. Look about how many "gimmicks" are implemented which aren't totally foreseen by the KSP language. Those where little challenges.
Don't you like the look of the tables? Why don't overlap 2 or more of them and look what's happen?
Don't you like that the instrument is going to move if you accidentally drag its background? Well, you can tassellate it of transparent sliders to prevent this irritating behaviour.
There was a thread from Big Bob about how to replicate the little popup label that shows when you move a slider in the Kontakt interface. This was a challenge!

And a challenge could be a little simple and effective way to reduce the sharing of your library.

This is the main, very interesting point of programming, forcing the software to realize and express your idea, expecially with the limited palette of tools that KSP language offer us.

If you want to say that opensource is better, that's ok. But this isn't what we're discussing here.
Apart from that, in my opinion those are the most interesting discussions here, the "solutions" that programmers find to realize their vision. Whatever vision it could be.


----------



## mpalenik (Dec 1, 2011)

paoling @ Thu Dec 01 said:


> I don't like when someone criticise the intentions.
> Personally I'm not so much into protecting the script, since KSE compact variable function transforms the code in a so radical way, that variablese like
> dniew:= ewccx+denz3 mod ce2c1
> are hard to read for everyone.
> ...


Yes, but as far as challenges go, they lie somewhere below, say, finding the eigen values of a non-hermitian matrix--or tons of other matrix opertions (which is by the way, stuff that I give away freely to people who ask for it).



> Don't you like the look of the tables? Why don't overlap 2 or more of them and look what's happen?
> Don't you like that the instrument is going to move if you accidentally drag its background? Well, you can tassellate it of transparent sliders to prevent this irritating behaviour.


I'm not really sure what the point is here.


> There was a thread from Big Bob about how to replicate the little popup label that shows when you move a slider in the Kontakt interface. This was a challenge!
> 
> And a challenge could be a little simple and effective way to reduce the sharing of your library.


How does locking a script reduce the sharing of your library?



> This is the main, very interesting point of programming, forcing the software to realize and express your idea, expecially with the limited palette of tools that KSP language offer us.
> 
> If you want to say that opensource is better, that's ok. But this isn't what we're discussing here.



That's not really the point. My point is more that anyone who is capable of breaking through the "lock script" option that Kontakt gives you is probably more than capable of writing any script your locking by himself. And anyone who doesn't know anything about programming probably won't find it useful. Most of these "challenges" aren't more than two hours of work, tops, which is really nothing when it comes to coding. These scripts aren't so valuable that they require an excessive amount of work to protect.


----------



## paoling (Dec 1, 2011)

Sorry but.. In this particular area of the forum there's often someone that assumes that he is more competent than his interlocutors. I find this behaviour quite irritating, since most of us tends to keep some of his discoveries as a secret in KSP and others, like the good Bob and Evildragon, likes to share their knowledge with the others.

If you read carefully we're not talking only about script locking, but also about the possibility to implement a light "watermarking" option using arrays and so.

Who are you to decide how much a script is valuable? I can't really stand those kind of statements. 

If someone asks for the solution of a problem, the best answer is giving him the solution, not questioning about the effective usefulness of what he's asking.


----------



## paoling (Dec 1, 2011)

Oh, by the way. It's almost three months that I'm working on a project, that is purely based on scripting. It features legato, a custom LFO system, a preset selector, and so. It is now 3500 lines of codes, excluding the awesome math library functions by Bob. But I don't like to be obliged to show how good I am to have the rights to talk about scripting here.


----------



## Hans Adamson (Dec 1, 2011)

To equate being a computer programmer coding, with the musicianship and deeper understanding of musical instruments needed to write meaningful instrument scripts in Kontakt shows a lack of understanding of the complexity of the task. Conceptualizing an instrument script is a totally different skill and talent than to write code on spec. No matter how crude a developer script may seem to a computer programmer, the quality of the script lies first in the understanding of the instrument emulated and how it is applied in the script. Not in the script code itself. I'd say protect your script any way you can. (o) 
/Hans


----------



## germancomponist (Dec 1, 2011)

Hans Adamson @ Thu Dec 01 said:


> To equate being a computer programmer coding, with the musicianship and deeper understanding of musical instruments needed to write meaningful instrument scripts in Kontakt shows a lack of understanding of the complexity of the task. Conceptualizing an instrument script is a totally different skill and talent than to write code on spec. No matter how crude a developer script may seem to a computer programmer, the quality of the script lies first in the understanding of the instrument emulated and how it is applied in the script. Not in the script code itself. I'd say protect your script any way you can. (o)
> /Hans



+100!


----------



## masonroza (Dec 1, 2011)

Hi guys,

I'm sure my response will raise a lot of complains and even punches but seriously, information is already incredibly sparse on the internet as well as even in this forum regarding Kontakt scripting. A lot of people on this list are desperately fishing for information and then I'm surprised that when they reach a certain point they do everything possible to hide the knowledge they gained...

I know this thread has evolved into a watermarking conversation and I understand protecting your IP but when it's about scripts they are (most of the times) tightly tied to the nki and the way the kontakt instrument is built. So plagiarism is not an option since you can't simply copy/paste a script expecting it to work. You would probably spend a big amount of time trying to figure out how it works first (that is if you can understand it) and how the nki is built.

I just think that in an industry of 10-20 developers (if that) and a handful of scripters, having an open source community could benefit each other. It's not like everyone is trying to create the same instrument so they can share code(and even if they do so what?) HOw many of you trying to create the same stuff over and over re-inventing the wheel every time?. We could all learn from each other and build on each others work to create really astonishing Kontakt instruments. And locking the scripts or not really has nothing to do with pirating(which I am completely against)

Maybe I'm a rare romantic but didn't we all learn from all the NI scripts that were unlocked? Or from Big Bob's posts and his incredible math library? Or from various post in this forum generous enough to post big scripts (Evil Dragon's, Dynamitec' posts etc? 

Mike and paoling, I was actually looking forward to try to understand your code and see how all the questions you asked in this forum would translate (if you were to keep it unlocked). After all you are (maybe were) one of the people that were trying to understand KSP and you managed to create scripted legato and other great structures(I'm guessing)! But now it will be obfuscated and locked...

Anyway, I'm sure people will hate m opinion, let the punches begin, I'll roll with them...


----------



## Mike Greene (Dec 1, 2011)

I go both ways when it comes to whether my scripts should be locked. (Which was the original purpose of this thread. I couldn't decide which way to go.)

You make some good points about why scripts should be open. If fact, even if I do lock my scripts (and for the purpose of watermarking, it looks I will,) if Big Bob or Dan or Mario or just about anyone on this forum asked me if they could see my scripts, I'd gladly send them to them. No question. (Heck, I'd be flattered!)

But at the same time, I have put a lot of work into these scripts, and I'd have to think about whether I'd want to share them with just _anybody._ 

There's something I often tell my commercial and TV clients when they think my job is easy and they pay me too much. _"You're not paying for what you're hearing. You're paying for what you're *not* hearing."_ Meaning they don't hear all the ideas I didn't use, but still spent time exploring. They're not hearing the singers who *didn't* nail the jingle, but who I had to pay anyway. They're not hearing the mix I completely scrapped because it just wasn't grooving.

It's very analogous to scripting. All told, my Realivox scripts (there are three tabs) total out to maybe 6,000 lines. Yet I've probably written 10,000 or 20,000 lines that are on the cutting room floor. So if someone else comes along and "sees how I did it," they'll undoubtedly be convinced that there's nothing complicated there. It's like a math problem. It's simple when you see the solution. Not so simple if you have to solve it yourself.

The scary part is if they decide this would be perfect for _their_ application. After all, Realivox isn't the first or last library that's essentially just a number of different articulations with sampled legato intervals. A violin library could substitute "vibrato" for "ooo" and substitute "sordino" for "ahh" and substitute "pizzicato" for "bop" (funny how our non-legato articulations correspond perfectly) and away they go. Heck they could keep my "Articulation/Keyswitch Assignment" tab exactly as is, changing nothing but the names in the string array. Again, bypassing all the snags I had to figure out. (I thought that "Articulation/Keyswitch Assignment" tab would take a few hours. It took 1800 lines and two hard weeks.)

And then there's my vibrato array. I spent hours and hours plotting by hand the values that a singer's natural pitch does during vibrato. Those values are now in a nice easy array that, quite frankly, I'd be more than a little reluctant to just give away to the next person who's going to make a vocal library to compete with mine.

Don't get me wrong, I appreciate where you're coming from and I like the utopian idea of all of us working together and sharing. Truth be told, if it were just an amateur who wanted to incorporate my scripts into his own private project, I'd be more than happy to let him. Why make him suffer with all the same wrong turns I had to take? But there *are* people planning to compete with me on a professional level. So while I'm happy to offer advice and answers (when I can) on this forum, even with a competitor, I'm hesitant to share a script wholesale.

Kind of like how I often share advice on getting gigs on other parts of this forum, but I stop short of opening my Rolodex and telling them which of my clients appreciate a bottle of wine on their birthday. :mrgreen:


----------



## paoling (Dec 1, 2011)

@masonroza
Well. 
You are reversing the thread towards a more peaceful route, but anyway no one was going to punch you..!

I'm trying to balance my posting in this forum between asking and contribution, in order to contribute to the general knowledge of KSP tricks.
I can say that my scripts are 95% fruit of my thinking and the rest is derived by the whole tricks I learnt from the others. So I don't think I need to share the code I produced to thank those people. 

Your wish of an open community of scripters who share their ideas is another part of the question. Every opensource community is made by people who wants to share some part of their knowledge; they are not obliged to share every possibile information to the community. In other words, you decide what to share. 

I shared some parts of the scripts I'm working on; mostly the parts that are more useful to someone else. I decide what to share. This is the right way to keep a community of shared knowledge. We aren't so many, so this couldn't be enough for someone else to learn to programming, but among us there are not so many secrets that we don't want to share.

If Mike asks: "Hi, guys, shall I protect my scripts?" the reason is that he trust in this community and he is doubting about the people outside here.

You mentioned Cinebrass script. Well I don't have it, but Mike some posts ago told that they take piracy issues in great consideration and they watermark and protect their library for this reason.
Do you condemn this behaviour?

If you want to see how our quesions here translate into the final product, if you really care about it, you just have to wait until the products are released. 
The final end user product is the answer to your question, not the scripted code behind that.


----------



## wst3 (Dec 1, 2011)

I've only recently started to study KSP - I have no idea if I'll ever use it, but I have been a programmer on and off for a long time, so if I might add a point on the open source part of the debate...

Open Source is tricky business. As has been said, an open source community has to show respect for it's members... that's where the bit about not always sharing everything comes in.

When you lose that, you lose the community, or some members of it anyway.

This has happened many times in the Linux community, but it seems to have the inertia to survive... but not without the loss of some fairly good hardware vendors.

Seems some of the open source folks felt that it was not right to hold back some of your secrets. And they attacked hardware vendors that would not provide all the details behind the hardware so that anyone could write a driver.

In utopia that's probably a valid request, here on earth, well, it's not.

Hardware or software - if you've found something clever, and it provides you with a competitive edge, well good for you. If you want to share other parts of your work, well, good for you again.

Ultimately it comes down to showing respect for the other members of the community.

Fortunately, most of the time that seems to be the case here - absent the occasional stumble over language differences, or even just the difficulty of communicating on line!

To answer the actual question posed - Mike, I think that if you even think you should lock your scripts then you need to trust your instincts! I especially enjoyed your comparison to composing - and you are absolutely correct, most solutions look easy - after they they are solved.

You will always have the opportunity to share your results with others... locking the script doesn't take that away.

The only caution I'd add is don't go crazy trying to implement it. Don't spend more time trying to protect the code than you spent writing it - unless it's a challenge you enjoy.

And as usual - I'd just like to thank everyone for the wealth of information I pick up here!


----------



## moonunit (Apr 18, 2012)

I was really enjoying this thread,especially the part of locking edit buttons-Then the thread got derailed by someone saying 'scripting is not rocket science and there is no need to protect it' or something like that.
It was an interesting discussion.
The watermarking thing would be brilliant if it could work.
NI should allow developers to utilise their control centre for authorisation and they could charge for each serial number.
I have bought loads of 3rd party developer libraries-I even bought Kontakt because I wanted to run a particular 3rd party library and not one of NI's so NI should give something back to devlopers.The way I see it I bet there are loads of people like me who bought Kontakt to play some small devs library.
I don't think NI realise how important the smaller dev is to their Kontakt instrument and why Kontakt is so popular.
....forgive me I'm ranting!!!


----------



## wst3 (Apr 18, 2012)

just want to underscore that last post...

up until late last year I had not yet purchased an NI library, I bought Kontakt2 for specific 3rd party libraries, I've ugraded to Kontakt4 because some 3rd party libraries needed it (I did manage to skip Kontakt 3<G>).

Lately I have been starting to use some of the content that came with Komplete 6 and Komplete 7, and even the VSL stuff that came with Kontakt4.

But the vast majority of my Kontakt libraries were developed by 3rd parties. And it does concern me that Kontakt could end up followning GS down the tubes if they lose the developers confidence.

I think it is a lot less likely because NI is a music software company, not a one-size-fits-all audio company.


----------

