crossfeed dsp plugin?

Lex Nahumury · Sep 18, 2003, 02:09 AM

>>btw, the headphone effect might be used with live, too -- but it uses =too= many resources...

Yep I know, I tested all versions of CL's hpsp. (they are really big).
Best to test them with Audigy.

>>and please check the two 'unused' inputs of the HpSp effect -- I wonder what they might be used for...

Yep, I will, ..I had made Frequency Reponse plots of all hpsp inputs a while ago.
(They matched close with HRTF database plots I made in MATLAB)

I will look them up again as soon as I installed ADGII (ADG1 was not available anymore..

..)

/LeMury

Daijoubu · May 8, 2004, 11:58 PM

Anyone tried to use the "3D Sound Gen" plugin?
Using 1/0/1/0/100%/25% for my earplugs

DocterDee · Oct 20, 2004, 02:31 PM

As a KX Newb i wanted to ask this Question. How can i use now LeMury's Crossfeed Plug In ?

Foolou · Oct 20, 2004, 04:40 PM

Should have read this thread earlier, as I got something to add to the hrtf-headphone simulation of 5.1 sound.

The direct use of HRTF-Data isn't that problematic.

With some changes the code of my 5.to-headphone-plugin could be reconfigured to use only static variables and not fixed 'pointers' to the itram, thereby opening the option to pass different HRTFs to the effect.
It wouldn't change much for the resources needed.

It would still be a resource-eater, and ofc the quality of the effect would be better with any bit of calculationtime given to it.
7.1 sound done the way the plugin is doing 5. now would take like 140 gprs and up to 270 instructions, still leaving free resources on a 10k1 even.

Ofc I'd be willing to do those modifications if you should decide to go the direct HRTF-way instead of the 'filtered as if it went through a hrtf-convolution'.

Lex Nahumury · Oct 20, 2004, 07:49 PM

>>...thereby opening the option to pass different HRTFs to the effect.
[color=yellow]Have you examined the option to dynamicly apply microcode changes[/color]
[color=yellow]through a .dll extension to switch HRTF sets?
[/color]
>>Ofc I'd be willing to do those modifications if you should decide to go the
>>direct HRTF-way instead of the 'filtered as if it went through a hrtf-
>>convolution'.

[color=yellow]Any contribution in any form to kX Project is always highly appreciated.[/color]
[color=yellow]So feel free to work out your own ideas/methods.[/color]
[color=yellow][/color]
[color=yellow]/LeMury[/color]

Foolou · Oct 21, 2004, 02:25 PM

[color=yellow]>Have you examined the option to dynamicly apply microcode changes[/color]
[color=yellow]>through a .dll extension to switch HRTF sets?[/color]

Not really.

I thought it could be possible to pass the HRTF-Filter data using the xtram, although that would require more gpr and a lot more instructions. ( 32 gpr and 100 instructions maybe)

One part of the plugin would constantly update the HRTF-Filters from different places of the xtram, changing the hrtf would take a few samples to get fully to work.
(would use the skip command to access different parts of the hrtf-updater, which would then change the xtram-access registers for the next samples calculation, by accessing all 32 registers of the xtram it would take 3 turns to change the hrtf, on the other hand it could be done in much smaller portions too)

Still dynamic hrtf's coded this way would increase the size of the plugin too much, specially considering the fact that ppl would only try around till they have their best hrtf and never change it again.

So I fear the microcodechanges would be the reasonable but for me more complicated way.

Lex Nahumury · Oct 21, 2004, 10:08 PM

Quote:

...specially considering the fact that ppl would only try around till they have their best hrtf and never change it again.

[color=yellow]Yes, that would be quite a waiste of DSP resources.
[/color]

Quote:

So I fear the microcodechanges would be the reasonable but for me more complicated way.

[color=yellow]Please have a look at the SDK ...\kxfxlib, and the demo.[/color]
[color=yellow]You'll find plenty of examples there.[/color]
[color=yellow]The da_xxx.cpp files contain the -> C++ exported Dane microcode part.[/color]
[color=yellow]You'll need MSVC 6.0 to succesfully compile a .kxl plugin.[/color]
[color=yellow]IIRC you did mention writing in C/C++ before, so it shouldn't be to hard really.[/color]

[color=yellow]/LeMury[/color]

Foolou · Oct 22, 2004, 02:35 PM

It's not the codewriting I got the trouble with.
Gonna have to get MSVC++6.0, I'm usually using the windows port of gcc (wxwindows for gui) and for the simple c-stuff lccwin32.
Most of the stuff I coded was for hobby purposes and the gui wasn't something I really cared for.
There was never a reason to get a commercial c++ compiler for me.
Looks like I'll have to change my mind on that.

