Dane and KX Register Access - Page 2

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;
}

Russ · Mar 16, 2007, 01:06 AM

Quote:

Originally Posted by Maddogg6

Whats responsible for automatic translation? - my plugin asks everytime I add one to the DSP screen - and I don't like that behaviour...

Congratulations

As for the translation stuff, it sounds like you turned on the "Advanced Options" in the DSP window.

Maddogg6 · Mar 16, 2007, 01:12 AM

Quote:

Originally Posted by Russ

Congratulations

As for the translation stuff, it sounds like you turned on the "Advanced Options" in the DSP window.

yes it was turned on - but, something must have turned it on - Well - maybe I did accidentally - but I have doubts - me thinks maybe re-installing or something turned it 'ON' when I wasn't looking.

I never noticed what that did before... *scratches head and shrugs*

Lex Nahumury · Mar 16, 2007, 07:58 AM

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

Well, my memory is very bad and I don't do kX stuff anymore but IIRC those >15 or >31 fxbuss numbers are just copies, so I fail to see the use of them.

>>*Hopes Lex wont be mad *
LoL no ..use whatever you want.

Anyway, nice to see you are making progress!

Maddogg6 · Mar 16, 2007, 10:33 AM

Quote:

Originally Posted by Lex Nahumury

Well, my memory is very bad and I don't do kX stuff anymore but IIRC those >15 or >31 fxbuss numbers are just copies, so I fail to see the use of them.

Hmmm - no, all my tests show they are working as expected - I just need to release the Wave devices (stop winamp) for KX Router changes to take.
I've played with FXBuss2 before and had happy results too - so I already was confident it was possible. Must have been something that E. fixed somewhere along the line.. I want to say I played with FXBuss2 in 3538H and they worked ?? but I guess maybe it was 3538J - now Im not sure.

But I do notice I created a problem - I allowed SBLives to select up to FXBuss 31 - but KX Router for my Live only allows up to FXBuss 15... I thought lives had 32 FXBUss lines.

Quote:

>>*Hopes Lex wont be mad *
LoL no ..use whatever you want.

Cool - thanks.

Quote:

Anyway, nice to see you are making progress!

hehe - thanks - yes, you can put that booze bottle away for now.

You too Russ.

Thanks again for all the patients and guidance.

Lex Nahumury · Mar 16, 2007, 11:54 AM

What 38xyz^2 version did you compiled it for??
I just installed MMMMMMMMMM!!
(boy, am i fed up with this idiotic version incompatibility crap

)

Maddogg6 · Mar 16, 2007, 12:01 PM

Quote:

Originally Posted by Lex Nahumury

What 38xyz^2 version did you compiled it for??
I just installed MMMMMMMMMM!!
(boy, am i fed up with this idiotic version incompatibility crap

)

lol - I compiled with 3538M SDK.

If you send me a zip of the SDK you have - maybe I can recompile for it.. ??
Id be more than happy to try anyway...
PM me and Ill give ya an email to send it to if you'd like.

Maddogg6 · Mar 16, 2007, 12:01 PM

oh hell - maybe sending the source to ya would be easier.. ?? its for MSVC2003 tho.. ??