# Grouping 2 or more Vol and keep relative levels?



## Tod (Apr 22, 2012)

This seems like it should be simple and probably is. I'd like to group 4 or 5 volume knobs and as I adjust one, they would all change accordingly but keep their relative db levels. The knobs control the group amplifier volumes and I'm sure this is probably a simple formula. Heh heh, well for Big Bob and some of you others.


----------



## Big Bob (Apr 23, 2012)

Hi Tod,

If I have a little time later, I'll try to suggest a way to do this. However, I think you first need to clarify a few issues. :? 

1. Are you asking that if any one of the 5 knobs are adjusted by some incremental amount, that the other four change by the same db increment?

2. If the answer to 1 is yes, then how do you propose to set the five knobs to different values in the first place?

Three possible answers to question 2 occur to me. The first is that the knobs are 'hard initialized' to different values and from there on they track incrementally. The second way, which would probably be more flexible, is to require that there be a way to optionally control when a knob change should be treated independently. For example, you could make it so that if you hold down the Alternate key when you adjust a knob that the other knobs will not be changed but when you don't hold down Alt, the other knobs would track. The 3rd way, which would be simpler than the 2nd way, would be that you set the 'different' values with the group knobs themselves and the script panel knobs always move incrementally. 

When you get a chance, please clarify what you have in mind because you may have some totally different angle for how you want it to work. :lol: 

Rejoice,

Bob

Edited.


----------



## Tod (Apr 23, 2012)

Hi my friend,

what I have are 5 knobs controlling the volume (via the Amplifier) for 5 different microphones. For the most part these will all work independently as they do now. However, there are times when it might be nice to group (or lock) 2 or 3 of the mics together to bring them up or down. Of course if they were at the same level it would be simple but in all likelihood they will be different and I would like to keep their equivalent and relative values. 

I haven't completely sorted out how I would group them yet but I'm thinking of a button for each mic along with a variable and array for flagging.



> Three possible answers to question 2 occur to me. The first is that the knobs are 'hard initialized' to different values and from there on they track incrementally.



Not sure what you mean here, I'm not familiar 'hard initialized'. Are you suggesting adjusting each subsequent grouped vol knob the same incremental amount of the knob being adjusted, only based on the subsequent grouped knobs last value? If so, I could see this working, would this keep them at relative values? This would also require an array for "Last value" but that would be simple enough.



> The second way, which would probably be more flexible, is to require that there be a way to optionally control when a knob change should be treated independently. For example, you could make it so that if you hold down the Alternate key when you adjust a knob that the other knobs will not be changed but when you don't hold down Alt, the other knobs would track.



I kinda like this idea, it would eliminate the group buttons. However, I should mention that many of the users of this know very little about DAWs and/or samplers so I'm trying to keep it as simple as possible. Heh heh, I hadn't planned on putting a manual together for it but that might not be a bad idea. Of course this would still have to have a way to keep all the knobs relative.



> The 3rd way, which would be simpler than the 2nd way, would be that you set the 'different' values with the group knobs themselves and the script panel knobs always move incrementally.



That wouldn't be practical because there are 8 round robins for each mic.

Heh heh, I don't know, I might be trying to add a can of worms to an otherwise pretty good working script. :mrgreen: 

Thankyou Bob and god bless you too.


----------



## Big Bob (Apr 23, 2012)

Hi Tod,



> what I have are 5 knobs controlling the volume (via the Amplifier) for 5 different microphones.
> 
> That wouldn't be practical because there are 8 round robins for each mic.



Combining the two above statements of yours, I'm not sure I have the correct picture any more :? 

What do these 5 microphones correspond with in terms of Kontakt groups?

I originally thought you wanted to change the volume of one group and have the other 4 (or so groups) change by the same incremental amount. Specifically, if the volume settings of 5 different groups were -12db, -6db, 0db, +6db, +3db and you then changed the -6db group knob to -2 db (up by 4 db), the group volumes would then become, -8db, -2db, +4db, +10db, and +7db respectively. If this had been what you wanted to do, I could have suggested how it could be accomplished.

Now you seem to be indicating that there are many more than five groups (since each mike has 8 RR groups assigned to it?). When you say you are changing the volume of a microphone, does this mean you are changing the volume of 8 RR groups containing samples of that microphone at the same time? Are your volume knobs something on your script panel or are you just using the K4 volume knobs? I originally presumed that your 5 volume knobs were on your script panel and that you were using engine pars to control some corresponding group amplifier.

Totally unclear at the moment what your setup actually is :lol: 

Rejoice,

Bob


----------



## Tod (Apr 23, 2012)

Big Bob @ Mon Apr 23 said:


> Hi Tod,
> 
> 
> 
> ...



I'm sorry Bob, I should have explained a little better. There are 5 mics with 8 RRs each for a totaly of 8 groups for each mic. The knobs just control the first group of each mic and the rest of the RRs for each mic are adjusted in a "while" statement or loop.



> I originally thought you wanted to change the volume of one group and have the other 4 (or so groups) change by the same incremental amount. Specifically, if the volume settings of 5 different groups were -12db, -6db, 0db, +6db, +3db and you then changed the -6db group knob to -2 db (up by 4 db), the group volumes would then become, -8db, -2db, +4db, +10db, and +7db respectively. If this had been what you wanted to do, I could have suggested how it could be accomplished.



