# Is there a way to clear the NKS knob positioning assignments I've saved in an nki?



## Mike Greene (Jun 1, 2021)

I try to be very careful when I set up my Automation_ID numbers, so that all the knobs go into the pages and positions that I want. I change my mind a lot, though, and I keep reevaluating what the best order would be, so I hold off on clicking "Apply and Save" for as long as possible, since it seems that once you do that, you can't change the positions anymore using the KSP script. Instead, you now have to cut/paste, or delete and add new knobs by clicking on the GUI, which is a PIA. (Especially since many of my knobs aren't actually on the GUI. They're hidden and used to control menus, or other little tricks. So I have to temporarily put them onto the GUI, just so I can add them. Ugh.)

So ... if I've already clicked "Apply and Save," is there a way to delete those stored settings in the nki so that I can start over and reassign the positions with the Automation_ID commands in my KSP script?


----------



## polypx (Jun 2, 2021)

I do it exactly the opposite way around. I put all my automation numbers in order as the widgets are declared, and those never change. When the instrument is ready for NI I delete all NKS pages, and one by one make pages for various things (Amp, Filter, etc). Then LEARN click the controls for each page before the final "Apply and Save". 

But yes, you can always delete the NKS pages or clear the knobs right?


----------



## EvilDragon (Jun 2, 2021)

I do it exactly the way polypx does. Don't mold automation IDs to NKS knob/page positions, have them all in fixed order and sorted logically according to sections of the GUI. This is then also easier to reach to from any other DAW's parameter automation lists.



Mike Greene said:


> Especially since many of my knobs aren't actually on the GUI. They're hidden and used to control menus, or other little tricks


Have a constant declared called $DEV_MODE or something, which you then just flip in the compiled code to show or hide those aliased widgets that aren't actually on the GUI but remotely control stuff that's not automatable.


----------



## Mike Greene (Jun 2, 2021)

Well, you guys are doing it the wrong way! The WRONG WAY!!!! 

Mario, I'm embarrassed to say I never thought of using a $DEV_MODE variable. I need to start doing that, not only for this, but now I'm thinking of uses besides this one. If I make it a standard thing for all scripts, it will handy.



polypx said:


> But yes, you can always delete the NKS pages or clear the knobs right?


Yes, I can, but what I was hoping for was that when I did that, then Maschine would repopulate with the controls numbered the way I have them in my script. I guess it's not a huge deal, since I can always move knobs around in Maschine. (You know, the way you amateurs do it.  ) But I find it easier to do the reordering in the KSP script. Especially in Hip Hop Creator, which uses all 16 pages, and where I keep reevaluating which controls should be highest/lowest priorities. Moving knob positions en masse in KSP is quick and easy, but in Maschine, it's a whole lot of clicking.



EvilDragon said:


> I do it exactly the way polypx does. Don't mold automation IDs to NKS knob/page positions, have them all in fixed order and sorted logically according to sections of the GUI. This is then also easier to reach to from any other DAW's parameter automation lists.


If you'll indulge me in a couple tangential questions:

I noticed in Logic that Sunset Strings has a zillion controller options that seem to match all the automation-enabled controls in my instrument. Interestingly, the ones I assigned automation-ID numbers to (for NKS/Maschine knobs) all appear at the _bottom_ of that list, and there are well over a hundred unnamed controls before that.

Is that because controls that are automation-enabled but don't have automation-ID numbers automatically come before the ones that do? Is that universal in all DAWs, or just a Logic thing? Also, can I can give them automation-ID numbers that are higher than 256, so they will appear _after_ my "important" controls? (I know I could just try it, but I often learn way more when you guys tell me about stuff I never thought of, so just in case there's some "other way," I'm asking the question here.)

Anyway, regarding those hundreds of controller option that appear before "the good ones," I guess I need to give names to all those other controls, so they're not blank (as they are now.) But ... now I'm thinking I'm not so sure they should really be automation-enabled in the first place.

In the case of Sunset Strings, I don't use menus, and instead I use a pile of switches, that are coded in KSP to _look_ like menu selections. (This gives me the option to have nested menus, etc.) So now I'm thinking - who the heck needs to be able to assign a controller to every button in these fake-menus? Is that really something any user would do? For that matter, I'm wondering if I should automation-_disable_ all the GUI controls that I'm not assigning to NKS/Maschine. Is there a downside to that?


----------



## EvilDragon (Jun 2, 2021)

AFAIK that's just a Logic thing. For something called Logic, it's often far from logical. 



Mike Greene said:


> In the case of Sunset Strings, I don't use menus, and instead I use a pile of switches, that are coded in KSP to _look_ like menu selections. (This gives me the option to have nested menus, etc.) So now I'm thinking - who the heck needs to be able to assign a controller to every button in these fake-menus? Is that really something any user would do? For that matter, I'm wondering if I should automation-_disable_ all the GUI controls that I'm not assigning to NKS/Maschine. Is there a downside to that?



Why are you using ui_switches for that at all? Use ui_buttons, they are not automatable inherently. And yeah, what you did there doesn't really need automatable buttons.


