# Ui_knob update ?



## snapshot (Aug 27, 2010)

Hello !

Is there alternative way with *power law *to update declared ui_knob with its function ?

Im writing a code for *quasi-real* instrument scenario ,with knobs dedicated to engine parameters and stuff . The code getting bigger and bigger . I planned to have possibility to store knob's settings in *%arrays* for preset situation . 

And im wondering if there is any *alternative way* to force knobs to do their job that is placed under every on ui_control $(...) part . *to avoid copying a huge amount of code (set_engine_par)* for %arrays section . I also would like to run through presets via midi controller . so again im forced to copy set_engine_par's to on_controller section ?
This is going to be incredibly huge code then . Will it increase my CPU / Memory usage if i use few programs/instruments with the same huge code inside ? will i notice it ?
Anything i should know or look for ?
what do you think guys ?

K


----------



## TechLo (Aug 27, 2010)

The best way I've found to avoid replicating code that would be nearly identical for both "on ui_control" and "on controller" for knobs (but use sliders) and buttons (but use switches) is to use PGS key commands. At the top of the on controller callback I set a variable ($conVgui) to equal 0, then set a PGS key at some point below to trigger the PGS callback. You'll need a separate call back for each on ui_control element, but you can get away with minimal code for each one. I set $conVgui=1 for each on ui_control callback, then set the same PGS key used in on_controller to 1 to trigger the PGS call back. Then, inside the PGS callback the code can sort out whether the callback was initiated by the controller or gui depending on the $conVgui variable. It matters because triggering a switch via midi control doesn't automatically set the control value to 1, unlike clicking on the gui. Using PGS callbacks, then, you only need your code in one location.

Use call functions when you can, obviously, though it's frequently a matter of testing each one to see if it works in a "call" or if you need to use a KScript function which inlines the code in every instance. You are using the KScript editor, right? lol (scripting impossible w/o it).

Preset storing in arrays is pretty straightforward. I use a menuless method of alt clicking on gui buttons to store preset information (control click to recall) to different location (as you can see in one of my BooTweak videos on YouTube.

As for power law/scaling there are some good math guys here (I'm not one of them, lol) and I think maybe Big Bob has some posts about some math libraries he's done that might help out there.


----------



## snapshot (Aug 27, 2010)

Hi TechLo !

thats wicked ,thanks for your description ! im getting into this right now , will do some testing .

i have seen your workflow on youtube material ,pretty great situation man ! im just still not sure how you store presets ... well , normally i would like to use mouse as less as possible while performing or recording . i forced ui_value_edit (that is a number of cell in %array) with INC function to skip forward when i press one controller button and backward when i press another ,which works for me in desired way , but i still would like to understand how you are doing your snap manipulating . i dont get this clicks and Alt keys LOL ...

With power law i mean exactly this what you have described to me .
and yes ,i have been learning a lot from Big Bob already ... Big thanks to Big Bob too

Big respect to Nils Liberg for his amazing tool that makes me feel for scripting at all

K


----------



## snapshot (Aug 27, 2010)

Hi again !

im back ,yes ! any amount of callbacks can influence on one set_engine_par in *ON PGS_CHANGED* . but you dont need to create any variable to switch (as i understood from your suggestion to use variable that let PGS know from where that event comes). As i see ui elements firing events *only when touched* ,seems like its not streamed all the time . So *pgs_get_key_val* will *receive events only when appeared* .
*TechLo* ! thank you very much again ,this is incredibly useful and it will decrease my code about 3 times

~o) 
K


----------



## snapshot (Aug 27, 2010)

a simple prove for knob and snapshot situation ...

slot A

```
on init
    declare ui_value_edit $volume (0,100,1)
    declare %save[127]
    declare ui_value_edit $preset (0,127,1)
    pgs_create_key(VOLUME,1)
end on

on ui_control ($Volume)
    %save[$preset] := $Volume
    pgs_set_key_val(VOLUME,0,$Volume)
end on

on ui_control ($preset)  
    $Volume := %save[$preset]
    pgs_set_key_val(VOLUME,0,%save[$preset])
end on
```

slot B

```
on init
    declare $volume
end on

on pgs_changed   
    $Volume := pgs_get_key_val(VOLUME,0)
    set_engine_par ($ENGINE_PAR_VOLUME,$volume*10000,0,0,-1)
end on
```


----------



## TechLo (Aug 27, 2010)

Cool, glad to be of help! For knobs/sliders it doesn't matter where the PGS key is being triggered from, but at least for what I'm doing, on controller doesn't automatically change a switch's $CONTROL_PAR_VALUE off and on like clicking on the gui with a mouse does, hence the indicating variable.

Yeah, my preset system is unique and therefore takes a little bit of learning to come to grips with. I just posted an overview video for BooTweak and hope to finish up a few more (including how the preset system works) before the weekend is over.


----------



## kotori (Aug 27, 2010)

TechLo @ Fri Aug 27 said:


> The best way I've found to avoid replicating code that would be nearly identical for both "on ui_control" and "on controller" for knobs (but use sliders) and buttons (but use switches) is to use PGS key commands.


Why PGS commands instead of using "call"? (unless your explicit goal is to have the preset data end up within a separate script of course)



> It matters because triggering a switch via midi control doesn't automatically set the control value to 1, unlike clicking on the gui.


It did last time I checked. Do you mean there is a bug that affects switches. Would you care to post an example in that case?


----------



## TechLo (Aug 28, 2010)

Hey Nils -- I went with PGS commands because I found them more robust than the "call" functions while testing the programming. This was just a little while before you posted the info. on the "call" bugs and fixes. I have some code in callbacks that go several layers deep in "if"s and "select"s and was able to make them work better with PGS commands.

As for the switches, it may be down to the fact that I use separate single graphic files for different states of my switches. I guess using a built-in switch in the normal fashion works? I was literally figuring out scripting as I went along, so I'm sure many things I ended up doing are not orthodox, and I don't know any better, lol. I could give a more detailed explanation at a later time with more time, I reckon.


----------



## kotori (Aug 28, 2010)

TechLo @ Sat Aug 28 said:


> Hey Nils -- I went with PGS commands because I found them more robust than the "call" functions while testing the programming. This was just a little while before you posted the info. on the "call" bugs and fixes. I have some code in callbacks that go several layers deep in "if"s and "select"s and was able to make them work better with PGS commands.


If you use the "Automatic workaround for call-bug" option in the settings menu of KScript Editor it fixes the problem automatically. I have not yet run into any case where that doesn't work. Maybe you were affected by the get_ui_id bug. Invoking that function isn't safe inside called functions.



> As for the switches, it may be down to the fact that I use separate single graphic files for different states of my switches. I guess using a built-in switch in the normal fashion works? I was literally figuring out scripting as I went along, so I'm sure many things I ended up doing are not orthodox, and I don't know any better, lol. I could give a more detailed explanation at a later time with more time, I reckon.


I just tried with a switch with custom graphics and it worked too. Must be something else then I guess.


----------



## snapshot (Aug 28, 2010)

Hi guys

do you know if ON_PGS_CHANGED is firing *all* events/parameters written below even if i touch just *one* ui element or controller ? *TechLo*, did you noticed CPU spiking when touching anything written below on_pgs_changed? 

K


----------



## TechLo (Aug 28, 2010)

Nils, I wasn't aware that it was the "get_ui_id" that was causing the bug in call functions. Does your automatic fix in the script compilation cover that as well? It most certainly was the source of my problems, then, as I use a ton of get_ui_id commands for the tons of controls on my performance view.

Snap--I haven't noticed any CPU spikes or overall difference in CPU use using PGS commands. Unless the individual "if get PGS key val"s that are all nested in the ON_PGS callback are somehow prebuffered (I don't know, but I doubt it), I imagine that each PGS key that triggers the ON PGS callback forces the callback to look through all the if statements looking for the appropriate key. I have an awful lot of if statements in my PGS callback, but it all seems to work fine. It seems logical, though, that a call function would be a little bit faster as it's a direct reference to the code you want to invoke, not nested in a general purpose callback like PGS. But like I said, I see no difference, and I'm using a not very powerful laptop.