That's it exactly. :D 



> Now you seem to be indicating that there are many more than five groups (since each mike has 8 RR groups assigned to it?). When you say you are changing the volume of a microphone, does this mean you are changing the volume of 8 RR groups containing samples of that microphone at the same time? Are your volume knobs something on your script panel or are you just using the K4 volume knobs? I originally presumed that your 5 volume knobs were on your script panel and that you were using engine pars to control some corresponding group amplifier.



Yes, like I explained above, there are 5 mics and 8 RRs per mic for a total of 40 groups. Of course the only groups the knobs need to be tied to are the first group of each mic RR. Yes, all the controls are in the script GUI. There's also Pan, select Output, Mute, and a Phase inverter.


----------



## Big Bob (Apr 23, 2012)

Hi again Tod,



> Yes, like I explained above, there are 5 mics and 8 RRs per mic for a total of 40 groups. Of course the only groups the knobs need to be tied to are the first group of each mic RR. Yes, all the controls are in the script GUI. There's also Pan, select Output, Mute, and a Phase inverter.



Ok, so if I illustrated how to do it with 5 knobs each controlling one group (not necessarily in sequence) using engine parameters would that be sufficient for you to take it from there?

Maybe before I actually post something I should warn you that it would require the use of the Math Library (specifically the converter routines *ep_to_mdb *and *mdb_to_ep*) and some indirect addressing of the knobs (some of the control id stuff). The reason I bring this up is because it sounds a little like you maybe don't want to add anything too complex to what you already have and maybe you would consider this more trouble than it's worth?

However, if you want to give it a shot, please let me know and I'll cobble something together for you. It shouldn't take me too long but I want to be sure you really want it before I invest the time. 8) 

Rejoice,

Bob


----------



## mk282 (Apr 24, 2012)

Use a "constant" modulator within Kontakt set to modulate volume of those groups (with enabled "Invert" button - this is important!). Then you can set the relative levels between mic positions with the Volume knob ($ENGINE_PAR_VOLUME), and after that you can adjust the global volume of those groups by setting the modulation amount of the "constant" modulator (using $ENGINE_PAR_MOD_TARGET_INTENSITY).


----------



## Big Bob (Apr 24, 2012)

Hi MK,

I find it hard to believe that 'modulating' each volume control by the same amount would actually produce anything like an identical db change in volume for each group regardless of their relative settings. Since each volume control follows Kontakt's 18 db/octave curve, and in general, modulators are linear in their effect. 

Look at it this way, if volume is proportional to ep^3, then if you have two volume knobs K1 and K2, their absolute volume level for a given ep could be expressed as:


```
V1 = a*K1^3   and   V2 = a*K2^3     where a is a constant
```

Now suppose that K1 is set to ep = 10000 and K2 is set to ep = 800000, if I now change both Knobs by +10000, then K1 will double (meaning V1 will go up by a factor of 8 ) but V2 will simply increase by a factor of 1.03. So, the db change in each will be very different.

So, have you actually verified that what you are proposing really works as Tod wants it to? Let me just suggest a simple experiment using only two group volume knobs. Set one of them to say -24db and the other to +3db. Now apply a common modulation amount such that the -24db volume increases to -18db (an increase of 6db). Are you saying that the +3db volume will increase to +9db? If so, that is truly remarkable! I'm sure they will both increase by *some* amount but I think their db increase will not be the *same*.

If you think they will increase by the same db amount, have you actually verified this assumption? Unfortunately, AFAIK, a modulator's effect is not displayed numerically (only graphically in terms of the mod ring), so I'm not sure how to determine accurately what the db increase in each volume setting will be (or have you found some way to accurately display the volume + modulation numerically or are you just doing it by ear)?

In any case, Tod, do you want to try MK's suggestion first before I proceed? :roll: 

Rejoice,

Bob


----------



## mk282 (Apr 24, 2012)

Big Bob @ 24.4.2012 said:


> So, have you actually verified that what you are proposing really works as Tod wants it to?



No, I just suggested an easier way out without dealing with too much math and code. 




Big Bob @ 24.4.2012 said:


> Unfortunately, AFAIK, a modulator's effect is not displayed numerically (only graphically in terms of the mod ring), so I'm not sure how to determine accurately what the db increase in each volume setting will be (or have you found some way to accurately display the volume + modulation numerically or are you just doing it by ear)?



Nope, there's still unfortunately no way to do this in any way...


----------



## Big Bob (Apr 24, 2012)

Hey Tod old buddy,

I found a little time slot for this and, since I hadn't heard back from you yet, I decided to code a little demo for you. I'm attaching a simple .nki with 5 empty groups. The script displays 5 knobs on its panel which correspond with the 5 empty groups of the .nki.

If you adjust any one of the knobs, the other 4 knobs will make _approximately_ the same amount of change in db. If you want to set a knob independently, hold down the Alternate key while dragging the knob.

If this is the sort of thing you were shooting for (and it has sufficient accuracy for your purposes), please let me know and I'll post the source code for you.

God Bless,

Bob


----------



## Tod (Apr 24, 2012)

Big Bob @ Tue Apr 24 said:


> Hey Tod old buddy,
> 
> I found a little time slot for this and, since I hadn't heard back from you yet, I decided to code a little demo for you. I'm attaching a simple .nki with 5 empty groups. The script displays 5 knobs on its panel which correspond with the 5 empty groups of the .nki.
> 
> ...



Thankyou my friend, I'll be anxious to check this out. I've got an old client showing up shortly so I won't be able to get to it right away, maybe later today or in the morning. Heh heh, I'm totally retired now but I have a couple of old clients that just won't let me go. Oh well, I guess it's good for the old ego if nothing else. :mrgreen: 

At any rate, I think I've got a good way to check it out for it's accuracy by just using a test-tone in each group and assigning different outputs for them. That way I can get some accurate readings with the DAW meters.

I'm also somewhat curious about the modulator thingy you and mk282 were talking about. I'd actually thought about using a modulator for an overall volume control but quickly put it aside because of the possibility of inadvertently or accidently writeing some coresponding CC in the midi editor, I didn't think of the intensity slider. It could probably be tested in the same manner I describe above. However, as you say, it probably won't work anyway.

God bless you too Bob, I'll get back to you as soon as possible and thankyou so much.


----------



## Big Bob (Apr 24, 2012)

> At any rate, I think I've got a good way to check it out for it's accuracy by just using a test-tone in each group and assigning different outputs for them. That way I can get some accurate readings with the DAW meters.



That shouldn't be necessary because you will actually be able to *see* the accuracy numerically (or the lack of it :lol: ) the way I wrote the script. Any deviation in the audible result from the displayed db values will be due to Kontakt itself (in that they may or may not precisely control volume as they indicate in their db display).

However, if you try MK's technique, then you will need to resort to something like the above because there is no way to see a modulator's effect numerically in db (within K4, that is). Using a modulator may work out in certain situations in which the settings of each volume knob are rather near each other. However, if one or more volume settings differ by 10 or 20 db or more, I would be very surprised if it does the job but, I'd love to be wrong about that. So, please let us know how your tests turn out.

BTW regarding:


> Heh heh, I'm totally retired now but I have a couple of old clients that just won't let me go.



Congratulations on your retirement. o-[][]-o The same sort of thing happened to me with former clients when I first retired but it eventually settles down to nearly zero (at least as far as paid work is concerned :roll: )

Of course I'm talking about retiring as an Engineering Consultant, not from my music 'hobby'. But, I just realized as I was typing this that I've been retired now for almost 24 years :shock: . You know, some people say they get very bored when they retire but I sure haven't run into that problem :wink: In fact, most of the time, I wonder how I ever found the time to work :lol: 

Anyway, I wish you the best with your project and your retirement my friend.

God Bless,

Bob


----------



## mk282 (Apr 24, 2012)

Big Bob, I've just tested my suggested method. And I think it works, sorta. At least it sounds just fine to me.

Even though the volume control is in dB, the modulation is actually a percentage of the knob value. And by listening, everything sounds ok to me - seems like the correlation between the volumes are preserved. Try this: have one group set to 0 dB, and the other to 12 dB. Add a Constant modulator, enable Invert, and set the depth to 25%.

Now watch the rings in both groups. For the second group, the mod ring will move to the location that's somewhere around 3 dB. For the first group, the mod ring will move to the location that's somewhere around -9 dB.

The difference is -9 dB from original values. I think my method holds just fine!


----------



## Big Bob (Apr 24, 2012)

Hi MK,

I think you are right about the modulation moving each knob by the same fraction of the rotation all right, but, that is precisely why I think it won't track db for db (because the db amount is based on equal ratios of the current to the last ep, not equal differences). For small differences in initial volume, equal differences in ep can approach equal ratios in ep and therefore may sound very similar.

The way to prove my point would be to make an exceptionally large difference in the initial db gains. For example, set one knob to -40 db and the 2nd one to 0 db. Then raise the lower one by 6db (to -34db). If my theory is correct, the 0db volume will only increase to about 1.4 db (instead of to 6 db as we would like it to).

I think we might easily 'get by' with your method as long as the volume differences in the knobs are not too large. Right now it's not too convenient for me to set up your experiment but if you still have it set up, try it again with -40db and 0db as explained above. Then, increase the modulation until the -40db reaches -34db. If the other knob with the same modulation applied increases to about +6db when the -40db knob is raised to -34 db, then there might be something wrong with my reasoning because *it shouldn't even make it to +2db in theory*.

If you are able to repeat your test with -40db and 0db, I would be very interested in hearing what results you obtain. Maybe Tod will also be able to provide some test data?

Rejoice,

Bob


----------



## Big Bob (Apr 24, 2012)

Hey MK,

Hold everything :idea: 

I already quit for the day and was in the shower when I got to thinking about your modulator idea and, I think I need to review how NI configures their modulators internally.

If they actually modulate prior to the volume control point in the signal path, and I think maybe they do, then when the same amount of modulation is applied to two volume controls, their eps will *not* be changed by the same amount but rather by the same *percentage*. If that's the case, then it *will* result in equal db changes and you'll have a winner o-[][]-o . 

It's been about 4 years since I investigated the internals of Kontakt's modulation behaviour and my brain is a bit rusty. But, first thing tomorrow, I'm going to review my Volume Control Study to refresh my memory. Meanwhile, if you can perform the test I suggested in my last post, it should tell the tale.

