kX Automation...automation

Maddogg6 · Aug 26, 2008, 06:18 AM

Ok - so I had this lame brained idea and was hoping it could be done without using kX API (cuz I find using VC so darn cumbersome, and C/C++ isnt very friendly to this very BASIC brained bone-head)

So anyway, I am looking at kX Control (Console) and see I can list all the plugins loaded by using the 'mp' command. What I was hoping to find is something that lists all the plugins controls that can be automated with kX Automation.

Is there a kX Console command that lists these? How does kX Router find out what controls are automatable?

Anyways - my idea is this...

Run a script that outputs 2 files that are text in nature (thus with in my realm of possibilites from a technical stand point);
1 file that ends up as a kX Automations config file
and another file that saves Sonars MIDI controller info.
Todo this I would
1) lists every plugins automatable control
2) Assign each plugin control a CC and midi channel
3) format a text file appropriate for storing kX Automation config with automatically assigned midi controllers. Simply starting with midi channel 1, CC#1 and counting up all CC's until 127, then increment the midi channel and do that loop all over again - until all plugins and their controls are iterated through.

4) Once an array of kX plugin controls names and assigned midi controllers is made - I could store that in Sonar's master.ins file

So - anytime I make a custom DSP config - I would run this script that prepares these 2 files, I can even do a shell command to load the kX Automations settings file - and sonar will read the master.ins file upon loading Sonar.

This would help sooooo much to be able to accomplish this.

I see in kX Console it even takes the 'renamed' value of plugin names which is great.

And if VC/kX API is the only way... maybe I will just have to bit the bullet and give that a try, but if kX console can do any part of this would make it that much easier for stupid me.

Any direction would be much appreciated.

edit: woot - mp (plugin ID) shows all the registers, now to figure out what are controls as opposed to input, output, temp or static /edit.

edit2: Ok looking at kX Automations config - it looks like I will need to use a look up table for all the missing info that kX console doesnt seem to provide. ie..

GUID (plugin), MIN, MAX, ndx_xx, guid_xx, mask_xx

ndx_xx resolves the CC, but a look up table is quite doable. so stay tuned... /edit2

Max M. · Aug 26, 2008, 04:00 PM

>1) lists every plugins automatable control

that's pretty easy

>2) Assign each plugin control a CC and midi channel

that's problematic - there's no interface to assign control/parameters externally
(well, actually - there is one in "kX Manager API" - but it's never finished - i doubt if it's working at all)

>3) format a text file appropriate for

same as 1)

---

