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