It would certainly be nice if this method works out correctly because it is certainly a whole lot easier and less cpu demanding than what I was proposing. 

In any case, I'll check back in tomorrow morning when I start my day to see where everyone is at. :lol: 

Rejoice,

Bob


----------



## Big Bob (Apr 25, 2012)

Many apologies MK.

It turns out that my main concern about your modulator idea was unfounded. :oops: Because of the way NI handles modulators internally, it *will* preserve the ratio and therefore the db relationship. I was erroneously thinking that equal modulation amounts would cause equal changes in each ep value.

Essentially the cubic relationship between volume and ep without modulation is given by:

(1) V = 60000*Log(ep) -348000 V in mdb

With modulation, the relationship becomes:

(2) V = 60000*Log(m*ep) -348000 where m is a modulation factor from 0 to 1

Equation 2 can be recast as shown in (3):

(3) V = V0 + 60000*Log(m) where V0 is the volume with m = 0

Equation (3) clearly shows that there will be a change of 60000*Log(m) in db regardless of what the initial V0 volume level is. So, the bottom line is that *your method does preserve the relative db relationship between the slave controls*.

That being said, there are a few other things that should be noted about doing it this way however.

1. The technique is mostly applicable to situations where a master/slave setup is desired.

2. The Master control can most conveniently provide only attenuation from the non-modulation slave settings.

3. The modulation taper is linear and therefore not too friendly to use for volume adjustment.

4. There is no numerical indication of how much attenuation the modulator is providing.

5. But, this technique is rather easy to setup and not very CPU hungry.

There are of course ways to mitigate some or all of the four shortcomings cited above. For example, (3) could be addressed by interposing a mathematical function between the Master knob's output and the ep it sends to the modulation intensity slider. For (2), if gain is also required, it could possibly be mitigated by some additional complexity in the interposing math. 

If we take Tod's original request as a *requirement*, ie that you can change any volume knob in the group and the remaining knobs will continue to track accordingly (as I implemented in my demo nki), then overcoming (1) might be kind of tricky but, I suppose it could be done. The only way I know to overcome (4) would be to write another Math converter routine that reverse converts the modulation amount to mdb of change.

Implementing all the above enhancements might well require even more effort and cpu usage than I was proposing with my example script. Moreover, if a master/slave solution is acceptable to Tod, then the example script could be considerably simplified.

So, Tod old buddy, you need to weigh in here as to what your actual requirements are and/or which kinds of alternates can be considered. *If you can get by with simple Master/Slave attenuation (by adding another knob to act as a Master attenuator), I think MK's solution should be very appealing to you. *On the other hand, if you need the group-link type of behavior and/or you want more of an audio-taper control and/or you want or need a numerical display of the master's effect, then, you may still want to consider using my proposed method.

In any case, this has been a very interesting discussion that hopefully will prove to be of some use in future projects and Kudos to MK282 for coming up with yet another clever way to avoid mathematics :lol: 

God Bless,

Bob

BTW The reason that the modulator's invert button must be used can be seen by referring to Figure 11 in my 'Kontakt Volume Control Study and Report' that I wrote in 2008 for K2. Compare Fig 11 with Fig 10. In both figures set the MIDI CC to the 1.0 position (equivalent to what the 'constant' modulator provides) and you should see the situation.


----------



## ScoringFilm (Apr 25, 2012)

Bob,

Been following this thread and learning from the master!

Is there any chance you could post Tod's Knobs script uncompiled?

Regards,

Justin


----------



## Big Bob (Apr 25, 2012)

Sure thing Justin,

I'm attaching the KSE source code. If Tod decided to go this way, I was going to post it anyway, probably along with a few choice comments describing the general idea used. But, until then, you can probably work that out for yourself :lol: 

Rejoice,

Bob


----------



## ScoringFilm (Apr 25, 2012)

Bob,

Many thanks - I'll dissect this one as much as possible!

Regards,

Justin


----------



## Big Bob (Apr 25, 2012)

You're welcome Justin,

I forgot to mention, for anyone that wants to use this general technique, the CPU usage can be considerably reduced by including F1 and F2 in the SetMathMode option list.

*SetMathMode(F1+F2+TI)*

This will compile the math routines in their fast mode. Of course you will then need to include the corresponding .nka files in the Data folder per the instructions given in the V405 User's Guide Addendum. :roll: Well, you know what they say about there is no such thing as a 'free lunch' :lol: 

Rejoice,

Bob


----------



## ScoringFilm (Apr 25, 2012)

Thanks Bob,

Done all that and still feels like a free lunch - many thanks!!

I really don't want to hi-jack this thread before Tod has his say so I have updated the following thread with a very similar request (the same but different!):

http://www.vi-control.net/forum/viewtopic.php?t=25334

Regards,

Justin


----------



## Mike Greene (Apr 25, 2012)

Big Bob @ Wed Apr 25 said:


> Many apologies MK.
> 
> It turns out that my main concern about your modulator idea was unfounded. :oops:


Hey, I was (silently) right there with you, Bob. I would have bet good money that the db relationship wouldn't have held for exactly the reasons you said.

This thread proves yet again what an amazing bunch of guys we have here. At the risk of going off topic for a minute, I just want to say thank you! 8) 