That said, anything you could envision user could consider modifying during a project should be automatable. Not just NKS controls.


----------



## kb123 (Jun 2, 2021)

If you delete all the nks pages in maschine and save it, when you next load it up it will take on the automation as it is defined in the script with the full 16 pages again


----------



## polypx (Jun 2, 2021)

I think the stupid Logic thing is because it sorts the unnamed controllers (numbers) above the named controllers... alpha sort.


----------



## polypx (Jun 2, 2021)

It looks like the auto-populate option (Mike's advanced method ) just assigns the first 128 host assignments in order, is that right?


----------



## Mike Greene (Jun 2, 2021)

EvilDragon said:


> Why are you using ui_switches for that at all? Use ui_buttons, they are not automatable inherently. And yeah, what you did there doesn't really need automatable buttons.


My general philosophy has always been to give the user the ability to automate any control they want, so I make *everything* automatable. Kinda dumb in hindsight, because nobody's going to have 200 controller knobs/buttons for all the UI switches in my fake menus. Buttonizing will make a number of things easier.



kb123 said:


> If you delete all the nks pages in maschine and save it, when you next load it up it will take on the automation as it is defined in the script with the full 16 pages again


No, I tried that. It definitely doesn't work. Here, I'll try it again now. Delete, delete, delete, delete ... Apply and Save ... Close ... Open ... Oh shit. It works!

~sigh~ I really need to fire myself. In fact, the whole point of this thread was that I thought that didn't work. 



polypx said:


> I think the stupid Logic thing is because it sorts the unnamed controllers (numbers) above the named controllers... alpha sort.


I didn't notice this before, but you are correct. It's completely alphabetical, which explains why even the NKS parameters weren't in the order I expected. Alphabetical. Ugh. No wonder Mario likes Logic so much ...



polypx said:


> It looks like the auto-populate option (Mike's advanced method ) just assigns the first 128 host assignments in order, is that right?


You mean "The way the cool kids do it"?  It actually works where you tell Maschine each slot position. Like this:


```
$Knob_01 -> automation_id := 0
$Knob_02 -> automation_id := 1
$Knob_03 -> automation_id := 8
$Knob_04 -> automation_id := 9
$Knob_05 -> automation_id := 15
```
That will place $Knob_01 and $Knob_02 on Page 1 in the first two slots. The other 6 knobs on Page 1 will be unassigned/empty. (Those would have been automation_id numbers 2 through 7, which I didn't use.)

Then $Knob_03 and $Knob_04 will be the first two knobs on Page 2, the next 5 knobs on Page 2 will be unassigned/empty, but the last knob on page 2 (automation_id = 15) will be $Knob_05.

I do these assignments all in one block, at the end of the init callback. That way I can see them all at once and know where they are assigned. Plus the NKS stuff for me is an afterthought after I've done everything else, so it's easier to just handle all of it at the end of the init.

This single block of all my knobs also makes things a little easier (for me, at least) to do the naming, since I can copy that block and substitute automation_id with automation_name, and that way I know I have them all covered. I also do "help" by copying the same block. I still struggle with NKS (I eventually had to make a "How to" video ... for myself!), so I have to do it this way. Otherwise, I'll definitely forget something if these assignments are made as each ui_control is defined.


----------



## EvilDragon (Jun 3, 2021)

At the end of the day, while there are cool things about NKS and all, I don't think automation IDs should be catering to it, which cramps normal non-NKS DAW workflows by making the parameter list way more fragmented than it should be. Which is exactly why I order parameters logically by section, and then manually create NKS controller pages.


----------



## polypx (Jun 3, 2021)

Yeah, I think I basically agree with Mario here. It's tempting to use automation_id just for the NKS layout like that, but I usually include a lot of automation which isn't mapped to the NKS. I sometimes fill all 512 slots. Keeping this list organised is important, Cubase (and I guess most non-Logic DAWs) present the list in order, so you have all your compressor controls together, all your filter controls together, etc.


----------



## Mike Greene (Jun 3, 2021)

That's interesting. I sorta figured nobody actually used those parameter lists in various DAWs. I only recently knew they even existed, because I stumbled across it one day in Logic. (Totally by accident, and that's when I noticed the weird ordering and all the blank slots.) But I assumed that everybody did automation by right-clicking a knob, then using CC controllers, rather than scanning the parameter list. I guess I need to rethink that.

Logic orders the parameter list alphabetically, but it sounds like the other DAWs do it by automation_id number? So in my example above (I used automation_id slots 0, 1, 7, 8, 15), the parameter list would show my first 2 controls, then 6 empty slots, then my next 2? That's what you mean when you say "fragmented"? If so, then I agree thats's ugly, so tell me if you think this idea would work:

1. I do the numbering how I do it now, specific to how I want the NKS layout.
2. Commit to a final NKS layout and click Apply and Save in Maschine.
3. Then I renumber all the automation-id's so they would be in logical DAW order.
So my nki would already have the NKS knobs how I want them, but the KSP script sends a different order to the DAWs. Would that work?

A little off topic, but I'm prioritizing NKS because I'm trying to make my instruments more accessible for blind people. That's why I make so many changes to the NKS knobs layout, because I'm trying to make my instruments usable entirely through the knobs, with no interaction with the GUI necessary. So as I test the instrument in "NKS Knobs Only" mode, I do a lot of tweaks as I discover what the best workflow is. For me, these tweaks, especially when they involve moving entire pages, are much easier to do in KSP. Plus I'm slow at adopting different methods, so I'm sticking with it.


----------



## polypx (Jun 3, 2021)

Yes to the first question... in Cubase it's shown the same way as the Host Automation sidebar in Kontakt... in order, with gaps if there are gaps. 

Re second question, I'm pretty sure it won't work. NKS uses the host automation, so if you change that you break the NKS map you made earlier.


----------



## EvilDragon (Jun 3, 2021)

Yeah that won't work.


----------



## Mike Greene (Jun 3, 2021)

~sigh~ There goes my brilliant plan...

Okay, so I'm looking at the Host Automation sidebar (literally the first time I've looked there - yeah, I know...) and as we'd expect, the parameter names don't include the NKS page names. For example, on the NKS display, I have an Attack page, with a knob labeled "Articulation," and on the Release page I have a knob also labeled "Articulation."

That's no problem on an NKS display, because they're on labeled pages. But in the Host Automation list, there's no indication for which element/page each "Articulation" knob belongs to. (I had noticed this before in the Logic parameter list. There were a whole bunch of controls named "Volume," for instance.)

I'm reluctant to rename the knobs "Attack Articulation" and "Release Articulation," because then the NKS display would have to compress/abbreviate the names. How do you guys handle that?


----------



## polypx (Jun 4, 2021)

Depends on how obvious it is from context. I'll occasionally repeat names when it's obvious (perhaps I'm repeating the same controls for a bunch of mics, all grouped in the same way ... Mic 1 Level, Pan, Mic 2 Level, Pan are all just "LEVEL", "PAN") ... or sometimes clarify with prefixes if it's not obvious from it's location (ie. "AEG Release", "FEG Release") and remove the "FEG" distinction on the NKS pages only.


----------



## maxchristensenaudio (Jun 4, 2021)

Butting in with an amateur question if I may.
Why do you need automation IDs? All automatable controls are automation enabled by default.
The only use case I could imagine is forbidding automation for certain controls or CC numbers


----------



## Mike Greene (Jun 4, 2021)

maxchristensenaudio said:


> Butting in with an amateur question if I may.
> Why do you need automation IDs? All automatable controls are automation enabled by default.
> The only use case I could imagine is forbidding automation for certain controls or CC numbers


You're thinking of "allow_automation". You're right that it's mostly unnecessary, although sometimes you might want to disallow a control that is automation enabled by default. "allow_automation" is Step 1. Then step 2 is:

"automation_id" is what we're talking about here, and is used to assign ID numbers to each ui_control (0 to 127 in NKS, 0 to 511 for DAWs), so they'll display in a certain order. When you first start making it so an NKS keyboard can display the knobs, "automation_id" is like the first draft of what order those knobs will show up on the keyboard. (In my case, I'd like it to also be the final draft.  )

There's also "automation_name", where you name that knob, like what Dan (polypx) and I were talking about in the last couple posts.


----------



## EvilDragon (Jun 4, 2021)

I always, always, always, nicely name automation parameters. I never repeat names because that will be confusing to users in a normal DAW host automation workflow.


----------



## maxchristensenaudio (Jun 5, 2021)

And the reason one would want to do this is....
When you say NKS, do you mean Kontakt Player libraries with Komplete support?
So the user would then see on his machine or wherever: Knob1: "Dynamic", Knob 2 "Expression", Knob 3 "Whatever" etc... ? 

If I'm assuming that correctly then that makes sense to me, but what is the point of having automation IDs and names for the DAW?


----------



## EvilDragon (Jun 5, 2021)

Because certain people want to automate stuff with greater resolution than MIDI CCs, and prior to having $CONTROL_PAR_AUTOMATION_ID, you had to do this manually for each and every NKI in the library. Tedious. This way, the script sets it all up, and just presents the list of everything for automation to the DAW. Much easier and nicer UX.


----------



## mussnig (Jun 5, 2021)

Mike Greene said:


> I sorta figured nobody actually used those parameter lists in various DAWs. I only recently knew they even existed, because I stumbled across it one day in Logic. (Totally by accident, and that's when I noticed the weird ordering and all the blank slots.) But I assumed that everybody did automation by right-clicking a knob, then using CC controllers, rather than scanning the parameter list. I guess I need to rethink that.


I'm using Ableton Live and most of the times I'm using the parameters that are provided by host automation instead of Midi CCs. The reason is that editing CC curves in Midi clips is quite tedious in Live's GUI. Sure, one could also use some M4L device to have CC curves in Arrangement View but I try to avoid M4L if possible (because it's a resource hog, in general). Also, it's nice if the automation lanes already have nice names (e.g., "Vibrato" instead of some CC number) although that can also be obtained by using racks.


----------

