# New Control/Knob functions in K2.1 are pretty spiffy!



## Big Bob (Jun 7, 2006)

Prior to K2.1, all controls (edit boxes, knobs, etc) were labeled with the name of their corresponding variable (less the $). With K2.1, the ability to re-label controls with any text (not limited to the variable naming rules) was added. Some primitive string variables and functions were also added along with the ability to 'hide' controls at run time. Now in K2.1.1 a few more new knob functions were added that allow us to assign units and/or to display 'data' strings (instead of limiting us to just numeric data display).

Collectively, these new features can make a world of difference in the appearance and user-friendliness of our control panels. I'm attaching a couple of screenshots taken of the new control panel for V110 of SIPS. The 2nd screen shot is the main control panel for the new SLS. For examples of the 'friendlier' labeling, note that the units of XTime is now shown as ms, the units of AtkFade is shown as %, etc. The edit boxes are also 'less-cryptically' labeled. Now take a look at the Offset parameter. When Auto Mode 1 or Auto Mode 2 are selected, the knob setting has no meaning so the data display is now blanked out. When Manual or Manual + Random is chosen, then the knob data is shown in ms. Note also that the instrument range is now shown in letter-octave format instead of MIDI note number. This is made much easier than before because of the new string array functions.

The 1st screen shot is the SLS panel with the Preset Naming sub-panel open in the lower, right-hand corner. Note that the Alpha Knob data display shows the character being entered rather than a numerical value.

IMHO, all in all, the new additions to the KSP allow us to make more functional and more friendly control panels. What do you think?

God Bless,

Bob


----------



## Dynamitec (Jun 7, 2006)

Hi Bob!

It looks really great! And i looks like a lot of work! I Great to have people like you ins this community here!

BTW: Does Sips have only one page or are there more? I ask because if so i could do a skin for i, that should show the real "value" Sips will be for all Kontakt users (only if you want it, of course) I would really be glad to make a really great looking skin for it...


----------



## kotori (Jun 7, 2006)

Hi Bob
That looks really nice!


----------



## Hans Adamson (Jun 7, 2006)

Very cool interface Bob.

How can I make the script controls become part of the instrument interface rather than just shown in the script editing window? Is there a part of the manuals referring to this?


----------



## Thonex (Jun 7, 2006)

Hans Adamson @ Wed Jun 07 said:


> Very cool interface Bob.
> 
> How can I make the script controls become part of the instrument interface rather than just shown in the script editing window? Is there a part of the manuals referring to this?


Put the words "make_perfview" somewhere in your on init call.

T


----------



## kotori (Jun 7, 2006)

Hans Adamson @ Thu Jun 08 said:


> Very cool interface Bob.
> 
> How can I make the script controls become part of the instrument interface rather than just shown in the script editing window? Is there a part of the manuals referring to this?



Hi Hans,
Easy - just add the statement _make_perfview_ as the first line in 'on init'.

Cheers,
Nils


----------



## Hans Adamson (Jun 7, 2006)

Ok, thanks!

How cool!


----------



## Big Bob (Jun 7, 2006)

Dynamitec @ Wed Jun 07 said:


> Hi Bob!
> 
> It looks really great! And i looks like a lot of work! I Great to have people like you ins this community here!
> 
> BTW: Does Sips have only one page or are there more? I ask because if so i could do a skin for i, that should show the real "value" Sips will be for all Kontakt users (only if you want it, of course) I would really be glad to make a really great looking skin for it...



Hi Benjamin,

As I understand it, we can only associate a skin with an instrument not with a script. I just did the skin saying 'SIPS' to be cutsey.  Of course I suppose we could make a .tga available with the script and give the user a set of instructions for how to 'connect' the tga with those instruments that he was going to use SIPS with.

Another complication is that SIPS is a 'suite' of scripts (admittedly only two member scripts right now, the SLS and SVS). If we add make_perfview to both the SLS and SVS, I guess the last one compiled will win.

Having said all that, I'm not sure of how to answer your question as to the number of 'pages' that SIPS has. As you can see from the two screen shots I posted, the SLS has one Main Panel but the Preset Rename sub-panel can 'popup' in the lower right-hand corner. So that's sort of 1.25 views I guess. However, the SVS has its own control panel (and it also will have a Name Edit popup). I guess the answer depends on whether a user is content to always display just the SLS in performance view (or just the SVS but the SLS seems more logical). Then to set the SVS parms, the instrument will have to be 'opened' to get at the other member script tabs.