Okay, now that I got that off my chest . . . carry on! :mrgreen:


----------



## Big Bob (Apr 25, 2012)

> Hey, I was (silently) right there with you, Bob.



Hey Mike, too bad you didn't chime with a post or two before I discovered my error. Then, I could have blamed it you some way :lol:


----------



## Tod (Apr 25, 2012)

Okay, finally got a chance to check your script out. I'm not sure why, but when I updated K4, for some reason my dll files didn't get updated. However, my stand-a-lone version did so I was able to copy the script from there and then recreate your nki in Reaper. It appears to work perfectly, I also loaded a looped test tone in each of the groups and all the meter levels coresponded properly. 

I did make a valiant attempt to follow the script through, I put it into Nils editer and indented everything to see it better. Heh heh, I'm afraid I didn't get to far other than to realize how un-up-to-date I am with the newer scripting features in K4. :oops: So we now have actual functions that are sort of sub-routines?

Oops, sorry Bob, you posted the source code while I was makeing this reply. After looking it over I'm afraid my current undertsanding is just not adequate for all this.:oops: Also my version of the math library is V403 so I'll want to get that updated too regardless.



Big Bob @ Wed Apr 25 said:


> I forgot to mention, for anyone that wants to use this general technique, the CPU usage can be considerably reduced by including F1 and F2 in the SetMathMode option list.
> 
> *SetMathMode(F1+F2+TI)*
> 
> This will compile the math routines in their fast mode. Of course you will then need to include the corresponding .nka files in the Data folder per the instructions given in the V405 User's Guide Addendum. :roll: Well, you know what they say about there is no such thing as a 'free lunch' :lol:


 
I'll continue to look all this over my freind but in all honesty I'm pretty overwhelmed at the moment and I'm not sure my old brain is capable of implementing all this. I think I do vaguely remember something about "SetMathMode" in the 403 User's Guide Addendum and also mention of the Resource Container, is that the Data folder you're talking about? I've read a little about the Resource Container in the KSP manaul but nothing beyond that.

God bless you Bob, you are truly an inspiration. o=<


----------



## Big Bob (Apr 25, 2012)

Hi Tod,

Glad to see you're back with us. You missed a lot of excitement!



> I think I do vaguely remember something about "SetMathMode" in the 403 User's Guide Addendum and also mention of the Resource Container, is that the Data folder you're talking about?



Yes. However, you only need worry about that if you have to use the Math Library in the fast mode.

I'm a little swamped right now but when I get a chance, I'll try to post some clarifying comments about the TodsKnobs script. I've emailed you a copy of MathV405 so you can spend a little time reviewing the fast mode stuff if you want to.

Take it slow and easy and in no time it should all be clear as mud :lol: 

God Bless,

Bob


----------



## Tod (Apr 25, 2012)

> I've emailed you a copy of MathV405 so you can spend a little time reviewing the fast mode stuff if you want to.



Thanks Bob, I got it.

I also had a chance to check out the modulator mk was talking about and it indeed works. I only used two groups with test tones and they seemed to track perfectly according to the vu meters. I used it with a slider and it could work as an overall volume attenuator. Not sure about the "invert" button mk mentioned, it didn't seem to matter on or off, the volume is max when the slider is full left either way?

Thanks again my freind.

Edit: Well I stand corrected, I no sooner had posted this post, walked into my studio and clicked on the "invert" button (turning it off) and it no longer worked, clicking it on works. I must have tried this at least 10 times before, oh well.. o/~


----------



## Big Bob (Apr 25, 2012)

Hi Tod,

I'll just point out a couple of things here that I already covered but since this thread has gotten kind of busy, you may not have caught all these things.

Regarding the 'Invert Button'.



> BTW The reason that the modulator's invert button must be used can be seen by referring to Figure 11 in my 'Kontakt Volume Control Study and Report' that I wrote in 2008 for K2. Compare Fig 11 with Fig 10. In both figures set the MIDI CC to the 1.0 position (equivalent to what the 'constant' modulator provides) and you should see the situation.



Regarding your testing with VU meters, etc, It's always nice to confirm things but you could have saved yourself the trouble had you noticed the following:



> (3) V = V0 + 60000*Log(m) where V0 is the volume with m = 0
> 
> Equation (3) clearly shows that there will be a change of 60000*Log(m) in db regardless of what the initial V0 volume level is. So, the bottom line is that *your method does preserve the relative db relationship between the slave controls. *



The other thing I'll emphasize is that modulators always behave linearly with regard to the parameter they are controlling. This means that using the Intensity slider as a volume control will not exhibit the same kind of pseudo-audio taper that the ep knobs exhibit. As I already pointed out, this could be mitigated by interposing a math function between the Master knob output and the Intensity ep that it generates but without such a function, the audio control may not be too satisfying.

Finally, let me ask you whether or not a Master attenuator will fit your application needs as well as the original 'grouping of controls' that you asked for? If so, maybe you should use MK's method so you won't have to struggle with trying to understand the script I gave you.

On the other hand, it really isn't all that complicated and if you want, I'll be glad to walk through the general logic with you. But, your choice. Although, I do think that somewhere along the line you should try to get caught up a bit with all the spiffy new KSP stuff in K4/5.

Also, I'll mention that if you decide to spend any more time studying the TodsKnobs script, you may want to download the variant I just posted for Justin, near the end of this thread 