Besides above - the 3) needs you to define more details on how exactly you will assing things (will it be some GUI (similiar to kX's own window for example), or will it be just bunch of kxctrl like console commands, or etc.)

Maddogg6 · Aug 26, 2008, 05:53 PM

Quote:

Originally Posted by Max M.

that's problematic - there's no interface to assign control/parameters externally
(well, actually - there is one in "kX Manager API" - but it's never finished - i doubt if it's working at all)

Thanks for that info Max... I was hoping to avoid kX API for this anyway... and think I have found a way to do it.

Quote:

Originally Posted by Max M.

Besides above - the 3) needs you to define more details on how exactly you will assing things (will it be some GUI (similiar to kX's own window for example), or will it be just bunch of kxctrl like console commands, or etc.)

It will be kX Console commands *and* SW generated .kx files that I can SHELL execute to have kX receive kX Automation settings. (Then manipulating 2-3 Sonar config files to have sonar know what the controllers are and have 'friendly Names like 'ProFX:MX6 input_level1')

I am pretty sure I can do this - how user friendly it will be in the end is another story. I think I can at least popup some winapi file and/or directory requesters to find file locations etc..
Ill ask the user how many cards, and which device
use the 'ds -2' command to get device names... etc..

Any ideas for automating the making of the plugin lookup table would be helpful/appreciated. The hard way is to 1 by 1 add plugins to kX DSP and assign all meaning automatable parameters a CC - save file - and make a program to build a table based on the saved data in resulting .kx files, and the MP command (pluginID, plugin Names...?? Still working out the kinks on that part.) that may need to be more interactive - read all the mp 1 registers and manually choose registers that can be automated...

Or maybe something with autoit, FBSL or whatever to manually assign (but automated) all plugins automatable parameters to even just the CC#0/CH1 just so all the - possible extract info displayed in kX AUtomation applet - their probably just common controls with text assigned...??

Still thinking about that part - worst case is all manually made table, but doable.

Max M. · Aug 26, 2008, 06:38 PM

aha, interesting, yeah, i think that just generating *.kx file with automation assigments can serve as "2) Assign each plugin control a CC and midi channel"

Regarding the rest, just one important note: it's all better to implement with self-contained console-tool (well, right - written in C/C++)
The problem is that you are not able to get any info of "parameters" with kxctrl - and it is the "parameters" which are automated not the "registers".
So, well, yep - you can build some big-parameter-info-table and then extract plugin info basing on that table and kxctrl output - but to me this seems to be overkilling (well, hard to say more since i'm not familiar with those scripting tools you use)
With the "self-contained" tool you would just iterate through loaded plugins, query their parameters (really a few lines of code) and then build whatever files you need (e.g. *.kx (containing only automation settings) and other files (*.ins) etc)

Russ · Aug 26, 2008, 06:46 PM

@Max
There is no way to get the iKXManager, iKXPluginManager, or iKXPlugin interface from iKX, right? Do you know of a way to access those interfaces outside of a plugin or addon (this would seem to be necessary to create a simple console program to do such a thing)?

Maddogg6 · Aug 26, 2008, 06:55 PM

Quote:

With the "self-contained" tool you would just iterate through loaded plugins, query their parameters (all just about 20 lines of code) and then build whatever files you need (e.g. *.kx (containing only automation setting) and other files (*.ins) etc)

Yeah - that would be easier than managing a table... Ill look at the kX SDK to see what may be involved in querying automation parameters of plug-ins... but that is also involving a learning curve - as I am already somewhat familiar with other languages...

unless - if any of kX API is COM interface - I could maybe interface with that with DISPHELPER - but hear that COM is also a PITA... I dunno, would probably be easier to use C/C++ and kX SDK.. ?? Still playing with the idea... so far I am opening kxconsole and piping the info into strings and spliting up the info (pluginID, Name & pluginGUID)

Next I will compare using a scripting language to build a table versus using kX API to query automation controls available.
But - see - theres that ProFx:MX6 '__Do Not Use' parameters - that I would prefer to avoid using, and the table idea could do that... ??

Max M. · Aug 26, 2008, 06:58 PM

>There is no way to get the iKXManager, iKXPluginManager, or iKXPlugin interface from iKX, right?

Yep, no, there's not - (no surprise) as iKXPlugin instances are created by kxmixer (and living there) while kxapi is available with no kxmixer running.
Hmm, i did not really think of that - right.

Then i propose a hack: iterating through loaded plugins with kxi and then instatiate iKXPlugin on your own right from within corresponding kxl and then query its parameters.
(though this will be more complicated then i thought)

Russ · Aug 26, 2008, 07:20 PM

I was thinkin it would probably be easiest (under the circumstances) to just create a plugin (plugins have access to iKXPluginManager) that dumps the info upon the push of a button (or whatever).

Not quite as easy as a simple console app, but it has got to be easier than parsing saved config files, etc.

Russ · Aug 26, 2008, 07:36 PM

Quote:

Originally Posted by Maddogg6

But - see - theres that ProFx:MX6 '__Do Not Use' parameters - that I would prefer to avoid using, and the table idea could do that... ??

You would have to know about such parameters ahead of time, and then just add code to filter those out based on the text.

Maddogg6 · Aug 26, 2008, 08:21 PM

Quote:

Originally Posted by Russ

I was thinkin it would probably be easiest (under the circumstances) to just create a plugin (plugins have access to iKXPluginManager) that dumps the info upon the push of a button (or whatever).

Not quite as easy as a simple console app, but it has got to be easier than parsing saved config files, etc.

For me, a console app that output controls would be easiest for me to interface to.

If only kxctrl could give indication what registers were available in kX automation - at first, I thought the '[800x]' indicated this, but I found to be proven wrong.
Is it not possible for some editing of kxctrl.exe to output needed data - or was the comments about *any* console app not able to access iKXPlugin.. I guess this confuses me about what kX API console apps can do...

Quote:

Then i propose a hack: iterating through loaded plugins with kxi and then instatiate iKXPlugin on your own right from within corresponding kxl and then query its parameters.
(though this will be more complicated then i thought)

so, is it possible - or no? Do I bother researching this?

So far looking at kX SDK headers - I dont see the mechanism/query in iKXPlugin...

Maddogg6 · Aug 26, 2008, 08:24 PM

Quote:

Originally Posted by Russ

You would have to know about such parameters ahead of time, and then just add code to filter those out based on the text.

see thats the stuff that would make a C/C++ application more complicated for me - Im capable of string manipulations in other languages... but for C/C++ its an added learning curve.

Russ · Aug 26, 2008, 09:00 PM

Really it is not as hard as you probably think it is:

i.e.
(where "szName" is a string (std::string or CString (MFC)) that holds the parameter name used for automation)

if (szName == "---Do Not Use! ---")

Maddogg6 · Aug 26, 2008, 09:24 PM

Quote:

Originally Posted by Russ

Really it is not as hard as you probably think it is:

i.e.
(where "szName" is a string (std::string or CString (MFC)) that holds the parameter name used for automation)

if (szName == "---Do Not Use! ---")

lol - says the guy who already knows this stuff..

anyway - it looks like I still need to ..
Add at least one automation control for each plugin, save file - to get that guid_x info. and still go with a table anyways...

Still looking at all this tho...

Thanks for the input of course, as always it is much appreciated.

Max M. · Aug 26, 2008, 09:32 PM

i've sketched some sceleton tool to show my idea, just a console tool that lists loaded plugins and prints their parameters.

download the binary and it's source here: Some Download
(the binary is compiled for 3543 - i don't know if it's compatible with later/earlier versions)

There're few problems so far (it's not safe, *.da plugins are not supported) - but everything can be solved further.

Maddogg6

>m capable of string manipulations in other languages... but for C/C++ its an added learning curve.

Ah, just look at the sources - not a higher mathematics - just read the "printf" docs
comparison:

Code:

if (!strcmp(name, "---Do Not Use! ---"))
{
    // skip me
}

and no magic

Max M. · Aug 26, 2008, 09:44 PM

anyway - it looks like I still need to ..
Add at least one automation control for each plugin, save file - to get that guid_x info. and still go with a table anyways...

You can find all guids in Registry ("HKEY_CURRENT_USER\Software\kX\Plugins").

Either way i'd suggest the other way around (to avoid any manual manipulations):
We could generate correspoding *.kx file (generate by "the tool") with whatever automation set for each parameter: e.g. just something like:
plugin 0 / parameter 0 -> Ch.0 / CC0
plugin 0 / parameter 1 -> Ch.0 / CC1
plugin 1 / parameter 55 -> Ch.1 / CC55
etc. etc.
(whatever flat assignment that can be hardcoded)

The problem with this is that *.kx will contain only automation settings (and therefore working only with the DSP config it was generated for)
But as soon as you have such *.kx you can load it and then save a new one containg all the settings.

GUID (plugin), MIN, MAX, ndx_xx, guid_xx, mask_xx
ndx_xx resolves the CC

ndx_xx is a parameter index
and CC is encoded by mask_xx (resolves to midi message type and value)

Russ · Aug 26, 2008, 10:16 PM

Quote:

Originally Posted by Max M.

i've sketched some sceleton tool to show my idea, just a console tool that lists loaded plugins and prints their parameters.

Hmm interesting...

This is an example of the type code I was thinking to use in a plugin (in a button click handler)

Code:

    for(int i=0; i<MAX_PGM_NUMBER; i++)
    {
        dsp_microcode mc;
        iKXPlugin * pPlugin;
        int nParamCount;
        kx_fxparam_descr pParamDescription;

        CString szPluginName, szParamName, szGUID, strDebug;
        int nType, nMinVal, nMaxVal;
    
        if(plugin->ikx->enum_microcode(i, &mc)==0)
        {        
            // ignore plugins that are not enabled?
            if (mc.flag & MICROCODE_ENABLED)
            {        
                pPlugin = plugin->pm->find_plugin_by_id(i);            
                nParamCount = pPlugin->get_param_count();
                // ignore plugins that have no parameters
                if (nParamCount > 0) 
                {
                    szPluginName = mc.name;
                    szGUID = mc.guid;
                    strDebug.Format("%2d: %s (%s)\n", i, szPluginName, szGUID);
                    OutputDebugString(strDebug); 
                
                    for (int j=0; j<nParamCount; j++)
                    {
                        pPlugin->describe_param(j, &pParamDescription);
                        szParamName = pParamDescription.name;
                        nType = pParamDescription.type;
                        nMinVal = pParamDescription.min_value;
                        nMaxVal = pParamDescription.max_value; 
                        if (szParamName.Compare("----Do not use! ----") != 0)
                        {
                            strDebug.Format("\t \t \t Param: [%s]\tIndex: [%d]\tType [%d]\tMinVal: [%d]\tMaxVal: [%d]\n", szParamName, j, nType, nMinVal, nMaxVal);
                            OutputDebugString(strDebug);                    
                        }
                    }      
                    OutputDebugString("\n");
                }
            }        
        }
    }

(obvioulsy replacing debug output with file output or whatever)

BTW: I am not sure what the guid listed in the kx file is...

Max M. · Aug 26, 2008, 10:18 PM

compare that to my sources (same stuff - the only trick is to get iKXPlugin)
p.s. and your way is better of course - when used from within kX Add-On.

Russ · Aug 26, 2008, 10:35 PM

Yeah, that it a neat trick

Now couldn't you use your code to find the first .kxl plugin, instantiate that, and use it to grab the iKXPluginManager pointer from that plugin, and then use that pointer to get the iKXPlugin pointer for the rest (instead of instantiating each one manually (then you do not have to worry about .kxl vs .da, etc))?

Maddogg6 · Aug 26, 2008, 10:39 PM

Thanks Max... I seen this...

Quote:

/* note:
We are not going to emulate kxmixer here, so if
some smart-ass plugin tries to access any advanced
iKXPlugin function before describe_param() we're
(likely) to crash. Well, just let it burn -
It is the evil Pinocchio for itself. */

And it seems FXMix makes it crash... (probably to add controls to kX Mixer - I would presume...)

But I can use this to automate making a table, add the 'problem' plug-ins manually.

I presume that changing the '.kxl' to '.da' would list dane only plugins...?? I have not tried yet, but that would be simple enough.

But I guess I dont see anyway around using some sort of table otherwise. Unless I am completely missing something obvious. (always possible

)

Quote:

>m capable of string manipulations in other languages... but for C/C++ its an added learning curve.

Ah, just look at the sources - not a higher mathematics - just read the "printf" docs

I am fairly certain, parsing text from piped console output and/or - from files uses more than just printf() - no?
I must not be seeing a bigger picture here or something.. ??

Max M. · Aug 26, 2008, 10:39 PM

Nope, look at alloc_plugin() function.
We don't have kxmixer there - we are emulating it themselves

(hense no ikx, pm etc.)

>And it seems FXMix makes it crash...

No crash for me with K2 and 3543 and default config - but (if there's no other good way around) i suppose some "blacklisted" filter/table would do the trick.

Max M. · Aug 26, 2008, 10:45 PM

For the *.da - we can't get iKXPlugin instance for it, but we can use initial microcode info, get registers array through get_microcode and scan it for 'control' registers.
(parameters for *.da are just 'control' gprs with min/max always being 0/0x7fffffff)

I am fairly certain, parsing text from piped console output and/or - from files uses more than just printf() - no?
sure, but we don't need any pipe of console i/o if "the tool" is doing everything
(e.g. we don't need to analyse the output of kxctrl this way - do we?)

Russ · Aug 26, 2008, 10:48 PM

Quote:

Originally Posted by Max M.

Nope, look at alloc_plugin() function.
We don't have kxmixer there - we are emulating it themselves

(hense no ikx, pm etc.)

>And it seems FXMix makes it crash...

No crash for me with K2 and 3543 and default config - but (if there's no other good way around) i suppose some "blacklisted" filter/table would do the trick.

I see, yeah that makes sense...

FxMix does not cause crash for me either (k1 (default config) 3545b)

Maddogg6 · Aug 26, 2008, 11:04 PM

my bad - FXMix Happens to be the last plugin on my first card...

I wrongly assumed it would query the selected device/card... But it still shows no controls on a few plugins - Are the ones missing '.da'?

I thought they were all .kxl (MX6..?) ..??

Code:

-----------------------------------------------------------
 1: FXBus 12/13 (6e302861-0df9-4b21-b91a-6631220da97d)
    Parameters (name [index] [min max]):
        "Source" [0] [0 126]

-----------------------------------------------------------
 2: FXBus 10/11 (6e302861-0df9-4b21-b91a-6631220da97d)
    Parameters (name [index] [min max]):
        "Source" [0] [0 126]

-----------------------------------------------------------
 3: Reverb R (80100009-0ADF-11D6-BFBC-D4F706E10C52)
    Parameters (name [index] [min max]):
        "Bypass" [0] [0 1]
        "Mute" [1] [0 1]
        "Dry On/Off" [2] [0 1]
        "DryMix" [3] [99 3]
        "Wet On/Off" [4] [0 1]
        "WetMix" [5] [99 3]
        "Early On/Off" [6] [0 1]
        "Rev On/Off" [7] [0 1]
        "Early/Rev" [8] [0 100]

-----------------------------------------------------------
 4: Stereo Chorus (80100003-0ADF-11D6-BFBC-D4F706E10C52)
    Parameters (name [index] [min max]):
        "Level" [0] [0 100]
        "InWidth" [1] [-50 50]
        "OutWidth" [2] [-50 50]
        "Feedback" [3] [0 99]
        "Delay" [4] [0 200]
        "Mod Depth" [5] [0 100]
        "Phase" [6] [-180 180]
        "Mod Rate" [7] [0 1000]
        "Invert Feedback" [8] [0 1]

-----------------------------------------------------------
 5: Delay A (80100006-0999-11D6-BFBC-D4F706E10C52)

-----------------------------------------------------------
 6: Phaser (ab0284b2-3caf-4850-84ca-6eb772cd68a4)
    Parameters (name [index] [min max]):
        "Dry" [0] [0 20]
        "Wet" [1] [0 20]
        "Feedback" [2] [-9 9]
        "CrossFeed" [3] [0 100]
        "Sweep Rate" [4] [1 100]
        "Sweep Range" [5] [0 52]
        "Frequency" [6] [50 1500]
        "Stages" [7] [0 2]

-----------------------------------------------------------
 7: MX6 (f02fc662-a8b0-45fa-bde5-459c23549314)

-----------------------------------------------------------
 8: k1lt (fc2acf07-5b4b-4c80-a157-1e6fd59909b6)
    Parameters (name [index] [min max]):
        "Out1/2" [0] [0 126]
        "Out3/4" [1] [0 126]
        "Out5/6" [2] [0 126]
        "Out7/8" [3] [0 126]
        "Out9/10" [4] [0 126]
        "Out11/12" [5] [0 126]
        "Out13/14" [6] [0 126]
        "DOO" [7] [0 1]

-----------------------------------------------------------
 9: FXBus 0/1 (6e302861-0df9-4b21-b91a-6631220da97d)
    Parameters (name [index] [min max]):
        "Source" [0] [0 126]

-----------------------------------------------------------
10: FXMix (2bfd1db1-46ca-4848-b690-c8fe4944370b)

Quote:

sure, but we don't need any pipe of console i/o if "the tool" is doing everything
(e.g. we don't need to analyse the output of kxctrl this way - do we?)

Ok - I see - I would use this in leu of kxctrl.exe - ok that makes sense... all this C/C++ code - makes my brain hurt/ makes me stupider

My original idea probably put blinders on me, along with not understand the C stuff completely.

I still dont see how we make the .kx file guid_x (its not the same as the one seen by editing a plugin - its shorter...

Quote:

[General]
device_1=SB0350 10k2 [b800]
[General - SB0350 10k2 (b800)]
descr=kX Saved Settings
version=5.10.00.3545 - debug
flag=0x800
[automation - SB0350 10k2 (b800)]
mask_1=0x8b2
flag_1=0x13
ndx_1=0x0
min_1=0x0
max_1=0x7fffffff
plg_id_1=0x5
guid_1=0xde313b53
flag_2=0xffffffff

They are the same for multiple instances of plugins.

edit: but this will make the table a lot faster, I can just add the guid_x manually later.

Max M. · Aug 26, 2008, 11:30 PM

It seems that MX6 needs plugin->init() call before it returns valid parameters count
- but also it crashes within plugin->init() - probably trying to access plugin->ikx or something.

Russ · Aug 26, 2008, 11:35 PM

It also seems to be missing params for stuff like prolog/epilog/xrouting...

Max M. · Aug 26, 2008, 11:49 PM

OK, updated the sources and the binary with workaround for MX6/MX8

Quote:

It also seems to be missing params for stuff like prolog/epilog/xrouting...

looks like they should be treated as plain *.da plugins (e.g. by searching for 'control' registers; though they have iKXPlugin code - they don't inplement get_param_count/describe_param functions)

Well, not a big deal - we'll add support for such stuff (raw da) in next series

Max M. · Aug 26, 2008, 11:55 PM

The guid_x item is a mistery for me too - i can't see anything related to it anywhere.
Seems to be some internal undocumented stuff (will ask E.)

Russ · Aug 27, 2008, 12:03 AM

Quote:

Originally Posted by Max M.

looks like they should be treated as plain *.da plugins (e.g. by searching for 'control' registers; though they have iKXPlugin code - they don't inplement get_param_count/describe_param functions)

Hmm, I did create a little test plugin to do this, and it does work with those plugins, so they must be implementing those functions, no?

Max M. · Aug 27, 2008, 12:34 AM

inside kxmixer - probably (if get_param_count() is not implemented then the base of iKXPlugin counts control registers on its own and then maintains anything related).
But it requires (well, i suppose) calling plugin->init() and plugin->request_microcode() and then will cause (in our enviroment) more plugins (Surrounder for example) to crash.

Well, of course it's a bit complicated - there're a lot of such tricks there - but workarounds possible (just not all at once

)

Russ · Aug 27, 2008, 01:00 AM

And as you said, all of those plugin do use "control" registers, so it should be easy enough to get the info for those plugins (the harder part is probably just bringing everything together, such that the program knows when to do it one way versus another way).

Aug 26, 2008, 04:00 PM	#2
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	>1) lists every plugins automatable control that's pretty easy >2) Assign each plugin control a CC and midi channel that's problematic - there's no interface to assign control/parameters externally (well, actually - there is one in "kX Manager API" - but it's never finished - i doubt if it's working at all) >3) format a text file appropriate for same as 1) --- Besides above - the 3) needs you to define more details on how exactly you will assing things (will it be some GUI (similiar to kX's own window for example), or will it be just bunch of kxctrl like console commands, or etc.) __________________ Last edited by Max M.; Aug 26, 2008 at 04:08 PM.

Aug 26, 2008, 06:38 PM	#4
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	aha, interesting, yeah, i think that just generating .kx file with automation assigments can serve as "2) Assign each plugin control a CC and midi channel" Regarding the rest, just one important note: it's all better to implement with self-contained console-tool (well, right - written in C/C++) The problem is that you are not able to get any info of "parameters" with kxctrl - and it is the "parameters" which are automated not the "registers". So, well, yep - you can build some big-parameter-info-table and then extract plugin info basing on that table and kxctrl output - but to me this seems to be overkilling (well, hard to say more since i'm not familiar with those scripting tools you use) With the "self-contained" tool you would just iterate through loaded plugins, query their parameters (really a few lines of code) and then build whatever files you need (e.g. .kx (containing only automation settings) and other files (*.ins) etc) __________________

Aug 26, 2008, 06:58 PM	#7
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	>There is no way to get the iKXManager, iKXPluginManager, or iKXPlugin interface from iKX, right? Yep, no, there's not - (no surprise) as iKXPlugin instances are created by kxmixer (and living there) while kxapi is available with no kxmixer running. Hmm, i did not really think of that - right. Then i propose a hack: iterating through loaded plugins with kxi and then instatiate iKXPlugin on your own right from within corresponding kxl and then query its parameters. (though this will be more complicated then i thought) __________________

Aug 26, 2008, 09:32 PM	#14
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	i've sketched some sceleton tool to show my idea, just a console tool that lists loaded plugins and prints their parameters. download the binary and it's source here: Some Download (the binary is compiled for 3543 - i don't know if it's compatible with later/earlier versions) There're few problems so far (it's not safe, .da plugins are not supported) - but everything can be solved further. Maddogg6* >m capable of string manipulations in other languages... but for C/C++ its an added learning curve. Ah, just look at the sources - not a higher mathematics - just read the "printf" docs comparison: Code: if (!strcmp(name, "---Do Not Use! ---")) { // skip me } and no magic __________________ Last edited by Max M.; Aug 26, 2008 at 09:55 PM.

Aug 26, 2008, 09:44 PM	#15
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	anyway - it looks like I still need to .. Add at least one automation control for each plugin, save file - to get that guid_x info. and still go with a table anyways... You can find all guids in Registry ("HKEY_CURRENT_USER\Software\kX\Plugins"). Either way i'd suggest the other way around (to avoid any manual manipulations): We could generate correspoding .kx file (generate by "the tool") with whatever automation set for each parameter: e.g. just something like: plugin 0 / parameter 0 -> Ch.0 / CC0 plugin 0 / parameter 1 -> Ch.0 / CC1 plugin 1 / parameter 55 -> Ch.1 / CC55 etc. etc. (whatever flat assignment that can be hardcoded) The problem with this is that .kx will contain only automation settings (and therefore working only with the DSP config it was generated for) But as soon as you have such .kx you can load it and then save a new one containg all the settings. GUID (plugin), MIN, MAX, ndx_xx, guid_xx, mask_xx ndx_xx resolves the CC ndx_xx is a parameter index and CC is encoded by mask_xx (resolves to midi message type and value) __________________ Last edited by Max M.; Aug 26, 2008 at 10:15 PM.*

Aug 26, 2008, 06:18 AM	#1
Maddogg6 Tail Razer Join Date: Jun 2005 Location: Bernyurass, AZ - USA Posts: 4,027 Rep Power: 0	kX Automation...automation Ok - so I had this lame brained idea and was hoping it could be done without using kX API (cuz I find using VC so darn cumbersome, and C/C++ isnt very friendly to this very BASIC brained bone-head) So anyway, I am looking at kX Control (Console) and see I can list all the plugins loaded by using the 'mp' command. What I was hoping to find is something that lists all the plugins controls that can be automated with kX Automation. Is there a kX Console command that lists these? How does kX Router find out what controls are automatable? Anyways - my idea is this... Run a script that outputs 2 files that are text in nature (thus with in my realm of possibilites from a technical stand point); 1 file that ends up as a kX Automations config file and another file that saves Sonars MIDI controller info. Todo this I would 1) lists every plugins automatable control 2) Assign each plugin control a CC and midi channel 3) format a text file appropriate for storing kX Automation config with automatically assigned midi controllers. Simply starting with midi channel 1, CC#1 and counting up all CC's until 127, then increment the midi channel and do that loop all over again - until all plugins and their controls are iterated through. 4) Once an array of kX plugin controls names and assigned midi controllers is made - I could store that in Sonar's master.ins file So - anytime I make a custom DSP config - I would run this script that prepares these 2 files, I can even do a shell command to load the kX Automations settings file - and sonar will read the master.ins file upon loading Sonar. This would help sooooo much to be able to accomplish this. I see in kX Console it even takes the 'renamed' value of plugin names which is great. And if VC/kX API is the only way... maybe I will just have to bit the bullet and give that a try, but if kX console can do any part of this would make it that much easier for stupid me. Any direction would be much appreciated. edit: woot - mp (plugin ID) shows all the registers, now to figure out what are controls as opposed to input, output, temp or static /edit. edit2: Ok looking at kX Automations config - it looks like I will need to use a look up table for all the missing info that kX console doesnt seem to provide. ie.. GUID (plugin), MIN, MAX, ndx_xx, guid_xx, mask_xx ndx_xx resolves the CC, but a look up table is quite doable. so stay tuned... /edit2 Last edited by Maddogg6; Aug 26, 2008 at 08:27 AM.

Aug 26, 2008, 06:46 PM	#5
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	@Max There is no way to get the iKXManager, iKXPluginManager, or iKXPlugin interface from iKX, right? Do you know of a way to access those interfaces outside of a plugin or addon (this would seem to be necessary to create a simple console program to do such a thing)?

Aug 26, 2008, 07:20 PM	#8
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	I was thinkin it would probably be easiest (under the circumstances) to just create a plugin (plugins have access to iKXPluginManager) that dumps the info upon the push of a button (or whatever). Not quite as easy as a simple console app, but it has got to be easier than parsing saved config files, etc.

Aug 26, 2008, 09:00 PM	#12
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Really it is not as hard as you probably think it is: i.e. (where "szName" is a string (std::string or CString (MFC)) that holds the parameter name used for automation) if (szName == "---Do Not Use! ---")

Aug 26, 2008, 10:18 PM	#17
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	compare that to my sources (same stuff - the only trick is to get iKXPlugin) p.s. and your way is better of course - when used from within kX Add-On. __________________ Last edited by Max M.; Aug 26, 2008 at 10:28 PM.

Aug 26, 2008, 10:35 PM	#18
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Yeah, that it a neat trick Now couldn't you use your code to find the first .kxl plugin, instantiate that, and use it to grab the iKXPluginManager pointer from that plugin, and then use that pointer to get the iKXPlugin pointer for the rest (instead of instantiating each one manually (then you do not have to worry about .kxl vs .da, etc))?

Aug 26, 2008, 10:39 PM	#20
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	Nope, look at alloc_plugin() function. We don't have kxmixer there - we are emulating it themselves (hense no ikx, pm etc.) >And it seems FXMix makes it crash... No crash for me with K2 and 3543 and default config - but (if there's no other good way around) i suppose some "blacklisted" filter/table would do the trick. __________________

Aug 26, 2008, 10:45 PM	#21
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	For the .da - we can't get iKXPlugin instance for it, but we can use initial microcode info, get registers array through get_microcode and scan it for 'control' registers. (parameters for .da are just 'control' gprs with min/max always being 0/0x7fffffff) I am fairly certain, parsing text from piped console output and/or - from files uses more than just printf() - no? sure, but we don't need any pipe of console i/o if "the tool" is doing everything (e.g. we don't need to analyse the output of kxctrl this way - do we?) __________________

Aug 26, 2008, 11:30 PM	#24
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	It seems that MX6 needs plugin->init() call before it returns valid parameters count - but also it crashes within plugin->init() - probably trying to access plugin->ikx or something. __________________

Aug 26, 2008, 11:35 PM	#25
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	It also seems to be missing params for stuff like prolog/epilog/xrouting...

Aug 26, 2008, 11:55 PM	#27
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	The guid_x item is a mistery for me too - i can't see anything related to it anywhere. Seems to be some internal undocumented stuff (will ask E.) __________________

Aug 27, 2008, 12:34 AM	#29
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,639 Rep Power: 69	inside kxmixer - probably (if get_param_count() is not implemented then the base of iKXPlugin counts control registers on its own and then maintains anything related). But it requires (well, i suppose) calling plugin->init() and plugin->request_microcode() and then will cause (in our enviroment) more plugins (Surrounder for example) to crash. Well, of course it's a bit complicated - there're a lot of such tricks there - but workarounds possible (just not all at once ) __________________ Last edited by Max M.; Aug 27, 2008 at 01:40 AM.

Aug 27, 2008, 01:00 AM	#30
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	And as you said, all of those plugin do use "control" registers, so it should be easy enough to get the info for those plugins (the harder part is probably just bringing everything together, such that the program knows when to do it one way versus another way).