So just off the top of my head, if you wanted to make a custom skin, I guess you would make it to accomodate just the SLS for both views (ie with Edit panel open or closed). I haven't completed the new SVS panel yet anyway.

All the above is a long-winded way of saying: Sure, if you want to create a super duper skin, it's OK by me. The SLS panel(s) will probably end up just as shown in my post, ie it's very unlikely it will undergo any more changes because I'm planning to move on to the SVS now. If you do want to do this, would it help if I sent you the interim source code for the SLS? Just let me know if you want it.

God Bless,

Bob

BTW: Evidentally, you aren't too crazy about my graphic Arts effort huh :razz: 
(Just kidding :wink: )

Whoops. I forgot that there is one other view but it's not a normal one. V110 now uses an auto-import feature for transferring your presets when upgrading. If you try to downgrade or do a member cross-grade or something like that, SIPS displays a large error window instead of the normal control panel. Since this is only an exception mode, it may not matter but I thought I had better mention it.


----------



## Nickie Fønshauge (Jun 8, 2006)

Bob, first I want to thank you for your great effort. I really like your SIPS suite - it is a fine thing.

But, I find it rather annoying, that I have to choose between SLS and SVS for the performance view. Couldn't they be implemented as one script with each its own "front page" toggled with a button or menu? That would make it much easier to use.


----------



## Thonex (Jun 8, 2006)

Nickie Fønshauge @ Thu Jun 08 said:


> Bob, first I want to thank you for your great effort. I really like your SIPS suite - it is a fine thing.
> 
> But, I find it rather annoying, that I have to choose between SLS and SVS for the performance view. Couldn't they be implemented as one script with each its own "front page" toggled with a button or menu? That would make it much easier to use.



Hi Nickie,

I think Bob wrote this script before the move_control (x,0,0) hide trick was implemented.... so he wrote them as 2 scripts. I like the idea of just loading n the Legato script when I need it knowing there isn't all that extra code I won't use if I don't need the vibrato function... but who knows... maybe he'll update it all into 1 script with pages.


Cheers,

T


----------



## Nickie Fønshauge (Jun 8, 2006)

Hi Andrew,

I know it was written before move_control(x,0,0). My suggestion was for version 1.1. True, if you only need one of the scripts, there would be an extra overhead of code, but if you need both scripts, an integration into one script would make it easier to use, since you don't have to open the script rack then. And I think it should be possible to write the code in a way, so that it wouldn't require much more processor time except during initialization, if you only use one of the functions.


----------



## Big Bob (Jun 8, 2006)

Nickie Fønshauge @ Thu Jun 08 said:


> Hi Andrew,
> 
> I know it was written before move_control(x,0,0). My suggestion was for version 1.1. True, if you only need one of the scripts, there would be an extra overhead of code, but if you need both scripts, an integration into one script would make it easier to use, since you don't have to open the script rack then. And I think it should be possible to write the code in a way, so that it wouldn't require much more processor time except during initialization, if you only use one of the functions.



Hi Nickie,

This is an intriguing line of thought. There were two main reasons that I began SIPS with two scripts. One of them was (as everyone has guessed) that with K2.0 there was no way to overlay controls or make 'paged' panels, but each instrument can have 5 cascaded scripts (each with its own control panel). The 2nd reason was that I was envisioning several more major functions, each being performed by a separate script but collectively working in harmony. If we remove the first reason (by virtue of the ability to now do 'paged' panels), let's try to list the pros and cons of one combination script versus separate cascaded scripts. Here are few that I can think of off the top of my head.

Pros:
1. One master performance view.
2. Eliminate the inter-script communication workarounds.

Cons:
1. Voluminous code is harder to understand and maintain
2. Current problems with K2 editor slowing everything to a crawl during development

Con #1 would have been much more of a problem without the NL Editor which greatly helps to modularize the initial source code (if not the actual K2 code). Pro #2 may not happen if we want to retain the capability to rearrange and regroup User Presets. For example, V110 takes advantage of K2.1's double buffering for persistent variables and allows you to do a version upgrade that will automatically import User Presets. So for the upgrade process, no explicit Import/Export machinery is needed any longer. However, I have still left the ability to export one User Preset at a time to an identical script for purposes of regrouping User Presets. Without the Import/Export function, this capability would be lost.

