# Roses Have Thorns



## Big Bob (Jan 19, 2007)

We are presently enjoying an embarassment of riches with the availability of so many 'free' scripts. Some of these scripts are starting to get very sophisticated and most all of the current scripts can be very useful. But just as roses have thorns, there is a very large problem looming.

Many of the most useful scripts cannot cooperatively coexist with each other. For example, one of the most recent scripts from Nils provides the much sought after function of Mod-Wheel-controlled velocity layer crossfading. But then come the posts from script users asking if they can use this script with SIPS (or at least with the SIPS Legato Script, SLS). Unfortunately, the answer presently is no. But a larger question is could they be made to work together? The answer to that is probably yes but with the current state of affairs, the only way this can be done is by customizing both scripts with the specific idea of allowing them to work together.

But, what about the next very useful script. The way things are, chances are very good that there will be problems cascading it with the present scripts. I anticipated this state of affairs more than a year ago and I have periodically since then suggested that we try to do something about the cascaded script problem. Perhaps the time is now right for me to talk about this again, now that the level of interest is much higher.

The current situation with scripts is not too dissimilar to that of the pre_MIDI days with synthesizers. We have a lot of script writers each 'doing their own thing' without regard to any agreed-upon standard protocols that might enable smoother integration of these scripts. In addition, while NI had the foresight to provide 5 script slots, they completely dropped the ball when it comes to interscript communication and control support. Put this together with a number of inconsistencies that are script-slot dependent, and making scripts that 'play together' can be a real challenge.

Nils has recently urged NI to add some additional functions which would go a long way toward mitigating some of the problems associated with cascading scripts. But, I think that more than this will be required to do this right. What I propose is the formation of a Script Writers Association, SWA, to both hammer out some initial protocols and specs and then to function (much as the MMA functions with MIDI) as a central clearing house for assigning author codes and controlling future expansion of the specifications. Just as the development of the MIDI Specification finally broke the deadlock and made it possible for equipment from multiple manufacturers to be interconnected, our Cascaded Script Specification, CSS, might eventually make it possible (or at least a whole lot easier) to get future scripts to 'play nicely' together.

I have a number of technical ideas for how to go about developing such a spec but I think, like the MIDI spec, this thing should initially be developed by a small committee. Then, the proposal should be submitted to the general scripting community for feedback before formalizing it. If we do this right, I think we can temporarily work around the 'missing pieces' and 'inconsitencies' that we hope NI will eventually correct. However, even if that glorious day should come, the CSS should have value beyond that of a 'work-around', such that it may continue to be a useful spec.

Before I put any details of my ideas down on paper, I'd like to get some feedback as to how the rest of you feel about this concept. If most of you don't like the idea of writing scripts that would have to adhere to certain standards to be classified as compliant, then I won't expend anymore effort on this. On the other hand if enough of you feel that this concept has merit, then I'll disclose more technical details of what I have in mind.

Please let me know what you think about all this.

God Bless,

Bob


----------



## kotori (Jan 19, 2007)

Hi Bob,

If I may be completely honest I feel this talk about SWA is a bit big/formal considering that the limitations in Kontakt might not let us go all the way in any case. Why not start off discussing different ways to do this and if it turns out to be good it might establish itself as some kind of defacto standard. However I don't see much reason to make predictions about that at this stage. The big problem as I see it, and as I wrote in my feature request on NI's forum, is that dynamical changes to volume/panning/tuning is hard to pass on to regenerated versions of a note in an efficient manner.

Maybe we could start off disregarding that case and agree on some standard way to pass note-on time information about volume, panning, tuning, sample offset and release samples on/off on to following scripts. Eg. some agreed upon way of encoding this in the event parameters. I hope I don't sound negative. Maybe your plans were a lot more ambititious. Please give us some hints about what you had in mind.

Cheers,
Nils


----------



## Moonchilde (Jan 19, 2007)