Sep 18, 2003, 02:09 AM	#31
Lex Nahumury DH Senior Member Join Date: Jan 2003 Location: The Netherlands Posts: 1,930 Rep Power: 62	>>btw, the headphone effect might be used with live, too -- but it uses =too= many resources... Yep I know, I tested all versions of CL's hpsp. (they are really big). Best to test them with Audigy. >>and please check the two 'unused' inputs of the HpSp effect -- I wonder what they might be used for... Yep, I will, ..I had made Frequency Reponse plots of all hpsp inputs a while ago. (They matched close with HRTF database plots I made in MATLAB) I will look them up again as soon as I installed ADGII (ADG1 was not available anymore....) /LeMury

May 8, 2004, 11:58 PM	#32
Daijoubu DriverHeaven Newbie Join Date: May 2004 Location: Montreal QC Canada Posts: 2 Rep Power: 0	Anyone tried to use the "3D Sound Gen" plugin? Using 1/0/1/0/100%/25% for my earplugs

Oct 20, 2004, 02:31 PM	#33
DocterDee DriverHeaven Junior Member Join Date: Jun 2002 Location: Germany Posts: 99 Rep Power: 0	As a KX Newb i wanted to ask this Question. How can i use now LeMury's Crossfeed Plug In ?

Oct 20, 2004, 04:40 PM	#34
Foolou DriverHeaven Junior Member Join Date: Oct 2004 Posts: 25 Rep Power: 0	Should have read this thread earlier, as I got something to add to the hrtf-headphone simulation of 5.1 sound. The direct use of HRTF-Data isn't that problematic. With some changes the code of my 5.to-headphone-plugin could be reconfigured to use only static variables and not fixed 'pointers' to the itram, thereby opening the option to pass different HRTFs to the effect. It wouldn't change much for the resources needed. It would still be a resource-eater, and ofc the quality of the effect would be better with any bit of calculationtime given to it. 7.1 sound done the way the plugin is doing 5. now would take like 140 gprs and up to 270 instructions, still leaving free resources on a 10k1 even. Ofc I'd be willing to do those modifications if you should decide to go the direct HRTF-way instead of the 'filtered as if it went through a hrtf-convolution'.

Oct 20, 2004, 07:49 PM	#35
Lex Nahumury DH Senior Member Join Date: Jan 2003 Location: The Netherlands Posts: 1,930 Rep Power: 62	>>...thereby opening the option to pass different HRTFs to the effect. [color=yellow]Have you examined the option to dynamicly apply microcode changes[/color] [color=yellow]through a .dll extension to switch HRTF sets? [/color] >>Ofc I'd be willing to do those modifications if you should decide to go the >>direct HRTF-way instead of the 'filtered as if it went through a hrtf- >>convolution'. [color=yellow]Any contribution in any form to kX Project is always highly appreciated.[/color] [color=yellow]So feel free to work out your own ideas/methods.[/color] [color=yellow][/color] [color=yellow]/LeMury[/color]

Oct 21, 2004, 02:25 PM	#36
Foolou DriverHeaven Junior Member Join Date: Oct 2004 Posts: 25 Rep Power: 0	[color=yellow]>Have you examined the option to dynamicly apply microcode changes[/color] [color=yellow]>through a .dll extension to switch HRTF sets?[/color] Not really. I thought it could be possible to pass the HRTF-Filter data using the xtram, although that would require more gpr and a lot more instructions. ( 32 gpr and 100 instructions maybe) One part of the plugin would constantly update the HRTF-Filters from different places of the xtram, changing the hrtf would take a few samples to get fully to work. (would use the skip command to access different parts of the hrtf-updater, which would then change the xtram-access registers for the next samples calculation, by accessing all 32 registers of the xtram it would take 3 turns to change the hrtf, on the other hand it could be done in much smaller portions too) Still dynamic hrtf's coded this way would increase the size of the plugin too much, specially considering the fact that ppl would only try around till they have their best hrtf and never change it again. So I fear the microcodechanges would be the reasonable but for me more complicated way.

Oct 22, 2004, 02:35 PM	#38
Foolou DriverHeaven Junior Member Join Date: Oct 2004 Posts: 25 Rep Power: 0	It's not the codewriting I got the trouble with. Gonna have to get MSVC++6.0, I'm usually using the windows port of gcc (wxwindows for gui) and for the simple c-stuff lccwin32. Most of the stuff I coded was for hobby purposes and the gui wasn't something I really cared for. There was never a reason to get a commercial c++ compiler for me. Looks like I'll have to change my mind on that.