Obviously one advantage of using PGS is that if you wanted you could have a script in another slot that works with other scripts via PGS.

Sounds like you're coming to grips with the different ways of only writing code once, which was a big milestone for me as well when learning scripting. I still use the KScript functions which inline the code because sometimes the new call statement doesn't work for everything, and then you still only have to write the code once.


----------



## kotori (Aug 28, 2010)

TechLo @ Sat Aug 28 said:


> Nils, I wasn't aware that it was the "get_ui_id" that was causing the bug in call functions. Does your automatic fix in the script compilation cover that as well? It most certainly was the source of my problems, then, as I use a ton of get_ui_id commands for the tons of controls on my performance view.



There are two different problems: using get_ui_id inside called functions and invoking a function using "call" on the last line of a compound statement. I have contemplated adding an option warning for get_ui_id invocations inside functions, but I haven't had the time yet.


----------



## snapshot (Aug 29, 2010)

TechLo!

Yes . It is a big milestone for me neither . every day a little step forward but this was a huge step .

So that statements keeps you safe , thats clever . I will go on with call functions ,my code is too modular to make it work with other instruments so i think i will be not in need to communicate through PGS on that level . i will see what will come out after remixing my code and debugging ... i wish myself luck !

ps:im still wondering about your preset situation 

cheers
k


----------



## TechLo (Aug 29, 2010)

Ha, I call it the "Invisible Pyramid Preset System." Now that you can alt or control click buttons in K4, I use alt/click on a button already on the gui that is normally used for something else to store preset info to an array, and control click to recall it. In the overview video you can see that there are 4 tiered button layers that each save 4 different amounts of preset data (which I call bricks), ranging from just the last touched knob to around 168 different parameters for any group selected. Then in the main preset builder section you build your pyramid preset out of whichever bricks you want to, so it's pretty easy to make simple to complex/wild presets by quickly dialing in what you want in the preset builder area. So you can "play" presets on the brick level by conrol/clicking individual brick presets or on the pyramid presets level with the 32 preset buttons. It does take a little bit of getting used to making the preset bricks with no visual information of what you're doing, but in the preset builder area the labels light up when there are actual preset bricks in the location you're dialing in with your builder knobs.


----------



## snapshot (Aug 30, 2010)

a very modular preset system :D
Very smart man . And i see that for your project it was quite nessesary .
Im seeing your workflow on the panel , very impressive i must say !



cheeeers
K


----------