I noticed the old NLXfade script interfered with Ultra TKT, I had made one of my first posts here about it actually... Anyway, since the Math Library came out, that problem is no more. Perhaps it has to do with using internal K2 functions vs mathematical functions? Bob, perhaps standardizing things around your math library will help scripts be more compatible friendly for users wanting to chain them. Posting compatibility chains in a database would be helpful too, for example...

NLXfade > Ultra TKT works, but Ultra TKT > NLXfade doesn't. Same goes for Ultra TKT and Thonex's Intelligent Round Robin, which must come before Ultra TKT in the script chain if I recall correctly... I would have to go back to one of my patches to check. 

Perhaps if everyone updates their scripts to the math library standard, things will get a lot better for people using scripts and scripters making them.


----------



## kotori (Jan 19, 2007)

Hi Moonchilde,
I think the change is more likely to be related to you using a newer version of Ultra TKT than interoperability with this new xfade script having improved :wink:. The xfade script has still improved in many areas though.

The reason my crossfade script must be loaded before Ultra TKT is because the xfade script takes in one note and out comes up to six notes (one for each velocity layer). But the pitch-change performed by Ultra TKT is not inherited by these multiple child notes so should UTKT be placed first all one would hear is transposed notes. If a script at the time it generates a note could tell Kontakt that the new note should inherit properties like volume/tuning/paning from the parent note these scripts would probably work in either order. In the feature request I posted on the NI forum I suggested exactly this: that it should be possible to connect pairs of notes so that the latter inherit all central properties of the former. Please feel free to voice some support for it if you like. This is not to say that one should twiddle ones thumbs while waiting for NI to implement this. 

Cheers,
Nils


----------



## Big Bob (Jan 19, 2007)

Hi Nils,



> If I may be completely honest I feel this talk about SWA is a bit big/formal considering that the limitations in Kontakt might not let us go all the way in any case.



Perhaps I gave the impression that the SWA would be a big deal and very formal and if so, I misled everyone. However, if I may be completely honest, I don't think it very likely that NI will add the kind of features we need to mitigate this problem (at least not for a very long time). And, until they do, I think that a cooperative standard regarding such things as interscript communication and control is our only hope of attaining any easier integration of scripts that aren't compatible as they stand or are likely to be on their own.

Just to briefly touch on the kind of thing I had in mind, I envisioned that each script writer would be assigned a unique author code and a block of script IDs that the author would assign to the various scripts he/she writes. For a given script, the author would publish a series of codes that could be used to perform various actions and to request various data. Another script writer wanting to write a script which would play well with this script would then utilize this information profitably. The idea here was to avoid sending messages to a script slot (which may change) and rather send messages to a specific script no matter where it is in the chain. Only that specific script would then respond or take action. I agree that this kind of approach would take a little more work at the front than it would to continue with various ad hoc or band-aid solutions to problems as they arise, but, it wouldn't be all that difficult and I think in the end it would pay big dividends. I should also hasten to point out that once developed, the average script writer could utilize this capability quite easily by means of 'importable' modules similar to the Math Library idea.

As far as things like utilization of the event parms, I would have proposed that these be standardized for interscript communication with the freedom to be used differently for local functions.

While I'm kind of sorry that my proposal didn't grab you more positively, I am in a way relieved because it would take a fair amount of my time up front to document all the ideas I have for doing this in a smooth and very flexible way. Since we seem to disagree on our approach to this problem and, since I would have counted on you and others to do the heavy lifting anyway, I guess I'll just sit back and let you lead :wink: .

I'll be glad to help in any way that I can but I don't see much hope for trying to solve the cascaded script problem, two scripts at a time. Obviously there is always someway that can be found to do that but having done it, will the next pair be any easier?

I guess on this one we'll just have to agree to disagree :lol: 

God Bless,

Bob


----------



## kotori (Jan 19, 2007)

Hi Bob,

Sorry if you interpreted my response as me disagreeing with you. I guess what you were proposing was just not very clear to me. And I would also like to point out that I'm not speaking for anyone more than myself so please don't attach too great importance to my words. Now I'm beginning to get a clearer picture when you talk about things like being able to order scripts freely.

