Dane and KX Register Access

Discussion in 'Effects and the DSP' started by Maddogg6, Mar 15, 2007.

  1. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Hello,

    Ok so I'm reading a thread between Max and Lex and my heart dropped 10 feet (thats abut 3 meters) - when I read something about Lex dropping ProFx/SRC (maybe just joking.. ??)

    But it got me thinking about how an average Joe (read: using Dane) be able to make plugins for things like I2S Inputs (that are accessed with SRC as well as FXBuss) ?

    I see in SRC dane with Coax/Optical selected 'KX_IN(0x6)' and 'KX_IN(0x7)'
    The KX_IN shows as a keyword in dane editor - BUT if I try to compile that, Dane gives an error because of the '('.

    Is this something that can only be accessed with C++?
    Or are the KX_IN and KX_FX translated from something else.?

    Thanks in advance,

    Mark
     
  2. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    >Is this something that can only be accessed with C++?

    yep.
     
  3. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    LoL.
    No not joking. More like "why bother changing it".

    I haven't DL-ed latest 3538xyz^2 version,
    but there used to be a very old SRC source code in the sdk.
    Although that code really sucks you can see how it's done in principle.

    PS:
    hmm,.. to be honest, I cant remember for sure if it was *that* code that sucked.
    All I know is that the older (included) profx , mx6 code etc. etc. sucked:)
     
    Last edited: Mar 15, 2007
  4. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    :rofl:
     
  5. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    :evil:
     
  6. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    LOL - Thanks guys
    lol - I told you 100,000,000,000,000 times - no more exaggerations. :D

    I'll see if I can't get enough tylonol (extra strength) to tackle... erm, make heads or tails of that enough for a copy paste thingy/hack ... IIRC there were skin bugs, but I don't think I used the bundled ProFx much enough to remember if the SRC was skinned or not. Im thinking I may need to remove extra skinning code or something.. ??

    Maybe hacking prolog would be easier to grasp if so.. ?? but then theres the dane stuff to deal with... ??? wheres that tylonol at now..?? :D
     
  7. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Only bare minimum C++ is needed. To use these hardware registers, you really only need to make changes to the da_yourplugin.cpp file, otherwise it is the same as any other C++ plugin (it can be as complicated or simple as you want).

    i.e.
    If you do not need a GUI, or parameters (and you are not checking for model specific stuff), etc (i.e more like Dane only plugin), then much of the C++ code can be eliminated.

    IIRC, you only need the following:

    request_microcode()
    get_plugin_description()
     
    Last edited: Mar 16, 2007
  8. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    Accessing those 'special I/O registers' has nothing to do with the GUI part of a plugin, hence nothing to do with "skinning" code at all.

    EDIT:
    ah, Russ posted approx at the same time:)
     
  9. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Thanks Russ

    Well, my point I was trying to make was - if there is any code relating to skinning in that SRC (new one (V3) definitly has skinning done on it) - will likey 1) cause me confusion 2) I re-create a skin problem *if* one existed and I copy paste stuff from that - thats all.

    I'll need to play around more with that tho..

    edit: Im still struglling trying to understand the C++ stuff - not to mention much of the dane too..
    Like how do I export to C++ from dane editor - if I cant rely on the code being correct - it wont compile. as a for instance - I'm still not grasping stuff like that as well. /edit

    Thanks again guys.
    Mark
     
  10. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    If the Dane code is valid (i.e. works as a Dane only plugin) then exporting from Dane should produce the correct code. The only issue is with the plugin name, as it auto-generates the C++ name using the plugin name. For this reason it is easier to name your plugin using C++ naming conventions (use the name your C++ code uses (using correct case, etc), and only for the purpose of exporting the code), and then change the name where it appears in quotes, to the name you want the plugin to use (or change it as Lex suggested in the other thread, either way minor editing of the da_yourPlugin.cpp is needed).

    i.e.
    Code:
    char *[COLOR=DeepSkyBlue]PluginName[/COLOR]_copyright="plain text here";
    char *[COLOR=DeepSkyBlue]PluginName[/COLOR]_engine="plain text here";
    char *[COLOR=DeepSkyBlue]PluginName[/COLOR]_comment="mostly plain text here ($nobypass, etc. being exceptions)";
    char *[COLOR=DeepSkyBlue]PluginName[/COLOR]_created="plain text here (date)";
    char *[COLOR=DeepSkyBlue]PluginName[/COLOR]_guid="the plugin's GUID";
    char *[COLOR=DeepSkyBlue]PluginName[/COLOR]_name="the plugin's name in plain text";
    int [COLOR=DeepSkyBlue]PluginName[/COLOR]_itramsize=0,[COLOR=DeepSkyBlue]PluginName[/COLOR]_xtramsize=0;
    dsp_register_info [COLOR=DeepSkyBlue]PluginName[/COLOR]_info[]={...};
    dsp_code [COLOR=DeepSkyBlue]PluginName[/COLOR]_code[]={...};
    
    Everywhere the name is highlighted (above) should be the C++ name. That should be the only thing that might be wrong when exporting using the kX Editor.
     
  11. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Well - thats the thing - I cant export known working dane code when trying to use KX registers like 'KX_IN(0x0)' - as it errors out with the '( )' (parentheses) is what I meant. But yes - I understand about changing names as a later step.
     
  12. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    Yes, but that is not Dane only code. For that you would have to use different registers (or better, use 0) in place of the hardware registers in order to export it, and then manually edit the da_... file to add the hardware registers.

    i.e.
    SRC set to FxBus 0/1 (just as an example):

    Code:
    macs      Left,  0x0,  [COLOR=DeepSkyBlue]KX_FX(0x0)[/COLOR],  0x7fffffff;
    macs      Right,  0x0,  [COLOR=DeepSkyBlue]KX_FX(0x1)[/COLOR],  0x7fffffff;
    
    ; change to
    
    macs      Left,  0x0,  [COLOR=DeepSkyBlue]0[/COLOR],  0x7fffffff;
    macs      Right,  0x0,  [COLOR=DeepSkyBlue]0[/COLOR],  0x7fffffff;
    
    Export it to C++, then edit the da_... file as such:

    Code:
    dsp_code src_code[]={
        /* { instruction, R, A, X, Y } */
        { 0x0,0x8000,0x2040,[COLOR=DeepSkyBlue]0x2040[/COLOR],0x204f }, /* first instruction  */
        { 0x0,0x8001,0x2040,[COLOR=DeepSkyBlue]0x2040[/COLOR],0x204f }, /* second instruction */
    };
    
    // change to
    
    dsp_code src_code[]={
        /* { instruction, R, A, X, Y } */
        { 0x0,0x8000,0x2040,[COLOR=DeepSkyBlue]KX_FX(0x0)[/COLOR],0x204f }, /* first instruction  */
        { 0x0,0x8001,0x2040,[COLOR=DeepSkyBlue]KX_FX(0x1)[/COLOR],0x204f }, /* second instruction */
    };
    
    Again, SRC was just used as an example (and the SRC plugin is a little more complicated due to it's dynamic nature), and the above should only be used as an example of using these hardware registers with your own plugin, etc.


    BTW: The above is usually written using the value instead of the 'KX_FX(0x0)', etc, but either way should work.

    i.e.
    Code:
    dsp_code src_code[]={
        /* { instruction, R, A, X, Y } */
        { 0x0,0x8000,0x2040,[COLOR=DeepSkyBlue]0x2400[/COLOR],0x204f }, /* first instruction  */
        { 0x0,0x8001,0x2040,[COLOR=DeepSkyBlue]0x2401[/COLOR],0x204f }, /* second instruction */
    };
    
    See dsp.h to see where the above values come from.
     
    Last edited: Mar 16, 2007
  13. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    * scratches nogin *

    Err - thanks, I guess I'll have to come back to all this when I get a better handle on all this - but I gotta say - its not a simple thing. - for me anyway.

    I think I get the jist of what your saying - I gotta change a dummy # with the HW register after I export to C++ from dane. So I guess I need to trust the dane is correct - or need to re-compile DLL for every attempt in dane changes.

    It looks like dsp.h is the 'road-map' the dane compiler uses to change all the reg's to when export to C++... or maybe all compile dane even...

    Thanks Russ.
     
  14. Max M.

    Max M. h/h member-shmember

    Joined:
    Dec 7, 2002
    Messages:
    2,690
    Likes Received:
    9
    Trophy Points:
    63
    >It looks like dsp.h is the 'road-map' the dane compiler uses to change all the reg's to when export to C++...

    a sort of...

    btw. you can use all those definitions to have a bit more human-readable stuff when editing 'C++ exported code'

    e.g.
    Code:
    #include "dsp.h"
    {
        {MACS, 0x8000, C_0, KX_FX(0x0), C_7fffffff},
        {MACS, 0x8001, C_0, KX_FX(0x1), C_7fffffff}, 
    }
    is equal to
    Code:
    {
        {0x0, 0x8000, 0x2040, 0x2400, 0x204f},
        {0x0, 0x8001, 0x2040, 0x2401, 0x204f}, 
    }
    p.s. see surrounder_dsp_tags.h for example
     
    Last edited: Mar 16, 2007
  15. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    That is generally the way it is done (although some plugins do it a little differently (prolog, epilog, Surrounder+, etc).

    i.e.
    If you change Dane code, re-export to C++, re-compile (any changes to a C++ plugin need to be re-compiled anyway). If it is only a few instructions you could probably just edit the da_file easily enough, but with more instructions and more registers, re-exporting would be easier (and helps to ensure that your register names are mapped correctly, etc (if any of that was changed)).
     
  16. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    1.But the old SRC code included in the SDK's fxlib is not 'skinned'!
    Same as the included kxlt versions which btw also use those I/O register 'tricks'.
    ProFx v3.x source code (the skinned one) is not included in any distro!

    2. Follow Russ's instructions. In other words;

    Since we can not enter stuff like;
    macs Left, 0x0, KX_FX(0x0), 0x7fffffff;
    into dane editor,
    we simply enter 'dummy' Dane code instead;
    macs Left, 0x0, 0, 0x7fffffff;
    were in this case the '0' acts as a placeholder for KX_FX(0x0).
    So after exporting to C++ just substitute that '0' with KX_FX(0x0) in the da_plug.cpp file.

    This is just one way of doing it.

    EDIT:
    Ah, more help is/was on the way.
    Lol maddog, you can't go wrong now:)
     
    Last edited: Mar 16, 2007
  17. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    Ok I understand this - I guess I was fixated on writing working dane plugin *then* export C++ to add finishing touches (slider scaling, switches, etc..) in VC, but when dealing with HW registers this is not possible, so I guess it will force me to using very simple dane for that until I get better at this stuff.

    Just not very intuitive for my limited programming-able brain :D
     
  18. Lex Nahumury

    Lex Nahumury DH Senior Member

    Joined:
    Jan 5, 2003
    Messages:
    1,944
    Likes Received:
    6
    Trophy Points:
    0
    Well, most plugins that use those 'special HW I/O register' *are* simple dane plugins!!
    And even if you would use those regs in a 'big' plugin, the code lines containing them
    are simple per definition.
     
  19. Maddogg6

    Maddogg6 Tail Razer

    Joined:
    Jun 21, 2005
    Messages:
    4,027
    Likes Received:
    26
    Trophy Points:
    0
    you know me I had a hair-brained idea :eek: that most likely meant 'not so simple' dane AND HW registers too... but I'll wait on that one too I guess .. lol

    Baby steps suck!!!!! :evil:
     
  20. Russ

    Russ Well-Known Member

    Joined:
    Jan 17, 2005
    Messages:
    5,722
    Likes Received:
    13
    Trophy Points:
    48
    The reason I said "or better, use 0" is because, if you were to create dummy registers, then you would have to edit the 'dsp_register_info' structure as well, in order to remove the dummy registers, and this can mess up the register mapping for any registers that follow the dummy's (although this is not difficult to fix, it might be more confusing for you).

    However, for the situation that you describe:

    You can use dummy inputs (or outputs depending on which hardware I/O registers you want to use) in your Dane code, but declare these inputs/outputs *after* any other inputs/outputs. Then you can test your Dane only version by connecting SRC or ADC, or whatever to those inputs (i.e. you will have fully working Dane only version). Once you are done testing, export it to C++, and delete the dummy registers from the 'dsp_register_info' structure (they should be the last of the inputs/outputs, so it should be relatively simple to do, and it should not mess up the mapping of the other registers), and then edit the 'dsp_code' structure, replacing the dummy inputs/outputs with the hardware I/O registers (or you could, at the very last step, just delete them from the Dane version, and replace them with 0, and export to C++, as with my previous example (either way, you are able to test the Dane code without having to do anything in C++ until you are ready)).

    Again, once you start to actually do this stuff, things become clearer and you will figure out which tricks work the best for you (and maybe figure out some of your own), etc.

    <edit>
    If the above completely confused you (sorry), in other words, just use regular inputs/outputs for testing, and connect them to another plugin that gives access to the hardware I/O registers that you want to use.
    </edit>
     
    Last edited: Mar 16, 2007

Share This Page

visited