Dane and KX Register Access

Maddogg6 · Mar 15, 2007, 01:08 PM

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

Max M. · Mar 15, 2007, 01:15 PM

>Is this something that can only be accessed with C++?

yep.

Lex Nahumury · Mar 15, 2007, 02:32 PM

Quote:

Originally Posted by Maddogg6

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.. ??)

LoL.
No not joking. More like "why bother changing it".

Quote:

Originally Posted by Maddogg6

I see in SRC dane with Coax/Optical selected 'KX_IN(0x6)' and 'KX_IN(0x7)'.................

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

Russ · Mar 15, 2007, 02:37 PM

Quote:

Originally Posted by Lex Nahumury

I haven't DL-ed latest 3538xyz^2 version,

Max M. · Mar 15, 2007, 03:05 PM

Maddogg6 · Mar 15, 2007, 03:49 PM

LOL - Thanks guys

Quote:

Originally Posted by Lex Nahumury

I haven't DL-ed latest 3538xyz^2 version

lol - I told you 100,000,000,000,000 times - no more exaggerations.

Quote:

I haven't DL-ed latest 3538xyz^2 version,
but there used to be a very old SRC source code in the sdk.

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..??

Russ · Mar 15, 2007, 04:09 PM

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()

Lex Nahumury · Mar 15, 2007, 04:14 PM

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

Maddogg6 · Mar 15, 2007, 05:00 PM

Thanks Russ

Quote:

Originally Posted by Lex Nahumury

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

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

Russ · Mar 15, 2007, 05:31 PM

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 *PluginName_copyright="plain text here";
char *PluginName_engine="plain text here";
char *PluginName_comment="mostly plain text here ($nobypass, etc. being exceptions)";
char *PluginName_created="plain text here (date)";
char *PluginName_guid="the plugin's GUID";
char *PluginName_name="the plugin's name in plain text";
int PluginName_itramsize=0,PluginName_xtramsize=0;
dsp_register_info PluginName_info[]={...};
dsp_code PluginName_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.

Maddogg6 · Mar 15, 2007, 08:20 PM

Quote:

If the Dane code is valid (i.e. works as a Dane only plugin) then exporting from Dane should produce the correct code.

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.

Russ · Mar 15, 2007, 09:17 PM

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,  KX_FX(0x0),  0x7fffffff;
macs      Right,  0x0,  KX_FX(0x1),  0x7fffffff;

; change to

macs      Left,  0x0,  0,  0x7fffffff;
macs      Right,  0x0,  0,  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,0x2040,0x204f }, /* first instruction  */
    { 0x0,0x8001,0x2040,0x2040,0x204f }, /* second instruction */
};

// change to

dsp_code src_code[]={
    /* { instruction, R, A, X, Y } */
    { 0x0,0x8000,0x2040,KX_FX(0x0),0x204f }, /* first instruction  */
    { 0x0,0x8001,0x2040,KX_FX(0x1),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,0x2400,0x204f }, /* first instruction  */
    { 0x0,0x8001,0x2040,0x2401,0x204f }, /* second instruction */
};

See dsp.h to see where the above values come from.

Maddogg6 · Mar 15, 2007, 09:43 PM

* 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.

Max M. · Mar 15, 2007, 09:58 PM

>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

Russ · Mar 15, 2007, 10:01 PM

Quote:

Originally Posted by Maddogg6

or need to re-compile DLL for every attempt in dane changes.

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)).

Lex Nahumury · Mar 15, 2007, 10:06 PM

Quote:

Originally Posted by Maddogg6

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......

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

Maddogg6 · Mar 15, 2007, 10:13 PM

Quote:

Originally Posted by Russ

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)).

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

Lex Nahumury · Mar 15, 2007, 10:23 PM

Quote:

Originally Posted by Maddogg6

but when dealing with HW registers this is not possible, so I guess it will force me to using very simple dane for that ....

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.

Maddogg6 · Mar 15, 2007, 11:09 PM

Quote:

Originally Posted by Lex Nahumury

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.

you know me I had a hair-brained idea

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!!!!!

Russ · Mar 16, 2007, 12:07 AM

Quote:

Originally Posted by Russ

For that you would have to use different registers (or better, use 0) in place of the hardware registers in order to export it...

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:

Quote:

Originally Posted by Maddogg6

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.

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>

Maddogg6 · Mar 16, 2007, 12:17 AM

Woot!!!

I was able to successfully rip off Lex's SRC code and rename it to be my own...
J/K - I left the copyright notice...

Anyway - I did it from saving my own da_plugin.cpp exported from Dane editor.

The code is still all greek to me - but I hope to add FXBuss 32-63 to the list - at least I can compile it.

Thanks again guys... maybe you should sell your tylonol stocks now.

Naaa - I wouldn't either

Mark

Maddogg6 · Mar 16, 2007, 12:51 AM

Woot!..

Mission Accomplished... I now have a SRC plugin that gives me all FXBuss lines now..

If any one is interested...Its on my MD6 Music Esnips page.
READ THE 'READ_ME_OR_DIE_.txt' file to avoid 'invalid plugin version' or what ever error pops up with out that dll I added.

*Hopes Lex wont be mad *

Maddogg6 · Mar 16, 2007, 01:01 AM

Quote:

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.

Ah ok - thats how you pros do it... cool.

Thanks for all your help - just 1 more question tho... Whats responsible for automatic translation? - my plugin asks everytime I add one to the DSP screen - and I don't like that behaviour... I obviously changed something I should not have here

Code:

  case KXPLUGIN_INSTANTIATE:
       if(param<sizeof(plugin_list)/sizeof(kxplugin_list_t))
       {

        // to avoid numbering stuff
         instantiate_plugin(DSPSource,iDSPSourcePlugin);
       }
       break;
 }
 *ret=0;
 return -1;
}