But as I see it we have two different kinds of information flows: data about individual notes and script settings data. In my earlier reponses I have mostly been concentrating on the former. Maybe you were thinking more of the latter, I don't know. I think the ability to communicate settings independantly of script slots and intermediate scripts is important. However, I'm not sure I have a clear picture of exactly what scripts are typically used together and the types of problems which arise. Maybe the problem of how to encode individual note data is what concerns me most at the moment because that's what I've been dealing with.

Cheers,
Nils


----------



## Big Bob (Jan 19, 2007)

Hi Nils,

I'm going to go off the air for a while (hopefully a little) while I replace a hard drive on my computer. You've probably gone to bed by now anyway, so I'll leave you a response for your morning coffee again. If I don't you'll know I'm still fighting my computer.

God Bless,

Bob


----------



## Moonchilde (Jan 19, 2007)

Hmm, Bob, I don't have an earlier version of your Ultra TKT script anymore to do testing with. I have v 1.06 at the moment. But I have one of Nil's old crossfade scripts... and it works. So it must be the new version of Ultra TKT :( Ah well, a man can dream that math solved it all  Thank you Bob! I didn't realize it was Ultra TKT all this time that fixed it.


----------



## Big Bob (Jan 19, 2007)

Moonchilde @ Fri Jan 19 said:


> Hmm, Bob, I don't have an earlier version of your Ultra TKT script anymore to do testing with. I have v 1.06 at the moment. But I have one of Nil's old crossfade scripts... and it works. So it must be the new version of Ultra TKT :( Ah well, a man can dream that math solved it all  Thank you Bob! I didn't realize it was Ultra TKT all this time that fixed it.



Or maybe you were doing something different before? The only thing I would add is are you sure it's working OK? Which slots do you have the two scripts in?

God Bless,

Bob


----------



## Big Bob (Jan 19, 2007)

Hi Nils,

I'm still fighting my computer so I'll have to keep this short.



> But as I see it we have two different kinds of information flows: data about individual notes and script settings data. In my earlier reponses I have mostly been concentrating on the former. Maybe you were thinking more of the latter, I don't know.



I'm thinking of both of these issues and I think we can do both but, maybe I'm just being overly optimistic. I think we can send the 'individual note data' via what I'll call extended event parameters. It won't be as automatic as it would if NI were to magically implement your suggestions but I do think it can be made to work.

I'm sorry that I can't write more right now but I'll try to make another post with a little more substance as soon as I can get clear of my latest computer problems.

God Bless,

Bob


----------



## Moonchilde (Jan 19, 2007)

Big Bob @ January 19th 2007 said:


> Moonchilde @ Fri Jan 19 said:
> 
> 
> > Hmm, Bob, I don't have an earlier version of your Ultra TKT script anymore to do testing with. I have v 1.06 at the moment. But I have one of Nil's old crossfade scripts... and it works. So it must be the new version of Ultra TKT :( Ah well, a man can dream that math solved it all  Thank you Bob! I didn't realize it was Ultra TKT all this time that fixed it.
> ...



Maybe, either way things are working now and they weren't before. I'm happy, and that is all that matters at this point. For the record, I always loaded crossfade into slot 1 and Ultra TKT into slot 2, I do that for everything. Before, it seemed the cross fade would interfere with note on, because I couldn't here anything unless I moved the wheel up or down constantly, no matter the starting position.


----------



## Big Bob (Jan 20, 2007)

Hi Nils,

Sorry for the long delay in getting back on this thread but I finally got Humpty Dumpty back together again. (It's sure nice when one's computer works right  ).

I've gotten a couple of PMs indicating that NI might actually be getting near another update which could include some significant changes in such things as the slot problem and interscript communication. If these rumors are true and such an update is imminent, obviously we should hold off on trying to work around these problems. (Although I remain somewhat skeptical).

Also, after thinking about this whole thing (while I was trying to get my computer back on the air), I sort of had second thoughts about it anyway. It may not be too advisable for me to get involved in something so ambitious, considering my somewhat dubious health status.

However, if you still want to modify SIPS and XFade so that they can optionally be run together, I've had a few more thoughts on that subject that I'll be glad to share. Let me know if that's of interest.

Meanwhile, I've re-edited the Note/Release Study and Report .pdf to reflect the current thinking on the slot N thing, so I'm going to upload the latest version and drop a post about it.

Hope you have a lovely day Nils,

God Bless,

Bob


----------



## kotori (Jan 21, 2007)

Hi Bob,
I'm glad that you got it working again. 

I'm very interested in making SIPS and XFADE work together.
I think most things could be communicated through EVENT_PARs. The only thing which could be a bit tricky is the number of layers because it would be nice to be able to communicate that piece of information backwards through the script chain to SIPS. Maybe I should look up that old thread about sending things backwards... 
Or else one could let SIPS send the maximum number of notes and have XFADE stop the extra ones as I talked about earlier. I'm open to all kinds of ideas. And I think it's nice to use this example as a way to explore possible solutions to the more general case. Please let's discuss this.

I'll have a second look on your updated report as soon as I find time.
I must say that I feel much more confident about programming ksp after you made this available. :D

You have a lovely day too Bob!

Cheers,
Nils


----------



## Big Bob (Jan 22, 2007)

Hi Nils,



> I'm very interested in making SIPS and XFADE work together.
> I think most things could be communicated through EVENT_PARs. The only thing which could be a bit tricky is the number of layers because it would be nice to be able to communicate that piece of information backwards through the script chain to SIPS. Maybe I should look up that old thread about sending things backwards...



OK I'm on it. I agree that we will need bi-directional data flow but I think I already have that part pretty well gelled. As soon as I gather up all my ducks in a row, I'll whip out a rough draft proposal for how we can do this and we can then kick that around and take it from there. So for now, I guess the 'ball is in my court'.

Have a Great Day Nils (when you get up that is :wink: )

God Bless,

Bob


----------



## Moonchilde (Jan 23, 2007)

Now that there is equal power cross-fading and stuff, SIPS could possibly be improved, right? Bob mentioned cross-fade pitch bending... well perhaps we could apply that to SIPS? Instead of having a longer release trail and longer attack, we could possibly just fade the two notes together as they "tie," correct? 

I wish I could help out with the scripting, but since I can't I can only offer ideas :(


----------



## Big Bob (Jan 23, 2007)

Moonchilde @ Tue Jan 23 said:


> Now that there is equal power cross-fading and stuff, SIPS could possibly be improved, right? Bob mentioned cross-fade pitch bending... well perhaps we could apply that to SIPS? Instead of having a longer release trail and longer attack, we could possibly just fade the two notes together as they "tie," correct?
> 
> I wish I could help out with the scripting, but since I can't I can only offer ideas :(



I have a little 'back-burner' project going to convert SIPS from using the fade functions to using *change_vol *but it will probably be quite a while before that results in an update (if ever). The reason I say 'if ever' is that there are some problems with the 'new and improved', lower-noise *change_vol *function. From tests I have performed it looks like NI merely added a single-pole lowpass filter with about a 40 ms time constant. While this does reduce a lot of the noise when calling *change_vol *in a loop, it also makes the response very sluggish. It remains to be seen if the fade functions can be replaced without altering the now very-musical sound of the SLS, especially at the shorter crossover times. I'll keep everyone informed if and when I have anything to report.

God Bless,

Bob

BTW I should add that Nils is really in charge of what happens to the released version of SIPS and he may have plans other than those that I've mentioned. Since my health problems developed, I turned the baton over to him and I just sort of putter around with it a little, mostly for my own amazement :wink: .


----------



## Moonchilde (Jan 23, 2007)

What about your pitch bend idea? Basically, instead of equal power crossfading velocities, you're doing keys, right? That would require a slight mod to NLXFade?


----------



## kotori (Jan 23, 2007)

Moonchilde @ Tue Jan 23 said:


> What about your pitch bend idea? Basically, instead of equal power crossfading velocities, you're doing keys, right? That would require a slight mod to NLXFade?


It's related to what Bob wrote above. Currently we use the fade_in/fade_out functions for the note transitions, but to bend over multiple notes one probably have to perform an equal-power crossfade between each pair of notes using change_vol and Bob's math lib to make sure there are no volume dips. So this is how change_vol and it's timing problem enters the picture. 

Cheers,
Nils


----------



## Moonchilde (Jan 23, 2007)

Well, here is my idea for a pitch bend script, however you'd go about doing it.

Have a set range button like Ultra TKT. When you hold down a key, Kontakt will actually hold down 2 notes and cross fade between each based on oh say, the Pitchbend CC. When you move the pitch wheel up, it will move the root key up by one and release the previous, and hold down the next higher up note giving you a visual of the keys you're crossfading to.. Move it down and it does the opposite. The root key would always be pressed in and you'd see the cross to key fading in and out depending on how high or low you move the pitch wheel.

Confused yet?


----------



## kotori (Jan 23, 2007)

Isn't that what the PCE Bender script does? I haven't tried it for a very long time now, so I cannot really remember.


----------



## Moonchilde (Jan 23, 2007)

I don't even know of that script. I doubt it does equal power crossfading based on Bob's new stuff


----------



## Big Bob (Jan 23, 2007)

Moonchilde @ Tue Jan 23 said:


> I don't even know of that script. I doubt it does equal power crossfading based on Bob's new stuff



No it doesn't use the new Math Library but it does do equal-power crossfading between pitches using Sin/Cos and Log tables with interpolation. So it does do what you have described. The PCE is another script that was sidelined over a year ago because of the noisy change_vol function. Updating this script and incorporating it into the SIPS suite is another one of my 'back-burner' projects. Of course I should add that all these back-burner projects are what prompted me to write the KSP Math Library in the first place :wink: .

If you would like a copy of the PCE script, PM me with your email address and I'll send you the package.

God Bless,

Bob


----------



## Big Bob (Jan 25, 2007)

Thank you Benjamin,



> Thanks Bob, your Math-Library is amazing (and really easy to use)



I remember a conversation I had a long time ago with someone who said to me, "Oh I understand all about Trigonometry, but what's all this Sine and Cosine stuff you've been talking about?" :???: 

I throw that in for levity but, I don't think that creative musicians should have to tear their hair out trying to figure out how to compute trig and log functions with primitive integer arithmetic. So, when Nils added and embellished the 'import' function for his marvelous KScript Editor, I thought that a simple Math Library might eventually be very useful for our Scripting Kiddies (as Nickie always says) :wink: . 

Anyway, I'm glad to hear that some of you are finding it useful. I'm also gratified to hear that you think it's 'easy to use' because that was one of my objectives in writing it.

God Bless,

Bob


----------



## Dynamitec (Jan 25, 2007)

> I remember a conversation I had a long time ago with someone who said to me, "Oh I understand all about Trigonometry, but what's all this Sine and Cosine stuff you've been talking about?" Confused



Yes, that's absolutly true  Thanks to your great x-fade and math manuals i understand much more now! I can just say to everyone who really wants to unleash the power of KSP: read Bob's Manuals! Read everything you can get from him here 

My guitarscript can crossfade and blend different articulations. And it does polyphon legato and formant correct pitchbending. If i use all high quality settings this means that for every note i play 16 notes are triggered and crossfaded (and more . So i have a maximum of 96 voices if i play a chord on all 6 guitar strings. So far everything runs smooth, fast and without problems.


----------



## Thonex (Jan 25, 2007)

Dynamitec @ Thu Jan 25 said:


> My guitarscript can crossfade and blend different articulations. And it does polyphon legato and formant correct pitchbending. If i use all high quality settings this means that for every note i play 16 notes are triggered and crossfaded (and more . So i have a maximum of 96 voices if i play a chord on all 6 guitar strings. So far everything runs smooth, fast and without problems.


WOW :shock:


----------