With a little more thought, I'm sure we can come up with many more Pros and Cons so let me think about it a little. However, I think one more Con at this point is that I'm nearly done with V110 (and then I was planning on handing it off to Nils and retiring). However, if this seems to be a really desireable change to make, I would hate to palm it off on Nils. Right now Nils is very busy with many, many, other things and I for one was greatful that he offered to take over the maintenence and future development of SIPS. However, I'm sure he wasn't picturing being hit with anything quite this major right at the beginnng. So, the alternative might be for me to try to do it before releasing V110 to Nils. That's also kind of dubious because I can't do things very fast these days and I really need to reduce my workload.

So, let me cogitate this for a while and let's also see what kind of input we get from others about the ideas you've advanced.

God Bless,

Bob


----------



## Nickie Fønshauge (Jun 9, 2006)

Bob, you shouldn't put your health at risk. It is not that important. Maybe version 2.0 ... ? :smile:


----------



## Big Bob (Jun 9, 2006)

Nickie Fønshauge @ Fri Jun 09 said:


> Bob, you shouldn't put your health at risk. It is not that important. Maybe version 2.0 ... ? :smile:




After thinking about this a little more, here's my summary. There are several more functional advantages to spreading the functions among several scripts than I alluded to in my last post. Most of these issues are rather technical and I won't go into details about it here. However, the main advantage to combining the scripts would appear to be related to having a common performance view. Considering the amount of work that would be involved to merge the scripts, I'm not sure that a common perf view is worth the effort.

Morever, in the future, as the suite expands and more member scripts are added, it may become nearly impossible to keep everything in one script even from a programmatic point of view. Then there is also the very real possiblility that the KSP will not be able to handle really large scripts. With 3000+ lines of code, we're already experiencing extreme overload when the editor is open. When SIPS is fully populated with all 5 member scripts, the total coding might well reach 10,000 lines or more. If this were all combined into one big script, it might completely overload K2 (at least as things are now).

All factors being considered, including my current health state, I think I will just finish V110 pretty much as planned. However, I have another line of thought that I'll mention for the future. Currently the SLS is intended as the first script in the chain of scripts because it provides the Solo-Mode logic that is needed by all the following scripts. However, I have often thought that in the future, perhaps there should be one script in front of the SLS that would handle several generally useful tasks such as articulation switching and certain kinds of master-control functions. Now, very possibly, it could be arranged to have this 'master script' be able to 'remotely' control the panels of each following member script. So, the master script could then be the performance view panel and by means of 'panel paging' could also be used to 'pull up' any of the other panels. Then using the already-implemented, interscript data broadcasting facility, the master-script-paged panels could remotely change the actual panels for the following member scripts.

Just some food for thought for another day (sometime in the future)?

God Bless,

Bob


----------



## Dynamitec (Jun 9, 2006)

Hi Bob, hi everbody!

