# SIPS and Release Samples



## Big Bob (Apr 21, 2006)

-------------------------- *Introduction* ---------------------------

I'm launching this thread to start a series of technical explanations of how SIPS and K2 handle release samples. In the SIPS readme file, it was recommended that you disable release samples in some way (such as deleting them). However, there has been a lot of discussion as to what detrimental effect (if any) that might have when using the SLS with the EWQLSO library. One school of thought is that we must have those release samples (and among that group some want them attached to the 'inner notes' of a legato phrase and some only want them attached to the last note of the phrase). Another school of thought is that they shouldn't be used at all. And then, there's a lot of confusion and disagreement over the reverb issue.

Near the current end of the 'Awesome' thread, rJames asked what actually happens if he doesn't delete the release groups and he just leaves them as originally programmed. What does the SLS actually do in this situation? It turns out that the answer to that question is not very simple because it depends on several variables.

So, I think a good way to begin this thread is for me to explain just what you can expect the SLS, in concert with K2, to do with release samples (if you don't remove them).

Since this will require a rather lengthy technical presentation, I think I'll break this up into several posts to this thread. However, since you may want to post to this thread also, to preserve continuity in what I'm trying to convey I'll head each installment with *Chapter 1*, *Chapter 2*, etc. This will allow you to tell the difference between this technical presentation and various responses I might post to questions, etc. Also, if I do it this way, I won't have to keep summarizing what was said previously since you will be able to start at the beginning of this thread and read forward through all the '*Chapters*' to get the whole story.

So, look for *Chapter 1* next.

I also want to take this opportunity to thank all of you for posting so many very kind comments about SIPS. But hang in there because there are more enchancements coming soon. Some are already pretty well decided and others are in the discussion phase. When I get the list solidified for the next revision, I'll start another thread for that.

God Bless,

Bob


----------



## rJames (Apr 21, 2006)

Bob, you are too kind in giving this amount of time. I will, however, be glued to this forum for details.

My clarinets sounded fine with RTs, but as I recall, my violin test was dry until the final note. If K2 handles these RTs differently, because of programming or whatever, will I be able to reprogram them so that they will work?

And finally, as a general statement, even though SIPS creates a solo instrument, it can play 2 notes at the same time??? The legato line and (sometimes) the RT from the previous note. (that is good in my book).

OK, not so finally on the last sentence... one more unrealated question...(not only do I use colloquialisms badly, I like ellipses)

Most instruments (at least wind and brass) have "nodes", for lack of a better word, during a gliss. You know, as a trumpet is glissing up with open valves it will start maybe at a low C then gliss through a G then through the E and then smoother on up to a high C. That sounds really painful to address in a script.

Are you going there?


----------



## Hans Adamson (Apr 21, 2006)

Bob,

This is great!!

We will have our own script-writing school! I will definitely follow it.


----------



## ComposerDude (Apr 21, 2006)

Bob, thank you!


----------



## Big Bob (Apr 21, 2006)

------------------------------ *Chapter 1* --------------------------------
To facilitate this discussion, I'm going to be referring from time to time to Figures 1 through 4 in the User's Guide. So you don't have to struggle trying to display the .pdf on screen with this forum text, I suggest that you print out pages 14, 15, and 17 of the User's Guide, preferably in color, and have those pages handy during this discussion.

We are going to be concentrating on the way the SLS fades out the prior note. The SLS has two basic release modes that determine the strategy used to do this. You select one of these modes with the drop-down menu just under the RlsFade knob. For the initial discussion, I'm going to discuss how the SLS operates when the mode is set to 'Knob Setting'. Later I'll discuss what happens when the 'Key-Up/BTime' mode is selected.

When a pair of notes are played legato (ie overlapping), as soon as the 2nd note is played, the prior note begins its 'retirement'. If RlsFade is set to 100%, then the prior note fades out over the entire XTime period as shown in the bold Red curve of Figure 1. Thus, the note never ends, it just fades away. However, rather than let it consume resources, the SLS issues a note-off after the XTime period expires. But, remember that the note is silent at that point in time. Now, you may not hold the prior key down as long as XTime or you may hold it down even longer. In the 'Knob Setting' mode, the script doesn't care how long you hold the prior key and that has no influence on how fast the prior note fades out.

Now, while the script doesn't care how much you overlap the notes, *K2 does*. If you lift the prior key *before* the RlsFade period ends (remember the RlsFade period is the same as XTime when RlsFade is set to 100%), the script has to instruct K2 to defer ending the note until later when the script will issue a note-off. But when the script finishes its XTime interval and issues a note-off for the prior note, K2 moves the prior note to the release phase of its envelope and also triggers the release sample associated with this note-off. Off course at this point, since the normal sample is muted, we would likely rather not hear the release sample. To overcome this, I suppose you could diddle around with the release time counter as a volume modulator for the release sample (as described on the top ot page 131 in the K2 manual), but, you might have better control using Tod's CC11, CC12 idea.

Suppose we now set RlsFade to 25%, and for simplicity let's assume we have XTime set to 1000 ms. When the prior sample begins to fade out, it follows the bold Red curve shown in Figure 3. For the first 25% of XTime, the sample fades linearly, following along the path of the thin red line. But, when 25% of XTime has expired, the script issues a note-off. This causes the curve to change slope because the primary sample now decays in accordance with the normal sample's AHDSR Release setting. This is also the point at which K2 will trigger the release sample.

There's much more to this story but I think this is about enough for Chapter 1. So, look for Chapter 2 coming next.
--------------------------------------------------------------------------------------------

But in the meantime, for those of you who like to experiment with things, I'll suggest something that I would try (if I had the EW library). I suspect that because the instruments were setup to use release samples, that the AHDSR for the primary samòKç   7âBKç   7âCKç   7âDKç   7âEKç   7âFKç   7âGKç   7âHKç   7âIKç   7âJKç   7âKKç   7âLKç   7âMKç   7âNKç   7âOKç   7âPKç   7âQKç   7âRKç   7âSKç   7âTKç   7âUKç   7âVKç   7âWKç   7âXKç   7âYKç   7âZKç   7â[Kç   7â\Kç   7â]Kç   7â^Kç   7â_Kç   7â`Kç   7âaKç   7âbKç   7âcKç   7âdKç   7âeKç   7âfKç   7âgKç   7âhKç   7âiKç   7âjKç   7âkKç   7âlKç   7âmKç   7ânKç   7âoKç   7âpKç   7âqKç   7ârKç   7âsKç   7âtKç   7âuKç   7âvKç   7âwKç   7âxKç   7âyKç   7âzKç   7â{Kç   7â|Kç   7â}Kç   7â~Kç   7âKç   7â€Kç   7âKç   7â‚Kç   7âƒKç   7â„Kç   7â…Kç   7â†Kç   7â‡Kç   7âˆKç   7â‰Kç   7âŠKç   7â‹Kç   7âŒKç   7âKç   7âŽKç   7âKç   7âKç


----------



## Big Bob (Apr 21, 2006)

rJames @ Fri Apr 21 said:


> Bob, you are too kind in giving this amount of time. I will, however, be glued to this forum for details.
> 
> My clarinets sounded fine with RTs, but as I recall, my violin test was dry until the final note. If K2 handles these RTs differently, because of programming or whatever, will I be able to reprogram them so that they will work?
> 
> ...



Too many questions, too little time. But, I'll definitely dig out my trumpet later today and see if I can 'gliss-through some nodes', sounds like fun :razz:


----------



## rJames (Apr 21, 2006)

Bob, don't take me too literally, since I make up my own language much of the time.

When I say nodes, I am speaking of overtones that are playable with the same fingerings. You are so perceptive that I will assume you know exactly what I mean (even though I can't explain myself well).

OK, back to RTs.

I just found out why my violins were so dry sounding. The RTs are not working in that patch.

So, I'm experimenting with another patch. 

By turning off the volume of the main sample group, I can clearly hear what is happening with the RTs.

Yes, they are delayed by the XTime. I wish they weren't.

What I've been saying all along is that even though they are called release trails (or maybe they are called reverb trails) they are not releases. They are just reverb.

These term can really be interchangable here. Even though there may be some kind of tone that domes from an instrument when you stop putting air through it or come to a stop with the bow. Even though the developers may have caught that nuance in their recordings...its really about the reverb. What happens in the room.

Now even though the legato script in not "releasing" the phrase but extending it with other notes, we need to hear the RT immediately without pause. That is what would happen in reality.

I'm playing a C and make a legato jump to a D...the reverb from the C is attached to the C and NOT attached in the middle of the transition.

Is there a chance that we can get a button that will disable the offset of the not ending RTs?

Or maybe the script needs to fake Kontakt out by shooting an end of note to the RTs even though Kontakt is delaying it based on the XTime.

I will debate this until the cows come home (where did I get that one from?) the RTs need to be left alone. We can choose to lower their volume (which I do even without the script) if we want to do that. But the reverb (RT) begins when the note ends.

The optimum solution is this:

A FadeIn of the RT is directly proportional to the RlsFade time. And the RT begins at the exact moment that the RlsFade begins.


----------



## kotori (Apr 21, 2006)

Big Bob @ Fri Apr 21 said:


> Now when the script finishes its XTime interval and issues a note-off for the prior note, K2 obeys again and moves the prior note to the release phase of its envelope. Now, you might also expect that K2 would, at this point, trigger the release sample that should be associated with this note-off, but, it doesn't. Since at this point the primary sample is muted, we really wouldn't want to hear the release sample anyway so in this case it's probably good that K2 works this way.


Hi Bob,
this section made me a little confused. Sorry for not nowing all the details in the script, but I thought a note-off event that reaches the K2 engine always trigger the RTs. Of course one can delay this by using wait or ignore_event and invoke note_off at a later time. Is that what's happening here?
I thought the RTs at the time the note-off event reaches the K2 engine would be played regardless of the volume of the primary sample and of what groups have been allowed/disallowed if some group were active for the triggering note. Have you found some way around this? :???:


----------



## Thonex (Apr 21, 2006)

Wob Bob....

You're on a mission!!!  

I'm a little crazed today... but will be back on the SIPS test squad next week.

Cheers,

T


----------



## rJames (Apr 21, 2006)

The cows came home.

I can see what's happening now. No matter how hard you fight it, you will have extra volume at the beginning of the transition OR you will have a little bloom from the RT (reverb).

Because you are not ending the note, you are changing the note.

The best solution...maybe not a great one...is to mechanize the transtion to the RT.

I have been using the ADHSR to get the RT transition but the RT is offset so I am always getting a bloom. But I have taken the bloom to a reasonable place.

It the RTs were not offset and you could create a volume transition from 0 to the current setting in the same time as the RlsTime, it might work.


----------



## Big Bob (Apr 21, 2006)

rJames @ Fri Apr 21 said:


> Bob, don't take me too literally, since I make up my own language much of the time.
> 
> When I say nodes, I am speaking of overtones that are playable with the same fingerings. You are so perceptive that I will assume you know exactly what I mean (even though I can't explain myself well).
> 
> ...


Hey rJames, I don't disagree with everything you are saying (and saying and saying ... ) but I do disagree with a lot of what you are saying. However, I really don't have the time to keep on debating you on these issues. I made my position quite clear and you are entitled to disagree if you wish. But it's not productive for me to spend more time on your specific questions and areas of disagreement. Since the script (presently at least) doesn't have any special provisions for release samples, the best I can do is to tell you how the script works (which is why I started this thread in the first place). Now if you don't like the way it works, don't use it.

I will tell you this, if you really believe what you are saying then try changing the release mode to 'Key-Up/BTime' because then the release samples should play whenever you lift the prior key. That subject will be covered in Chapter 2 but it seems like you're always 'jumping the gun'. If I might make a humble suggestion to you it would be this: wait until I get done with this presentation on release samples before you get all worked up about these things. There are many things I haven't talked about yet.

Meanwhile, if you are so convinced that you understand the physics of sound generation better than I do, SIPS is provided in 'open source' form with more documentation than you could possibly expect. If you yourself are not comfortable with scripting, then try to get someone who is and who is willing to help you implement your ideas. I have enough to do with trying to improve SIPS by an orderly route based on *my* knowledge of physics. In the audio industry, there is altogether too much design by a 'cut and try' approach. I'm a retired Engineer, and so I prefer to take an engineering approach to problems. I don't know how much you know about the engineering profession, but generally, engineers are considered pretty good problem solvers. And, we don't do it by the 'seat of our pants', but rather based on our formal education in math and physics coupled with years of practical experience.

Now, if you don't like my approach to problem solving that is your privilege, but I'm not going to continue debating you on this. On the other hand, if you're patient and you can wait until I get this sorted out, you may just find that my ideas aren't so bad after all. It's up to you but, this is going to be the last long response I'm going to devote to you. I have more fun things to do.


----------



## Big Bob (Apr 21, 2006)

kotori @ Fri Apr 21 said:


> Big Bob @ Fri Apr 21 said:
> 
> 
> > Now when the script finishes its XTime interval and issues a note-off for the prior note, K2 obeys again and moves the prior note to the release phase of its envelope. Now, you might also expect that K2 would, at this point, trigger the release sample that should be associated with this note-off, but, it doesn't. Since at this point the primary sample is muted, we really wouldn't want to hear the release sample anyway so in this case it's probably good that K2 works this way.
> ...


Hi Nils,
I'm not doing anything special here, I'm afraid it's just another K2 inconsitency. If a key-up produces an RCB and you don't want to end the note yet, you can of course issue an ignore_event, which is what the SLS does. If you do issue an ignore_event, K2 will not trigger the release sample. Unfortunately, it will not trigger the release sample later either even though it's the first note-off that's not ignored. So, I'm afraid that your very logical assumption that a note-off always triggers a release group is not correct. I wish it was.

I guess it's something like this. The first RCB is your only chance to have K2 trigger the release sample. If you use ignore_event, it won't trigger but you have also lost your one an only chance. Seems kind of dumb no?

God Bless,

Bob


----------



## rJames (Apr 21, 2006)

Sorry, I thought I was giving you feedback...not arguments.

Take it as you like. 

You asked us to try some things out, I did. And then I gave feedback.

A lot of us are intelligent people, Bob. Maybe some aren't even engineers.

After following your guidance, I am hearing the slapback effect of the RTs being keyed at the end of the RlsTime. I don't like it and am giving you feedback on it.

I understand that you, Thonex and Theo had agreed that RTs won't work. I am a dissenting opinion. I tend to do that. 

I know you're not my programmer. I was just getting involved.

Geez.

This is my way and we differ.


----------



## Big Bob (Apr 21, 2006)

rJames @ Fri Apr 21 said:


> Sorry, I thought I was giving you feedback...not arguments.
> 
> Take it as you like.
> 
> ...


I said I wouldn't post any more long responses for you but here's the short version of my response. Feedback I welcome, Ideas I welcome, suggestions I welcome. Unfortunately, you have too many pre-conceived notiions that I disagree with and you keep trying to push them on me. I make it a point to try very hard to get along with everyone and I try to be patient. But, your posts, starting with the very first one to the 'awesome' thread seem to me to be very abrasive. So I guess we'll just have to agree to disagree. But, I still love you.

God Bless,

Bob


----------



## Evan Gamble (Apr 21, 2006)

I think 1 point that you are getting at Ron is something that scripting will just not be able to do on its own-when you refer to the nodes that a trumpet makes going from a G to a C and such. 

And this is noise, key clicks, lip adjustments ext. I mean listen to Rob's ww piece, all the human noise that goes in the transitions. 

There is no way to produce this noise without actually recording it. 

But by combining scripting and recorded intervals (because recorded intervals have their limitations as well)-legato programming will have great leaps and bounds. 

One thing that is possible would be recording key clicks and implementing them into scripts...just a thought.


----------



## rJames (Apr 21, 2006)

Big Bob @ Fri Apr 21 said:


> rJames @ Fri Apr 21 said:
> 
> 
> > Bob, don't take me too literally, since I make up my own language much of the time.
> ...



My self deprecating humor is supposed to negate my agressive tone. I guess that didn't work.

I too should not be responding...BUT we can work together because two heads are better than one.

I do jump the gun because I too get tired of going over the same ground.

I have worked with engineers and have found them to be great linear thinkers and once they have their beliefs, it is nearly impossible to get them to see the light.

That is the benefit that engineers get from non-linear thinkers like myself.

I did try your, "KeyUp/BTime," mode but even though your engineering based approach says that the RT should play when you lift the prior key, it doesn't.

It plays on the start of the next note. That would work fine for my purposes except that it skips the first release. So as you play a legato phrase you get 

note, note, previous RT, note, previous RT etc.

I'm not trying to be an asshole. I am and have always been trying to be helpful.

You think I'm being too aggressive, because I disagree with you.

See it any way you wish.

No response necessary.


----------



## Big Bob (Apr 21, 2006)

I decided to drop this response.


----------



## rJames (Apr 21, 2006)

Big Bob @ Fri Apr 21 said:


> I don't know how I can say it more clearly but I'll give it one more shot. This is in the Up-Key/BTime mode. As soon as you strike the 'next note' (but the first note must be there long enough to qualify as overlapping the second), you can now lift the prior key *and it will trigger the release sample*. If it isn't doing that for you I'd suggest you send it back and ask for a refund.



It doesn't work that way here. Send me my money back. (Or just test it for yourself!) Delete the main samples [or turn the volume to 0] and leave only the RTs. Sometimes the empirical method works best.



> Lot's of people disagree with me but I have no trouble getting along with them, how about you?



Yeah, name one.

{Now I'm pulling your leg because your starting to get serious}

Relax, Big Bob. We don't even need to get along. We are just comparing notes.

My tests reveal something different than your tests. Doesn't that matter to you?


----------



## Big Bob (Apr 21, 2006)

rJames @ Fri Apr 21 said:


> Big Bob @ Fri Apr 21 said:
> 
> 
> > I don't know how I can say it more clearly but I'll give it one more shot. This is in the Up-Key/BTime mode. As soon as you strike the 'next note' (but the first note must be there long enough to qualify as overlapping the second), you can now lift the prior key *and it will trigger the release sample*. If it isn't doing that for you I'd suggest you send it back and ask for a refund.
> ...



Of course it does, I was actually kidding when I said send it back and get a refund. Sometimes I have a wry sense of humor too. I must admit that I was only making a quick guess on how the Key-Up mode would affect RT. I haven't actually tested it yet. Remember that SIPS wasn't designed to work with K2's convoluted RT handling. So this kind of testing simply wasn't done. I planned to verify what I was going to say before writing Chapter 2 but you asked for something very similar to what the Key-Up might deliver. So I gave it to you off the top of my head without checking it. The problem here is that with K2, things don't always work logically. So, you have to resort to testing. I hope to have a little time soon now to run some tests and then I'll get back to you or maybe just write Chapter 2.

BTW I decided I was getting abrasive myself, so I withdrew my last post. I couldn't find a way to just delete it, so I sort of blanked it out. Sorry if I lost my cool.

God Bless,

Bob


----------



## Big Bob (Apr 21, 2006)

----------------------------------- *Chapter 2* ----------------------------------------
Now for the final installment of how the current version of SIPS can be expected to work with RTS. Chapter 1 dealt with when RSs would be played by K2 when the SLS was in the 'Knob Setting' mode. With the release mode set to the 'Key-Up/BTime' mode, things are a little different. In this mode, the script ignores the RlsFade knob and instead uses the earlier of the prior key-up, or BTime expiring, to end the 'prior' sample. This is explained in paragraphs 2 and 3 on page 16 of the manual. Refering now to Figure 3, the break-point in the prior-note fade out occurs either when you lift the prior key or when BTime expires (whichever occurs first).

Before talking about how K2 will trigger release samples in this mode, it should also be mentioned that both in this mode and in the 'Knob Setting' mode, playing a fast run will accelerate the note-offs to the prior notes. The SLS generally likes to keep only the last two notes active, so any earlier ones that are still fading (in or out) or bending, etc will be accelerated to their note off phase. *Now, please don't draw the conclusion here that the polyphony will only rise to 2 or 3 voices.* First off, SIPS solo-mode logic is designed such that each note in a legato phrase, other than the first one, activates two notes. The parent note is muted and then a child note is generated by the script so that sample-start offset can be used. The reason that the parent note is retained has to do with more K2 anomalies in how the RCB is and isn't invoked when notes end. In addition to the nearly 2:1 increase in polyphony, when fast phrases are played with long XTime and/or BTime, even though the SLS requests an early retirement of notes older than the last two, it still takes these notes a while to play the release phase of their envelopes. Thus it's quite easy to get the polyphony up to about 12 voices during very fast phrases with long crossfade time. Now, that's without any release groups. With release groups, a lot more polyphony may be needed because K2 plays all the release samples that it triggers polyphonically and earlier samples do not retire until they hit the end of the sample. You might typically expect polyphony to rise to 40 or 50 voices with fast passages and long X/BTimes. 

Now, back to the 'Key-Up/Btime' mode. When does the SLS cause K2 to trigger release samples. Well *basically*, its when you lift the prior key as I indicated earlier to rJames (in the post I withdrew if you happen to have read it). But, it's a little more involved. First off, if you have BTime set rather short, it will probably time out before you can lift the prior key. Remember that the Key-Up mode issues the note-off to the prior sample with the *earlier of*, lifting the key or BTime expiring. Also, if you play 3 or more notes very rapidly, then the accelerated retirement of the earlier notes will also accelerate the release triggers for those notes.

Now, let me emphasize that I have merely outlined the way SIPS works now and what you can expect if you don't delete the release groups. In my next installment, I'll start talking about what might be done to SIPS to provide more intelligent release triggering than K2 now does when un-aided by the script.

I should also mention that the problem is not just one of *when* to trigger release samples but also bending their pitch properly and contouring their volume as well. Tasks that will be difficult without the script helping out.
----------------------------------------------------------------------------------------

So, stay tuned for the next thrilling installment as we move on to Chapter 3 

God Bless,

Bob


----------



## Craig Sharmat (Apr 21, 2006)

looking forward to chapter 3...I will be curious to see how this now evolves. Loving the script btw.



Evan Gamble @ Fri Apr 21 said:


> One thing that is possible would be recording key clicks and implementing them into scripts...just a thought.



This can be done by simply applying keycliks either after or on a fader. they should but don't have to correlate to the note of which they came. Xfade patches with keyclicks have already been programmed by some people. No other controller was needed so it could be done at the patch level and the script applied later.


----------



## kotori (Apr 21, 2006)

Big Bob @ Fri Apr 21 said:


> Hi Nils,
> I'm not doing anything special here, I'm afraid it's just another K2 inconsistency. If a key-up produces an RCB and you don't want to end the note yet, you can of course issue an ignore_event, which is what the SLS does. If you do issue an ignore_event, K2 will not trigger the release sample. Unfortunately, it will not trigger the release sample later either even though it's the first note-off that's not ignored. So, I'm afraid that your very logical assumption that a note-off always triggers a release group is not correct. I wish it was.
> 
> I guess it's something like this. The first RCB is your only chance to have K2 trigger the release sample. If you use ignore_event, it won't trigger but you have also lost your one an only chance. Seems kind of dumb no?


Thanks for the answer. I get what you're saying, but I have trouble reproducing it with a test script. If I run note_off twice in the NCB with 0.5s between the calls and ignore it the first time in the RCB it seems that the RCB is only executed the first time but I still hear the RT the second time when the RCB is not run. This seems to run counter to what you're saying. Any ideas?
Is there any special conditions that must be true for this to happen, like only for parent notes, child notes or child notes having an unignored parent?
I'm interested in this since disallow_group strangely cannot be used to turn RT groups off, so I thought maybe invoking note_off and ignoring the event the first time around could be a workaround. Sorry to go off-topic.


----------



## Big Bob (Apr 22, 2006)

kotori @ Fri Apr 21 said:


> Big Bob @ Fri Apr 21 said:
> 
> 
> > Hi Nils,
> ...


Thanks for the answer. I get what you're saying, but I have trouble reproducing it with a test script. If I run note_off twice in the NCB with 0.5s between the calls and ignore it the first time in the RCB it seems that the RCB is only executed the first time but òL€   7ÿL€   7ÿL€   7ÿL€   7ÿL€   7ÿL   7þèL   7þéL   7þêL   7þëL   7þìL   7þíL   7þîL   7þïL   7þðL   7þñL   7þòL   7þóL   7þôL   7þõL   7þöL   7þ÷L   7þøL   7þùL   7þúL   7þûL   7þüL   7þýL   7þþL   7þÿL   7ÿ L   7ÿL   7ÿL   7ÿL   7ÿL   7ÿL‚   7ÿL‚   7ÿL‚   7ÿL‚   7ÿ	L‚   7ÿ
L‚   7ÿL‚   7ÿL‚   7ÿ L‚   7ÿL‚   7ÿL‚   7ÿL‚   7ÿL‚   7ÿL‚   7ÿL‚   7ÿL‚   7ÿLƒ   7ÿLƒ   7ÿLƒ   7ÿLƒ   7ÿL„   7ÿ L„   7ÿ!L„   7ÿ"L„   7ÿ#L„   7ÿ$L„   7ÿ%L„   7ÿ&L„   7ÿ'L„   7ÿ(L„   7ÿ)L„   7ÿ*L„   7ÿ+L„   7ÿ,L„   7ÿ-L„   7ÿ.L„   7ÿ/L„   7ÿ0L„   7ÿ1L„   7ÿ2L„   7ÿ3L„   7ÿ4L„   7ÿ5L„   7ÿ6L„   7ÿ7L„   7ÿ8L„   7ÿ9L„   7ÿ:L„   7ÿ;L„   7ÿ<L„   7ÿ=L„   7ÿ>L„   7ÿ?L„   7ÿ@L„   7ÿAL„   7ÿBL„   7ÿCL„   7ÿDL„   7ÿEL„   7ÿFL„   7ÿGL„   7ÿHL„   7ÿIL„   7ÿJL„   7ÿKL„   7ÿLL„   7ÿML„   7ÿNL„   7ÿOL„   7ÿPL„   7ÿQL„   7ÿRL„   7ÿSL…   7üÂL…   7üÃL…   7üÄL…   7üÅL…   7üÆ              òL…   7üÈL…   7üÉL†   7ü¼L†   7ü½L†   7ü¾L†   7ü¿L†   7üÀL†   7üÁL†   7ÿTL†   7ÿUL†   7ÿVL†   7ÿWL†   7ÿXL†   7ÿYL†   7ÿZL†   7ÿ[L†   7ÿ\L†   7ÿ]L†   7ÿ^L†   7ÿ_L†   7ÿ`L†   7ÿaL†   7ÿbL†   7ÿcL†   7ÿdL†   7ÿeL†   7ÿfL†   7ÿgL†   7ÿhL†   7ÿiL†   7ÿjL†   7ÿkL†   7ÿlL†   7ÿmL†   7ÿnL†   7ÿoL†   7ÿpL†   7ÿqL†   7ÿrL†   7ÿsL‡   7ÿvL‡   7ÿwL‡   7ÿxL‡   7ÿyL‡   7ÿzL‡   7ÿ{L‡   7ÿ|L‡   7ÿ}


----------



## Big Bob (Apr 22, 2006)

kotori @ Sat Apr 22 said:


> Sorry about the headache (please send that Excedrin bill to NI :wink . I really don't want to take your time Bob, so feel free to let this be and spend your time on something more important. I'm sure I'll found out the special cases myself sooner or later by testing.
> 
> Cheers,
> Nils


Hey Nils,

I hope you realize I was just kidding. BTW I sent you a couple of emails on this, one with a test script to demonstrate the behaviour I described. Wouldn;t it be nice if NI would document a complete set of rules we could follow without us having to resort to experiments from which to try to derive rules? My biggest fear in all this is will some of this stuff change with the new release (I shudder to thinkg about it).

God Bless,

Bob


----------



## Big Bob (Apr 22, 2006)

-------------------------------- *Chapter 3* ----------------------------------
Before starting the 'sure to be controversial' topic of revising SIPS to do something about RSs, I think I had better summarize the foregoing material. Since it was spread over 3 posts with a lot of intervening stuff, it may be tough reading for someone who just wants to know the bottom line.

*The question is: If I don't delete or disable my release groups, what will happen if I use the SLS? *

When playing a legato phrase, whenever a new 'inside' note is played, a process begins which will end up retiring the 'prior' note. When the prior note is retired, whether or not K2 will trigger a release sample (and when) depends on a number of factors. 

When the release mode is set to 'Key-Up/BTime', the SLS will end the prior note when the earlier of any of the following occurs: 

(1) The prior note's key is released 
(2) The BTime interval expires 
(3) Another note is added to the phrase (after the current note) 

When using the SLS in the normal release mode (ie 'Knob Setting'), the situation is similar but only two conditions apply. In this mode, the 'prior' note will be retired when the earlier of the following occurs: 

(1) The RlsFade interval expires (Interval = RlsFade*XTime) 
(2) Another note is added to the phrase (after the current note) 

For either release mode, K2 will trigger the RS when the earlier event causing the prior note to end occurs. 

I purposely left some things out of the discussion to avoid further complicating it. The sustain pedal as well as CC123 messages also have an effect on whether or when RSs will be triggered by K2. 

I think the above pretty well summarizes what I think can be expected if you don't remove the release groups. Of course I hope you realize that when release samples are triggered, they are not manipulated in anyway by the script. They are neither bent in pitch nor contoured in volume. K2 makes no provision for the script to do these things unless the script entirely takes over the process of handling the release groups. This in turn has other undesireable consequences which will be discussed in the next chapter.
-----------------------------------------------------------------------------------------------

God Bless,

Bob


----------



## Big Bob (Apr 22, 2006)

Hold everything guys!

There might be something wrong with my version of K2! I sent Nils a simple test script so we could compare results. But, it behaves differently for him than it does for me! Just a few weeks ago I found out that there is more than one version of the KSP manual and mine didn't have certain things. Now I'm beginning to wonder if I somehow missed a K2 update or something and maybe NI fixed some of these peculiar inconsistencies I've been fighting for so long?

I was just about to ask Nils what version he was running when he sent an email saying he was going to sleep (I think he's in the UK and it's around midnight there). My K2 version in 2.0.2.007 what do some of you have?

I'm beginning to feel like I might be on Candid Camera :oops: .

HEELLLP!

Bob


----------



## Thonex (Apr 22, 2006)

Big Bob @ Sat Apr 22 said:


> Hold everything guys!
> 
> There might be something wrong with my version of K2! I sent Nils a simple test script so we could compare results. But, it behaves differently for him than it does for me! Just a few weeks ago I found out that there is more than one version of the KSP manual and mine didn't have certain things. Now I'm beginning to wonder if I somehow missed a K2 update or something and maybe NI fixed some of these peculiar inconsistencies I've been fighting for so long?
> 
> ...


Actually Bob,

You bring up a good point.

I would hold off on any new updates until the new K2 is released. It's supposed to come out in By the end of the month... and they reiterated that on the NI forum... so I think they are sticking to their schedule.

T


----------



## Big Bob (Apr 22, 2006)

Yes indeed but, what's the latest version anyone has now? What is yours Andrew?


----------



## rJames (Apr 22, 2006)

Still watching the thread...

Mine is 2.02.007 I haven't paid attention to updating.


----------



## synergy543 (Apr 22, 2006)

I just checked for K2 updates the other day and 2.02.007 seems to be current. Bob, I think you're good for another week. :wink:


----------



## Big Bob (Apr 22, 2006)

I'm still hoping that Nils has a later version because Otherwise I'm baffled as to why he gets different results than I do with a very simple little test script that I sent him. Resolving this might well be crucial because it goes to the heart of the peculiar way my version of K2 triggers release samples in 'normal' mode. Nils is sleeping right now but we'll confer again tomorrow morning and after Church to see if we can resolve this. This is a very serious issue because there should be no difference like this in the first place and if it results from some unannounced update that NI made, I'll have to change a lot of things in the code to accomodate it.

Unfortunately, this is all undocumented stuff that those of us who are writing scripts have had to painstakenly ferret out by resorting to experiment. Then, after we think we have a set of rules to play the game by, we often have to warp the code to accomodate all the inconsistencies and observed behaviour. Now, if NI decides to twiddle with the innards of the KSP and the rules change (rules which they never disclosed in the first place), then lots of complex scripts like SIPS will cease to function properly. It's kind of a scary thought and while I've been looking forward with hopeful expectation for the things NI might get fixed in the pending update (such as the change_vol() function, please), I've also been dreading what might happen to the undocumented rules and interactions of the KSP (that we have counted on remaining stable).

If it turns out the Nils has some later release (or worse yet one that behaves differently but bears the same version number), Oh boy are we going to have fun.
òLÑ   8GLÑ   8HLÑ   8ILÑ   8JLÑ   8KLÑ   8LLÑ   8MLÑ   8NLÑ   8OLÑ   8PLÑ   8QLÑ   8RLÑ   8SLÑ   8TLÑ   8ULÑ   8VLÑ   8WLÑ   8XLÑ   8YLÑ   8ZLÑ   8[LÑ   8\LÑ   8


----------



## Big Bob (Apr 23, 2006)

josejherring @ Sat Apr 22 said:


> Don't know if this is any different but mine says 2.0.2.7. Created on February 10 2006. Is that the same as 2.02.007?
> 
> Jose



Wow, good question Jose. My update was released back in May of 2005 if memory serves me correctly. But it would seem like 007 and 7 should be the same (except that 007 has a license to kill :wink: ), but, with NI who knows.

I did get some feedback from Nils and he has the same version as mine (at least that's how his is identified). I only threw that last phrase in because we still haven't determined why he gets different results than I do.

Some other information coming in from Tod may point to differences in how K2 behaves standalone versus as a plug-in and further that even the plug-in may not work the same in one host as it does in another. However, this has not yet been confirmed.

Anyway, thanks for the feedback with your version number. And, I guess let's just put this thing on hold until I can get it all sorted out. I'll post when I know something definite.

God Bless,

Bob


----------



## sbkp (Apr 23, 2006)

I'd say .007 and .7(00) are two very different numbers.


----------



## Tod (Apr 23, 2006)

josejherring @ Sat Apr 22 said:


> Don't know if this is any different but mine says 2.0.2.7. Created on February 10 2006. Is that the same as 2.02.007?
> 
> Jose



Hi jose,

Are you getting your version information from the "ABOUT" located on K2 itself or are you getting it from somewhere else?

Like Bob says, mine is 2.02.007 and there is no date associated with it.


----------



## sbkp (Apr 23, 2006)

Ah, yeah...

For me, K2's dialog says 2.0.1.002. But Windows' "Version" property page says 2.0.1.2. Stoopid Windows....

:oops:


----------



## Big Bob (Apr 23, 2006)

sbkp @ Sun Apr 23 said:


> I'd say .007 and .7(00) are two very different numbers.



Hi sbkp,

I can't debate the mathematical correctness of what you're saying. However I was making the tacit assumption that the last field was something like a build number in which case leading zeros wouldn't matter, only trailing zeros (which they didn't use). But, like I say, mathematically you're absolutely right.

BTW Guys, I have some more informationon why some of us were gettiing different results as to when K2 triggered release samples. Fortunately, it looks like it hasn't got anything to do with either the version number or whether or not K2 is run standalone. Rather, the problem appears to be due to another K2 quirk in which it doesn't handle group soloing for release groups as you might expect. 

In order to be able to hear release samples playing distinctly, some of us were testing for release triggers by lowering the volume of the normal groups and others were simply soloing the release group (so we wouldn't hear the normal groups). K2 behaves differently for these two scenarios unfortunately. Since I was one of the people using the Solo method, my results differ from what you can expect when you run normally. 

As a minimum, I will have to edit my posts describing when K2 plays release samples. Everything I said about how and when the SLS issues note-offs is still correct. Only the statements about how K2 triggers release samples relative to these note-offs need some surgery. I'll post about this again after I finish testing and editing the affected posts.

Sorry for the confusion.

Bob


----------



## José Herring (Apr 23, 2006)

Yep. Windows says 2.0.2.7 but the NI logo in K2 says 2.0.2.007. Wow. That's kind of dumb.

Jose


----------



## Thonex (Apr 24, 2006)

Big Bob @ Sat Apr 22 said:


> Yes indeed but, what's the latest version anyone has now? What is yours Andrew?



2.0.2.007


----------



## ComposerDude (Apr 24, 2006)

The mysterious leading zeroes can be as simple as a C "printf()" formatting choice.

printf("Format test: %d %3d %3.3d %-3d %-3.3d\n", 7,7,7,7,7);

...produces the following output...

Format test: 7 7 007 7 007

So maybe Kontakt is printing with a leading-zero print specification, while the Windows view of the same data uses a non-leading-zero print-format specification.

-Peter


----------



## kotori (Apr 24, 2006)

ComposerDude @ Mon Apr 24 said:


> The mysterious leading zeroes can be as simple as a C "printf()" formatting choice.
> printf("Format test: %d %3d %3.3d %-3d %-3.3d\n", 7,7,7,7,7);


You couldn't have said that in any simpler way? :wink:
:lol:


----------



## sbkp (Apr 24, 2006)

Well, he left out "%03d"...


----------



## ComposerDude (Apr 24, 2006)

...and Stefan, you're right - %03d also generates "007" output, thanks!

-Peter


----------



## rJames (Apr 24, 2006)

Big Bob @ Sat Apr 22 said:


> -------------------------------- *Chapter 3* ----------------------------------
> Before starting the 'sure to be controversial' topic of revising SIPS to do something about RSs, I think I had better summarize the foregoing material. Since it was spread over 3 posts with a lot of intervening stuff, it may be tough reading for someone who just wants to know the bottom line.
> 
> *The question is: If I don't delete or disable my release groups, what will happen if I use the SLS? *
> ...



I updated to your latest SIPS legato script and now the "KeyUp/BTime" mode works as Bob has suggested.

I have a little input which is not meant to start another "war of words" nor to suggest that I am smarter than Bob.

I like the fact that the KeyUp/BTime mode allows the RT to play. I can set the attack time of the RT group to softly fade in, replacing the reverb that is now bending. (or should be bending) 

It seems that the KeyUp/BTime mode has another undesireable effect. It disables the BendUp Time. I believe the BendUp and its associated BTime is critical (at least in many cases) to a more realistic legato sound.

Not to say that anyone should program this for me alone...but my wish is that I could get the RTs to play as soon as the key comes up AND that the bend of the actual note (as opposed to the RT portion of a note) still occurs.

That would mean that the script would have to both; initiate the playing of the RT while delaying the fade out of the "first" note. I understand that on the surface this is totally illogical.

In that way, I could have the natural reverberation of the first pitch still returning its early reflections and its later reflections until time has elapsed for the natural decay of the first pitch to subside.

I am aware that while the first note is decaying the bending note will be bending its attached reverb up to a new note.

That would be the compromise in this scenario.


----------



## Big Bob (Apr 24, 2006)

Hi Ron,

My exposition thus far has not really disclosed any details of how the SLS handles bending, etc. However, the manual discusses it fairly well.



> It seems that the KeyUp/BTime mode has another undesireable effect. It disables the BendUp Time. I believe the BendUp and its associated BTime is critical (at least in many cases) to a more realistic legato sound.



This is not precisely true. The SLS continues the 'upbend ' (assuming you are going to a higher note) up to the shorter of BTime expiring or the 'prior' note going to silence and being retired by the KSP. The thing to note is that once the SLS issues a note-off to the prior note, it begins its release phase of the AHDSR thus producing the second segment of the fade-out curve depicted in Fig 4. Thus, after the break in the fade-out slope, the remaining bend time is determined by the R setting of the AHDSR. This is one reason why I suggested that you might want to increase this setting. Once the R phase is entered, the bend still continues but K2 is reducing the volume of the note according to the release time setting of the envelope. Apart from lengthening the R phase, the only other thing you can do which will allow the bend to be heard longer is to delay where the fade-out curve breaks. In the normal mode this would be determined by the RlsFade time whereas in the Key-Up/Btime mode this would be determined by when you lift the key (assuming that BTime itself is set longer).

I assume you have tried my suggestion of disabling the release groups entirely and then lengthening the R phase of the envelope for the normal samples? That didn't help at all? Are you sure that you gave it 'its day in court'? Sometimes we have to stand back and rethink things. Maybe you are just too focused on release samples. 

The only other thing I can comment on is that generally the kinds of things you are asking for would totally destroy what the script is trying to do. If I did make some of the modifications you want, it might then do what you want regarding the release samples, but you would no longer have a musical-sounding legato script.

Maybe you ought to sort of hang in there for a while until I get some energy to start Chapter 4. That's where I intend to begin a discussion of what, if anything, we can or should do to the script to handle release samples.

God Bless,

Bob


----------



## Tod (Apr 24, 2006)

rJames @ Mon Apr 24 said:


> Not to say that anyone should program this for me alone...but my wish is that I could get the RTs to play as soon as the key comes up AND that the bend of the actual note (as opposed to the RT portion of a note) still occurs.



Hi rjames,

If you really want to be able to do this with the script being the way it is at this time, I suggest you try what Theo suggested.

1. Copy the RTs "rel" group(s)in the instrument your useing. Then open a new instrument (Ctrl-N), and paste them there in the group editor (paste group(s) with samples).
2. Go back and delete the "rel" Group(s) in the original Instrument.
3. Set the new instrument up for the same midi channel.

Of course the new instrument would not contain the script. 

I know this is not ideal because it adds another instrument but at this point I think it's about the only way to get the RTs to trigger at the end of the note during the legato phrase. I haven't tried this out yet but I think it would work.

Another thing to concider. One of the big problems with useing a short "RlsFade" in the script is that it can possibly create a gap where the volume noticably decreases. Since the RTs are triggered at the end of the release fade, if you set the RlsFade to a small percentage theres always the chance that the RTs could fill in this volume gap. Hehe, I haven't tried this either but it's something to think about. :smile:


----------



## rJames (Apr 24, 2006)

Big Bob @ Mon Apr 24 said:


> Hi Ron,
> 
> My exposition thus far has not really disclosed any details of how the SLS handles bending, etc. However, the manual discusses it fairly well.
> 
> ...



New info about adding R factor in the first note ADHSR while using the KeyUp/BTime switch(Yes I read, or rather glossed through the manual but did not study it). That may be all I need for now. Too bad it will severely limit the flexiblity of the script since I will have to fix my RT Attack and my main note Release (they will be set for a particular type of legato phrase). But I think it may very well do what I want.

EW would set the Release to 0 since they planned for an immediate exchange of notes to the RT. I will experiment. Thanks.

Not only may I be too focused on release samples, I am only focused on release samples. You, Thonex and Theo are taking care of the non-RT areas, so no need for my attention.

I am becoming familiar with the detrimental effects of reverb of late. Every reverb has its own set of early, mid and later reflections. So by adding reverb, unless you have the exact microphone positioning in the exact same room, you will be adding (by increment) reflections that do not belong. (that fight)

Extra reflections just add chaos to the mix. The real reflections that are picked up in a room are tuned to that room. They all happen in a particular set of phases.

When you add artificial reverb, if is almost like (but not exactly like)adding out-of-phase signals. With finesse and great ears, you can do this well.

With VSL and other libs, you are not fighting a built in reverb. So, all the reverb reflections are built on one model (whatever you have chosen in your convolution reverb)

But I, like many owners of EWSO, depend on the "real" reverb to add to the quality of our mix. I have too many things to learn to become a great engineer. I don't have the ears, nor the tuned studio, nor the $5,000 studio monitors.

I'm just focusing on the RTs because I want to retain as pristine a level of realism as possible.

I only want one reverb in my orchestral space, if that is possible.

What you've given the community is a great addition(BIG thanks for that!!). I'm just focused on one little corner.


----------



## rJames (Apr 24, 2006)

Sorry to take so much of your time, Bob. But thanks for helping me understand exactly what the script is doing.


----------



## Big Bob (Apr 24, 2006)

Hi Ron,



rJames @ Mon Apr 24 said:


> Sorry to take so much of your time, Bob. But thanks for helping me understand exactly what the script is doing.



I don't mind trying to help as long as we don't go around in circles. From your 2nd last post, it's beginning to sound like you might be starting to come around a little more to my way of thinking :wink: . Adding reverb to individual instruments (whether when recorded with the sample) or prior to or during the main MT mixdown has always struck me as a somewhat dubious idea. If all the instruments are recorded fairly dry (and thus you aren't trying to balance them by adding more to some than others), it would seem best to defer adding reverb until the very last step when you can apply it to the whole MT orchestra. After all, that's when it gets added in the concert hall.

The hall doesn't apply the reverb to each performer individually and the composite reverb is not just the simple sum of the individual reverb that each player would be enveloped in when playing alone. This is often a very misunderstood situation but there are non-linear processes going on that make it best to get all the source sounds massaged and mixed before and then add the grand overall reverb. As always these kind of statements are qualified with IMHO.

Now I realize that what I'm saying doesn't help with the EWQLSO library, it's just for discussion. I still plan to write Chapter 4 one of these days and hopefully advance some ideas of what we might do with SIPS to help those of you that have the EW stuff and just don't want to give up your your RSs. I'm not sure where that discussion will go, but we'll see as it unfolds. 

BTW I just got some feedback from Tod after he tried my suggestion of deleting the release groups and then lengthening the R segment of the AHDSR and so far he's indicated that it did improve things a lot (it almost seems like it has to). I asked him if he would post his findings and the details of what he did because I knew that you (and maybe some others) would be interested. 

Have a great day Ron,

Bob


----------



## rJames (Apr 24, 2006)

Before my time on these forums (Northernsounds, VI) there has been a debate as to the best way to record the samples.

It will continue.

I did try lengthening the R phase, and it helped. I think that may do it.

But I have found that your script gets corrupted very often. I don't know why. Unloading it and reloading clears it right up.

It must be in the way I work since I don't hear that from anyone else.

Catch 22, you can't really work with the script on and yet the cc11 curves need to be (IMHO) very different if using the legato script.

So, I've deleted it from my project.

After a while only the RTs can be heard. Then just empty and reload.


----------



## Big Bob (Apr 24, 2006)

Hi Ron,



> But I have found that your script gets corrupted very often. I don't know why. Unloading it and reloading clears it right up.
> 
> It must be in the way I work since I don't hear that from anyone else.


There is still an open issue (see #3 in the readme file) that has not been resolved. This issue may be host dependent or it could even be a host/K2 interaction. Apart from you, the only users that have reported this kind of problem are those running Sonar as the host.

I've been working with Tod on this problem and with his setup the problem vanishes when he runs K2 standalone. This seems to suggest that it isn't caused by the MIDI stream and the KSP alone, but, possibly having to do with the 'inside' communication. Since, NI is supposed to come òMl   87HMl   87IMl   87JMl   87KMl   87LMl   87MMl   87NMl   87OMl   87PMl   87QMl   87RMl   87SMl   87TMl   87UMl   87VMl   87WMl   87XMl   87YMl   87ZMl   87[Ml   87\Ml   87]Ml   87^Ml   87_Ml   87`Ml   87aMl   87bMl   87cMl   87dMl   87eMl   87fMl   87gMm   87hMm   87iMm   87jMm   87kMm   87lMm   87mMm   87nMm   87oMm   87pMm   87qMm   87rMm   87sMm   87tMm   87uMm   87vMm   87wMm   87xMm   87yMm   87zMm   87{Mm   87|Mm   87}Mm   87~Mm   87Mm   87€Mm   87Mm   87‚Mm   87ƒMm   87„Mm   87


----------



## Nick Batzdorf (Apr 25, 2006)

Bob, when you're done with all this, would you mind making the script play breathing-in samples before the first note in a phrase?


----------



## Nick Batzdorf (Apr 25, 2006)

In case you're wondering: no - please don't answer that.


----------



## Big Bob (Apr 25, 2006)

Nick Batzdorf @ Tue Apr 25 said:


> In case you're wondering: no - please don't answer that.


Oh that's a relief! I was just grabbing my Music Encyclopedia to find out what breathing-in samples were (while simultaneously trying to figure out how I would know when it was 'just before' you were going to play the first note of a phrase


----------



## synergy543 (Apr 25, 2006)

Big Bob @ Mon Apr 24 said:


> rJames said:
> 
> 
> > But I have found that your script gets corrupted very often. I don't know why. Unloading it and reloading clears it right up.
> ...


Actually I have had this problem too. Reloading solved the problem. With one instrument its easy to do but I can envision the complications in a larger template.


----------



## José Herring (Apr 25, 2006)

What host are you using Syn?

I'm using Cubase sx3 on a PC and used the script for days on about 12 instruments without any crash.

When I first started to use the script it crashed on me once. I was trying to delete something while the script was playing. So I just make sure everything is off before I do any tweeking.

I don't think that it's a fault of the script. I notice that K2 is really buggy when your tweeking on the fly. I tried to lower the volume of some release samples while in motion. :shock: K2 emmited this wierd loud buzz, froze my entire computer with no way to turn off the buzzing sound without manually restarting. Now that's what I call a bug. When moving a knob brings your whole system down you know there's some bad code in there(k2: Love it though)

Jose


----------



## rJames (Apr 25, 2006)

We're not getting a crash or a freeze, Jose. The script just stops working.

For me, it emits no notes except for the RTs.


----------



## synergy543 (Apr 25, 2006)

josejherring @ Tue Apr 25 said:


> What host are you using Syn?
> ...
> I don't think that it's a fault of the script. I notice that K2 is really buggy when your tweeking on the fly. I tried to lower the volume of some release samples while in motion. :shock: K2 emmited this wierd loud buzz, froze my entire computer with no way to turn off the buzzing sound without manually restarting. Now that's what I call a bug. When moving a knob brings your whole system down you know there's some bad code in there(k2: Love it though)
> 
> Jose


I've just been testing the script in the K2 standalone when crashed (My Digital Sequencer 4..6.1 is currently usurped for library editing :twisted: ). It only happened once but I think I recall seeing the CPU load run away beforehand. And of course, I was tweaking at the time.

How are you guys using the script with programs?
Are you guys saving special verions of your library programs with the script or just adding it on the fly?

I first started testing script with Donnie Chrisitians Woodwinds with which it was working very nicely as the sounds I was using were dry. When I have time I'll have to build some presets for my Miroslav.

Why are there only 24 hours a day?


----------



## José Herring (Apr 25, 2006)

I add the script in on the fly. I find it doesn't work well with every patch so I'll soon make some dedicated patches.

Personally it's only stopped working on me once. So I'm not complaining.

edit: Oh by the way syn the script works beautifully on older libraries. It put in on my old AO strings and they sounded great. Now I'm looking at getting the old Miro woodwinds too.


----------



## synergy543 (Apr 25, 2006)

I also played with the EWQLSO solo violin and was quite pleased with the results. I forget if I was using the close or stage mics though. So of course it will work better with some programs than others.

Wouldn't it be great if we could have a patch exchange on VI-Control rather than each of us re-inventing the wheel each time? After all, many of us are using the same libraries and the presets should be small enough. I wonder if this could be organized?


----------



## Tod (Apr 25, 2006)

rJames @ Tue Apr 25 said:


> We're not getting a crash or a freeze, Jose. The script just stops working.
> 
> For me, it emits no notes except for the RTs.


Same thing here with Sonar and K2 set up as a VSTi. What I've found is that the script will stop playing if "play" is stopped in the middle of a legato crossfade or transition. By setting up the Start and Stop points in Sonar I can make this happen every time. If Sonar is stopped outside of the trasition period then there is no problem. When the script does freeze or stop playing, the only way I've been able to reset it is to reload the script.

Useing K2 as a DXi in Sonar dosen't seem to have this problem at least for me. I tested this quite a bit and it hasn't failed yet.

If the script is freezeing or stops playing for any of you try to see if it's primarily happening in the legato transitional phase. The more Bob has to work with the easier it will be for him to fix it.


----------



## José Herring (Apr 25, 2006)

synergy543 @ Tue Apr 25 said:


> I also played with the EWQLSO solo violin and was quite pleased with the results.



I know what you mean here. I tested it with the violin patch in the original Gold set and it transformed that patch into something remarkable. I was stunned at the difference.

Best,

Jose


----------



## rJames (Apr 25, 2006)

Tod @ Tue Apr 25 said:


> What I've found is that the script will stop playing if "play" is stopped in the middle of a legato crossfade or transition.



I agree. I haven't tested it thoroughly but I know it happens when I am working on a legato section (meaning that I am starting and stopping a lot).

I have assumed it is the same as the Sustain pedal bug as has been alluded to in some other posts.


----------



## Big Bob (May 5, 2006)

****************** New SIPS Threads ****************

This thread has kind of run its course and it also contains a lot of off-topic posts. So, I'm going to start several new threads and one of them will continue this topic. I'm also going to start a thread about planned new enhancements for the next version of SIPS and I'll also start another thread for reporting problems with SIPS. I'm hoping to use these new threads to gather information that may impact what needs to be addressed for the next release of SIPS. So, watch for the new threads and if you make any new posts, please try to put them in the thread that's most appropriate.

Thank you in advance for your cooperation.

God Bless,

Bob


----------



## JohnnyMarks (Sep 19, 2006)

Hello All,

I'm getting up to speed using SIPS legato with SISC. 

Anyone know if it would be possible to incorporate in the script (in lieu of release samples) the opening/closing of a reverb send envelope conditonally (at phrase endings, perhaps also during legato transitions)? The idea being to find a reverb that matches the samples' built-in ambience -- and bring it in only when needed.

Anyone know if it is feasible to give this a go? I'm a scripting (and K2) neophyte. All comments welcomed.

Mark


----------



## JohnnyMarks (Sep 19, 2006)

Never mind, got it sorted. 

At note on, triggering a send envelope covering the note transition period created by the script, and sending that to a convolution roughly matching the ambience of the SISS samples. Now, when using the script, the general ambience produced sits pretty well alongside SISS release sample programs...without slathering reverb over the sample bodies.

Cheers


----------



## rJames (Sep 20, 2006)

Hey, Johnny. CAn you send the modified SIPS to some of the gurus on the forum for them to give a quick look.

I'd like to try that modification.

thanks.


----------