http://www.vi-control.net/forum/viewtopic.php?t=25334

because it uses the same general idea but it might be easier for you to follow.

God Bless,

Bob


----------



## mk282 (Apr 26, 2012)

I'm glad my method is proven to be effective


----------



## Tod (Apr 26, 2012)

Hi Bob, sorry I got tied up with that old client again today. Right now I've got him in the studio editing some of his guitar parts.



> I'll just point out a couple of things here that I already covered but since this thread has gotten kind of busy, you may not have caught all these things.
> 
> Regarding the 'Invert Button'.
> 
> BTW The reason that the modulator's invert button must be used can be seen by referring to Figure 11 in my 'Kontakt Volume Control Study and Report' that I wrote in 2008 for K2. Compare Fig 11 with Fig 10. In both figures set the MIDI CC to the 1.0 position (equivalent to what the 'constant' modulator provides) and you should see the situation.



I remember that report and know I DLed it back when you first put it out but I can't find it. I Hadn't turned my old XP comp on in months. It's got 4 drives and I looked in all the logical places but don't have a clue where it would be.



> Regarding your testing with VU meters, etc, It's always nice to confirm things but you could have saved yourself the trouble had you noticed the following:
> 
> (3) V = V0 + 60000*Log(m) where V0 is the volume with m = 0
> 
> Equation (3) clearly shows that there will be a change of 60000*Log(m) in db regardless of what the initial V0 volume level is. So, the bottom line is that *your method does preserve the relative db relationship between the slave controls. *



Heh heh, keep in mind that your math skills are far beyond my old brain. :D I'm totally amazed at the way you can look at a formula and predict the outcome, I have to see the results. Actually I was pretty good in math back in highschool so I'm a little embarrassed where my heads at today :oops: , but that was over 50 years ago, kind of the "if you don't use it you lose it" scenario. :roll: 



> The other thing I'll emphasize is that modulators always behave linearly with regard to the parameter they are controlling. This means that using the Intensity slider as a volume control will not exhibit the same kind of pseudo-audio taper that the ep knobs exhibit. As I already pointed out, this could be mitigated by interposing a math function between the Master knob output and the Intensity ep that it generates but without such a function, the audio control may not be too satisfying.



Yes, I understand, I wouldn't want to use it on the main knobs, but it might serve it's purpose just as a simple overall volume slider. I know it doesn't give a readout but I think that's okay in this circumstance. 



> Finally, let me ask you whether or not a Master attenuator will fit your application needs as well as the original 'grouping of controls' that you asked for? If so, maybe you should use MK's method so you won't have to struggle with trying to understand the script I gave you.



As I mentioned above, I think it would be very easy to add mk's method as an attenuator. I've already got a velocity intensity knob for scaling the velocity and that was very easy to put together. I should also mention that this would only be used while adjusting the various mics, once they've got it set up I'll recommend that they direct all the outputs to the default instrument output, no use taking up outputs unnecessarily.



> On the other hand, it really isn't all that complicated and if you want, I'll be glad to walk through the general logic with you. But, your choice.
> 
> Although, I do think that somewhere along the line you should try to get caught up a bit with all the spiffy new KSP stuff in K4/5.



I tell you my freind, I pray to god I never get to old to want to stop learning and I do want to get up to date with the K4 stuff. I've DLed Justin's script too. I also had to update Nils editor to get the math library to work, I think I'm set.

Thanks bob, I've got some questions about how this will all work, I'll get back to you later, either tonight or in the morning.


----------



## mk282 (Apr 27, 2012)

Tod, how would my method work out for ya?


----------



## Big Bob (Apr 27, 2012)

> I remember that report and know I DLed it back when you first put it out but I can't find it. I Hadn't turned my old XP comp on in months. It's got 4 drives and I looked in all the logical places but don't have a clue where it would be.



For anyone interested in putting this Study aside for future reference, I'm attaching it to this post.

Keep in mind that it was written back in the K2 days but most of it is still applicable. The most notable difference, relative to modulation, is that instead of an Invert button, the Intensity slider was bipolar. Another functional difference was that with K2, changes in the Intensity would only take effect for the next note played. Therefore, you couldn't use MK's clever scheme to adjust the volume of a sustained note for example. Fortunately this seems to have been corrected because now changes in modulation Intensity seem to also act on existing (sustained) notes.

The main point I was addressing (when referring to the attached Study), was why one has to use the invert button to use MK's technique. Note that Figures 8 and 9 depict the positive and negative modulation configuration respectively. So you could translate Fig 9 as representing the case when the Invert button is engaged.

To apply MK's technique, use of the 'constant' modulator, essentially puts the MIDI CC potentiometer at the 1.0 side for both Fig 8 and Fig 9. From Fig 8 you can see that with the Invert button *disengaged*, the Intensity slider has no effect on the output. However, from Figure 9, the output is essentially 'tied' to the swinger of the Intensity potentiometer and therefore is able to control over the full range (but only as an attenuator of the current setting).

Rejoice,

Bob


----------



## masonroza (Apr 27, 2012)

Wow, very interesting topic!

I was trying to do something similar however my sliders ranges from 0-127 since I'm controlling MIDI CCs instead of 0-1000000. Can the above script's values be scaled to fit into the MIDI range? I'm trying to think of a way but I can't wrap my head around it...