Here is my first skin for SIPS (i will make some more :

http://rapidshare.de/files/22646095/SIPS_SKIN.tga.html

Preview (do not use this, download the one from rapidshare due to the 'bad' quality of thise jpg):





Hope you like it.


----------



## Thonex (Jun 9, 2006)

I like it Dyn,

What would it look like in context?

Cheers,

T


----------



## Big Bob (Jun 9, 2006)

Dynamitec @ Fri Jun 09 said:


> Hi Bob, hi everbody!
> 
> Here is my first skin for SIPS (i will make some more :
> 
> ...



Hi Benjamin,

Looks very nice. I was going to download it and see what it looked like with the script but the rapidshare site is rather unfriendly. After a lot of fooling around with reading a ton of material, they refused to let me download the image without an 'access code' and I couldn't figure out what that was or how I'm supposed to get it. Help!


----------



## Frederick Russ (Jun 9, 2006)

Hey Dyn (and everybody else on the Kontakt scripting team) - if you ever need me to host images I would be more than happy to help out. Just email me the image(s) at [email protected] - its better to avoid unnecessary hurdles and bottlenecks during the creative/engineering phase of these things.


----------



## Thonex (Jun 9, 2006)

Frederick Russ @ Fri Jun 09 said:


> Hey Dyn (and everybody else on the Kontakt scripting team) - if you ever need me to host images I would be more than happy to help out. Just email me the image(s) at [email protected] - its better to avoid unnecessary hurdles and bottlenecks during the creative/engineering phase of these things.



Frederick,

You're the host with the most!!!!  

Thanks for offering.

Cheers,

T


----------



## Dynamitec (Jun 10, 2006)

Hi everybody! Now i have my own server back  

Here are two SIPS Skin for Instruments enhanced by SIPS.






Rightclick and save as (.TGA Kontakt Wallpaper):
http://www.benjaminstelzer.de/ksp/skins/sips_wood_skin.tga







Rightclick and save as (.TGA Kontakt Wallpaper):
http://www.benjaminstelzer.de/ksp/skins/sips_brushedmetal_skin.tga

Here some make_perfview examples of SIPS in use:


----------



## Big Bob (Jun 10, 2006)

Yes indeed. I like that idea too Benjamin.  Have you ever tried to use sort of a 'two-tone' design so that the upper and lower parts are even more distinct (yet complimentary of course)?


----------



## Dynamitec (Jun 11, 2006)

Hi everybody! Two more variatons!

Here are two SIPS Skin for Instruments enhanced by SIPS.







Rightclick and save as (.TGA Kontakt Wallpaper):
http://www.benjaminstelzer.de/ksp/skins/sips_wood_skin.tga







Rightclick and save as (.TGA Kontakt Wallpaper):
http://www.benjaminstelzer.de/ksp/skins/sips_brushedmetal_skin.tga






Rightclick and save as (.TGA Kontakt Wallpaper):
http://www.benjaminstelzer.de/ksp/skins/sips_wood_and_metal_skin.tga







Rightclick and save as (.TGA Kontakt Wallpaper):
http://www.benjaminstelzer.de/ksp/skins/sips_metal_and_wood_skin.tga

Here some make_perfview examples of SIPS in use:


----------



## TheoKrueger (Jun 12, 2006)

Awesome stuff Benjamin! Thanks.


----------



## kid-surf (Jun 12, 2006)

Cool thanks.......

Now can anyone tell a knuckle head (me) how to load them. :mrgreen:


----------



## Big Bob (Jun 13, 2006)

Hi Kid,



> Now can anyone tell a knuckle head (me) how to load them.



Skins are associated with instruments (rather than with scripts, per se). So assuming that you have saved an instrument with SIPS, here is *a way *to load a skin for it.

Find the folder that contains the samples for the instrument and add a sub-folder named Wallpaper. Put the .tga file in the Wallpaper folder. Then load the instrument and open the Script Editor and add this new line to the script, right after the 'on init':

make_perfview

Then press the Apply button and resave the instrument .nki. The next time you load this instrument it should display the skin. For more detail see page 5 of the 'Kontakt 2.1 Manual Addendum'.

God Bless,

Bob


----------



## synergy543 (Jun 13, 2006)

So each sample program needs its own image file? There is no way to store a universal image file? This would seem like redundant overhead.

I wonder if aliases would work?


----------



## kotori (Jun 13, 2006)

synergy543 @ Tue Jun 13 said:


> So each sample program needs its own image file? There is no way to store a universal image file? This would seem like redundant overhead.


No, you can select an image from any folder and different instruments can share the same image (although I don't know whether they will really share the same RAM once they're loaded). What Bob wrote was just a suggestion about how to organize the image files so that you can find them later on, but one can store them anywhere.


----------



## synergy543 (Jun 13, 2006)

kotori @ Tue Jun 13 said:


> No, you can select an image from any folder and different instruments can share the same image....


Thanks Kotori. 

So you I guess you could create several universal images and store them in a folder in the Kontakt main directory? Would you need to write something in the script so that each instrument looks at this universal image folder?


----------



## Thonex (Jun 13, 2006)

synergy543 @ Tue Jun 13 said:


> kotori @ Tue Jun 13 said:
> 
> 
> > No, you can select an image from any folder and different instruments can share the same image....
> ...



It gets saved with the instrument. Open then instrument editor and click on the Instrument Option tab... then click on the Instrument tab. At the bottom you will see "skins"... you can create a path there and when you save an instrument it will come up the same way.

Cheers,

T


----------



## kid-surf (Jun 13, 2006)

Thanks Bob, guys... 

You guys know everything.....


----------

