kX Automation...automation

Discussion in 'Effects and the DSP' started by Maddogg6, Aug 26, 2008.

  1. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    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: Aug 26, 2008
  2. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    >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: Aug 26, 2008
  3. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    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.


    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.
     
  4. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    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)
     
  5. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    @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)?
     
  6. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    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... ??
     
  7. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    >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)
     
  8. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    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.
     
  9. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    You would have to know about such parameters ahead of time, and then just add code to filter those out based on the text.
     
  10. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    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...
    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...
     
  11. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    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.
     
  12. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    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! ---")
     
  13. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    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.
     
  14. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    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: Aug 26, 2008
  15. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    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: Aug 26, 2008
  16. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    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...
     
    Last edited: Aug 26, 2008
  17. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    :) 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: Aug 26, 2008
  18. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    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))?
     
  19. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Thanks Max... I seen this...

    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 :D)

    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.. ??
     
  20. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    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.
     

Share This Page

visited