Any help would be greatly appreciated!


----------



## Tod (Apr 27, 2012)

Thanks Bob, got the VolumeControlStudy and again I'm amazed how you come up with this stuff. Out of curiousity may I ask how got your test results to arrive at your conclusions? Heh heh, if you'ld rather not or it takes more the a couple of sentences don't worry about it, the important thing is that I think we're all on the same page as to the results.

Concerning the volume knobs, would the way you're proposing totally replace what I've got now or would it be an add on? For instance, here's the knob ui-controls for the 2nd and 3rd mic positions. 


```
on ui_control ($Vol_Bot)  {2nd mic}
  $cnt1 := (%Grp_Start [1] + $Ttl_RR_Per_Mic)
  $cnt2 := %Grp_Start [1]
  while ($cnt2 < $cnt1)
    _set_engine_par($ENGINE_PAR_VOLUME,$Vol_Bot,$cnt2,-1,-1)
      inc ($cnt2)
  end while
 set_knob_label($Vol_Bot,_get_engine_par_disp($ENGINE_PAR_VOLUME,%Grp_Start [1] ,0 ,-1))
end on
on ui_control ($Vol_Shell)  {3rd mic}
  $cnt1 := (%Grp_Start [2] + $Ttl_RR_Per_Mic)
  $cnt2 := %Grp_Start [2]
  while ($cnt2 < $cnt1)
    _set_engine_par($ENGINE_PAR_VOLUME,$Vol_Shell,$cnt2,-1,-1)
      inc ($cnt2)
  end while
 set_knob_label($Vol_Shell,_get_engine_par_disp($ENGINE_PAR_VOLUME,%Grp_Start [2] ,0 ,-1))
end on
```

I'm thinking the easiest way would be as an add on, because I think that would be the easiest way for me to implement it. Also I'm leaning towards using "gouping buttons" because under normal circumtances I'll only be grouping 2 mic positions at a time.

Thanks again Bob and god bless.


----------



## mk282 (Apr 27, 2012)

masonroza @ 27.4.2012 said:


> Wow, very interesting topic!
> 
> I was trying to do something similar however my sliders ranges from 0-127 since I'm controlling MIDI CCs instead of 0-1000000. Can the above script's values be scaled to fit into the MIDI range? I'm trying to think of a way but I can't wrap my head around it...
> 
> Any help would be greatly appreciated!



Yeah, that shouldn't be a problem. Multiply the knob value by 7874 to expand its range from 0~127 to 0~1000000.


----------



## Big Bob (Apr 27, 2012)

Hi Tod,



> I'm thinking the easiest way would be as an add on, because I think that would be the easiest way for me to implement it. Also I'm leaning towards using "gouping buttons" because under normal circumtances I'll only be grouping 2 mic positions at a time.



Things can always be done as an add-on, it's just a matter of understanding what it has to do and how much of that is already being done by your existing code. Once in a while, you may also have to resolve any conflicts that might occur.

However, your 'grouping' buttons idea may require a bit of rework versus the 'any control updates all the others' approach I scripted. For one thing, you will have to clarify precisely what you mean by using buttons. Do you mean something like each knob has an associated button that when enabled, causes that knob to be linked with all other knobs (that also have their button enabled)? If so, the logic I used in my example will have to be changed. If you simply mean that when you enable a button it allows you to adjust that knob without affecting the others, then you could use the same callback logic but just change the Alt key if clause to test the associated button. So, step one would be to clarify just how you envision these 'buttons' will operate. 

Also, before forging ahead with this, is it possible that you could simply use Mario's technique for this? For example, say you have a Master attenuator knob that affects only those knobs whose 'buttons' are enabled. Are you sure you couldn't make that do the job for you? If it's just the lack of numerical indication, that could be mitigated rather easily by using a simple math function to control what the master knob displays (it could be made to display the attenuation being provided to the 'on-button' knobs in db if you like).

I think you should try to use MK's technique if at all possible. However, if you still want to utilize my algorithm for some reason, I'll try to post a functional description of the basic principles utilized in my example script. I think it is essential that you understand these principles rather than the details of some specific embodiment of them. Once you understand the basics, you should have no problem integrating it with your existing code.

To be continued ...

Rejoice,

Bob


----------



## Big Bob (Apr 27, 2012)

Hi Tod,

Here's the basics.

Assume that each knob in the set is used directly or indirectly to provide engine parameter control of some corresponding amplifier volume. Thus, each knob covers a control range from 0 to 1000000. For any given ep value, the corresponding amplifier volume in db (the value reported by get_engine_par_disp in text format) can be approximated in *numerical* form with the Math Library function named *ep_to_mdb*.

You need to use this function to keep track of the last setting of each knob in volume units (mdb) instead of just keeping track of the last ep setting. In the example script, the last volume level for each knob is held in the *Vol* array.

Each time one of the linked knobs is changed (as detected by the fact that its callback will be executed), you compute its new volume level in mdb and calculate the change in mdb that has occured since the last known volume for that knob. Once you have that difference, you can update the last-known value to the current value. The example script does this with the first part of the function named *vol_change *where the change in volume is put in the variable named *dV*.

The next part of the process is to add *dV* to the last known volume for each of the linked (slave) knobs. In the *vol_change *function this is done by looping through all 5 knobs but excluding the knob who's callback is running (it has already been updated in the preamble).

When you update one of the 'slave' knobs all you have is the volume change in mdb. This must be added to the last-known volume in mdb but, you must also update the ep position of the slave knob itself to the corresponding ep number. This is done by using the Math Library routine named *mdb_to_ep*.

What may have to change is the way you test for the conditions under which other knobs need to be updated if you want to change the objective (like for example whatever you may propose for the 'buttons' you are now talking about). The demo script always updates *all* the knobs when *any* are changed. The only thing that I made optional is the ability to change a single knob without affecting the others but that may be quite different than what you may now be thinking of doing.
------------------------------------------------------------------------------------------

Other than maintaining the displayed values, etc, this is all the demo script does. The area that may be the most puzzling to you is probably more related to how the knobs are referenced rather than the functional volume control basics. I used indirect addressing of all the knobs and such so they can be accessed in simple loops rather than writing everything out inline. If you reference each knob by name, instead of referencing them by their numerical id, you have to unwind all the loops and, depending on the number of slaved knobs, it could get very messy, very fast. Even with only 5 knobs it will probably greatly expand the code.

The other area that may be new to you is the use of macros. Again, you don't have to do it that way. Simply expand the macros out inline and you will get the same result. In fact, the KSE will do just that anyway when you compile the code. So, what you could do is to compile the code and then paste the clipboard back into the KSE and examine the compiled code to see how the macros expand. Each invokation of the *declare_vol_knob *macro simply creates a ui_knob, assigns it a numerical index (0 to 4), and, stores some pertinent data such as the knob's id, the associated group index, etc in the Kid and Gx arrays.

The *on_volume_knob *macro simply creates the callback handler for each knob and you should also be able to see this by examining the compiled source code.

However, if you just aren't comfortable with using either the control id and/or the macro stuff, simply implement the basics (explained above the dashed line) any way that you are comfortable with.

I hope this helps a little but if not, let me know what specific area you are having a problem with.

Rejoice,

Bob


----------



## Tod (Apr 28, 2012)

Hi Bob, I'm sorry, I started this reply yesterday and then got tied up so I'll just continue.



> Things can always be done as an add-on, it's just a matter of understanding what it has to do and how much of that is already being done by your existing code. Once in a while, you may also have to resolve any conflicts that might occur.
> 
> However, your 'grouping' buttons idea may require a bit of rework versus the 'any control updates all the others' approach I scripted. For one thing, you will have to clarify precisely what you mean by using buttons. Do you mean something like each knob has an associated button that when enabled, causes that knob to be linked with all other knobs (that also have their button enabled)? If so, the logic I used in my example will have to be changed. If you simply mean that when you enable a button it allows you to adjust that knob without affecting the others, then you could use the same callback logic but just change the Alt key if clause to test the associated button. So, step one would be to clarify just how you envision these 'buttons' will operate.



Yes, each knob would be associated with a button. I haven't totally thought it through yet but I was thinking about a $variable that would keep track of how many knobs were linked. If the $variable was ($variable > 1) then the on/off %arrays associated with each knob would be checked and if they were on, they would be adjusted relative to the knob being adjusted. 



> Also, before forging ahead with this, is it possible that you could simply use Mario's technique for this? For example, say you have a Master attenuator knob that affects only those knobs whose 'buttons' are enabled. Are you sure you couldn't make that do the job for you? If it's just the lack of numerical indication, that could be mitigated rather easily by using a simple math function to control what the master knob displays (it could be made to display the attenuation being provided to the 'on-button' knobs in db if you like).
> 
> I think you should try to use MK's technique if at all possible. However, if you still want to utilize my algorithm for some reason, I'll try to post a functional description of the basic principles utilized in my example script. I think it is essential that you understand these principles rather than the details of some specific embodiment of them. Once you understand the basics, you should have no problem integrating it with your existing code.



I could see useing the the modulator as an overall attenuator but I'm not sure how it would work for the knobs themselves. 

If it was used as the sole means of controlling the knobs and I set all the group amplifiers at a +6db for the upper headroom, maybe. That is if the intensity values were kept in an array which of course they would have to be.

My simple minded logic tell me that using it as an add-on, could get rather messy. If a knob need to be increased and the intensity is already at 100% there would be no where to go. Kind of the left hand not knowing what the right hand is doing scenario.
-------------------------------------------------------------------

Concerning your last post I've got a few chores to do before I can get in the studio to examine things further. I've already spent quite a bit of time looking over your script, bouncing back and forth between the uncompiled and the compiled scripts. Actually I've gleaned quite a bit, although I'm still a bit overwhelmed when I try to correlate it all with your math library. :?  

I think I now have a much better idea of what the macros are and how they work, obviously the editor is set up to deal with them internally.

I'm a bit confused about the functions though, are the functions in the uncompiled script used by the editor internally to setup the compiled functions? The last time I tried to use functions (the old type, internal to the editor) I got errors and the editor wouldn't compile it, I'm not sure why, I've used them many times before.

I think the hardest part is just getting my head wrapped around the naming conventions, and then there are the IDs, I'm not sure where they come from. 

Thankyou my freind, I'll examine it more when I get in the studio.


----------

