I made a TimeBalance plugin

ROBSCIX

Hey Tril, What about compiling the Plugin for 3537?. I am missing my UFX, so I think I am gonna go back for now. What do you think man can you do it for the 3537 guys?

Tril

I don't mind doing it but I can't test it since 3537 is not installed.

I need advice on how to proceed to convert 3538 code to 3537 code. I don't know how to do it easily.

Lex Nahumury

Quote:

I need advice on how to proceed to convert 3538 code to 3537 code. I don't know how to do it easily.

Don't know if it's 'easy', but here are a few differences out of my head (which were already mentioned here IIRC);

In YourPlug.cpp;
3538: set_dsp_register
3537: set_efx_register

In da_YourPlug.cpp;
//3538:
dsp_register_info YourPlugin_info[]={
{ "some_constant",0x8010,0x5,0xffff,0x5 },
};

//3537:
efx_register_info YourPlugin_info[]={
{ "some_constant",0x8010,0x1,0xffff,0x5 }, // NOTE: 0x5 becomes 0x1
};

Also in da_YourPlug.cpp, always define the dsp registers you dynamicly change;
#define MYCONSTANT_P 0x8010,
and use/refer to it like;
set_dsp_register(MYCONSTANT_P, dsp_dataword );

The latter will make cross compiling somewhat easier.

Hope this helps.

/LeMury

Russ

Also, do not forget to use the 3537 versions of stdafx.h, fxlib.h, and plgmath.h as they are different.

Basic Steps:
Copy the project folder for your plugin to the 3537 SDK folder (so that it links with the 3537 libs, etc).
Copy stdafx.h, fxlib.h, and plgmath.h from the fx_demo (3537 version) folder, to your plugin project folder overwriting what is there.
Make the changes posted above by LeMury.
Compile.
Anything you miss (other than the constants thing) should get caught by the compiler, so you should have no problems.

Lex Nahumury

At this point I would like to add that it also might be wise to implement a driver version check
that 'bails out' with a proper message if user tries to load the wrong plugin version.
Very handy to avoid those"..your plugin doesn't load bla, bla.." user posts:-]

Something like;

This should bail out quite 'clean'.

/LeMury

Tril

Thank you Lemury and Russ. I'll save all this info for future use. It will come in handy.

I'll do the 3537 version this week.

I'll also try to implement a driver version check that 'bails out' with a proper message if user tries to load the wrong plugin version. Since Lemury provided the code, I'll be able to do it. I know that I would not be able to do it myself (at least not without some hard head scratching while trying to figure out how to do it and what's the corret syntax), so thank you Lemury.

Tril

Lemury, I can't get the version check to work. I tried to implement it as you shown in the 3537 version of the plugin. I can then test it since I'm using 3538. It does not work.

I did not have a "int iYourPlugPlugin::init()" function in my plugin so I added it in YourPlug.cpp and YourPlug.h.

It seems like the code in "int iYourPlugPlugin::init()" is not executed. I put a debug message at the beginning of the function. If the function is executed, I should see a message in DebugView but I don't.

Is it possible that "int iYourPlugPlugin::init()" is not executed before the step in the registration of the plugin where it stops if it's not the right version?

It seems like init is not executed during registration of the plugin. It's executed when you load the plugin to the DSP.


Lemury, I suppose that you have tested this code with success in the past. So, the mistake is probably on my end. Am I doing something wrong?


I'll post the 3537 version of the plugin once this version check implementation is working.

Russ

That is correct. The code will not help with avoiding plugin registration problems, but rather would help avoid plugin loading problems do to an incorrect driver version (i.e. some plugins will register ok with the wrong driver version, and then crap out when trying to load). This will just let the user know what version of the driver is needed for the plugin (in the case of an incorrect driver version) and unload, thus helping to avoid loading errors (unable to instantiate plugin type errors).

Max M.

>It seems like init is not executed during registration of the plugin

well, what's a problem? you may move that version check stuff into "publish_plugins" function.
(although, personally, i would not recommend to put such stuff into plugin... such version checking must be performed by kxmixer itself and finally, this is what KXPLUGIN_VERSION definition is for (but coutrary to the present (37/37.9) implementation, kxmixer should also check if plugin_version > kxapi_version not only plugin_version < kxapi_version case. Otherwise each plugin turns into a whole OS and problems start to pile up)) E.g. "if kxmixer registers invalid plugin, it is kxmixer's problem not plugin author's headache" (and therefore it should be fixed in kxmixer... although it's too late to fix it for v.37)

Tril

Ok. I'll do a verification in init like Lemury Suggested.

I could place some code in publish_plugins to make a window popup to say the version number. It would only be a warning to the user without any checks. But it may get annoying (the popup and the beep) since publish_plugins is called at plugin load time too. It could be a good idea if it was only called at registering time. I won't do it. Hearing windows beeping every time a plugin loaded is too annoying.

The 3537 version is posted. Link in first post.

Max M.

>But it may get annoying (the popup and the beep) since publish_plugins is called at plugin load time too

More annoying then its crash later? If vcheck is required then i suggest it to be in "publish_plugins" and if plugin versions are incompatible it should always return 0 ("*ret=0"), so that it won't get registered and then never be loaded. I doubt if it makes sense to do popup or beep (and it does not matter where) if plugin will not work correctly anyway. If plugin will work then it should not beep or popup or whatever. Nothing in between.

>It could be a good idea if it was only called at registering time.

"publish_plugins" is a multipurpose function (if you want you can insert beeps only into nodes which are executed at register time (for example do not do checking at KXPLUGIN_INSTANTIATE case))..

Max M.

and again, (in case it was not clear in my prev. post)... All that can be cosidered only as temporary solution for "v38 plugin on v37 kxmixer" situation. for future: kxmixer has its own version checking based on KXPLUGIN_VERSION and the only stuff to be done is to make that checking implementation more stronger and correct. Version checking based on KX_VERSION_DWORD has its own issues and should not be used (example: imagine kx v.39 is out and it's plugin api is backward compatible with v38. so that plugins compiled for v38 will work perfectly - but if they will contain code suggested by LeMury ("kx_vers != KX_VERSION_DWORD") they trigger "bail out".) E.g. the right way to avoid "..your plugin doesn't load bla, bla.." is to fix kxmixer itself not to add an extra code to plugin. (please do not protect yourself of newbies at cost of harder life for normal users )

ROBSCIX

ok is it compiled for 37 yet?..just following the thread doesn't say if the issues been solved or not..

Tril

It is compiled for 3537. Look at my previous post.

I used the version check as Lemury suggested. The only problem with that is that the plugin version 3538 could fail to work in a new version of the drivers (e.g. 3539) that does not exist at the moment.

Tril

I upgraded from win2k to winXP. I just reinstalled the drivers. I had to save the dll I provided to system32 to get the plugin to register. The save button does not seem to work. Apart from that, it works. I feel a bit stupid, not even being able to use the save button of my own plugin. I need to find out why it does not work.

I have not reinstalled VS6 yet. Maybe something that comes with it is required to make the save button work apart from the dll I already provided.

Maybe the code I used works for win2k but not for winXP but I would find this strange. Code working on win2k usually works on winXP.

Or something else like the recovery thingy that rollback drivers files if it thinks it's a virus. I never had to worry with this before so I don't know when to turn it off and how.

If I'm struggling to get it to work on a fresh windows install, I would not be surprised if it did not work for other people in the same situation.

I'll post again if I get it to work. That may help others if they encounter the same issue.

Tril

Russ

Check your code, there is something goofy going on with it.
For example:
If the plugin is on my desktop, the save button works fine, however it the plugin is in another folder off the desktop (i.e. Desktop\My_kX_Plugins or whatever) it does not work.

It may have something to do with the length of the path where you are saving the file. Make sure that the variable used to hold the path info is the size of _MAX_PATH + 1.

Tril

Good idea. I'll report back after changing the size of the variable.

I remember that I did not know how big to make the variable but I made it big enough to work in the directory I was using when testing.

Tril

Russ was right. The path variable length was not big enough. It was set to 64, my mistake . It's now set to _MAX_PATH + 1.

Files updated. Links in first post.

Tril

I compiled the plugin for 3538i. Link in first post. Same as before.

aspectus

Tril, thank-you for producing this little gem of a plug-in, I've been running it all day and it is a keeper imho. The most startling effect to me is how much the improved spatial accuracy affects my listenning experience. I remember that drag-able from an ancient version of liveware on an old SB4.0 and have missed it since. Your plug-in seems to produce superior results.. Thanks again!

I read some talk about having the speaker volumes adjusted automatically, and thought that would be useful. I can imagine seeing one single more slider, labelled 'SPL' and would be for the user to feed in the rated efficiency of their speaker system, for the volume scaling equation.

Cheers!

Tril

I could add a checkbox to turn on/off automatic volume control. I'm lacking knowledge on how the volume should be adjusted.

There is a loss of volume caused by the difference in the length the sound travels in the air between the speakers and the listener (If the speakers are not all at an equal distance to the listener). I need to know how much a sound signal is attenuated by a distance in air at about 20C (dB/meter or something). I know the distance so I can calculate the dB loss caused by the propagation of sound throught the air. I then need to figure out what scaling fraction to use with that dB loss.

I see a problem with that approach. The sound produced by the speakers has a volume control. To reduce the volume by a specific amount of dB (what you hear, not the signal that comes out of the sound card) at two different speaker amplifications you would use two different volume scaling fractions.

Not sure if this is correct.

Please explain how/why the SPL sliders should be used.

Maybe my thinking is incorrect. What I know is that I don't know how to do the automatic volume control with my current knowledge.

I can do the programming as long as I know what I need to calculate, what are the equations,etc.

Feel free to share any knowledge that can be useful. Links to webpages providing useful information are welcome.

aspectus

My SPL slider comment was more of a musing than anything else. Now that I read your post I can't help but doubt that my idea of a loudspeakers efficiency factor (or more specifically, a loudspeakers efficiency across its range of loudness) is useful here at all. I had this mental image of a slider with calibration marks for various SPL levels (if such data is even available, I doubt '1watt @ 1meter' rating alone would be enough) that the user would set one time based on the SPL ratings (1W @ 1M, 1W @ 5M, 5W @ 1M etc etc, is this info even databased?) of loudspeakers. Maybe just some left-brain debris.. Now reading your post I wonder if air humidity is actually more relevant, or even altitude.

Where did I put my thinking cap. Ok so we are trying to figure out how much to attenuate each of the 5 ouputs 'evenly' based on listenners distance from the speakers. Clearly you are correct in that a major factor is said distance(s), however I don't think this factor is a constant, although it may well be in practice, so long as the speakers aren't very very far away from listenner:

It is probably not easy to know which variables to prioritize without testing. So far I see these;

- listenner/loudspeaker(s) distance(s)
- air pressure
- air humidity

My SPL slider idea I realize now was a feeble way for me to try and describe the idea that any particular amp/speaker setup is going to express its input signal differently than another, across the possible range of master volumes. While I don't see how this is a factor at a fixed master volume with listenner equidistant from each respective speaker, I am thinking that it does become relevant when, for example, the center speaker is well behind the fronts, and then the master volume is changed. How many db's of difference between my center speakers quietest and loudest output levels, as compared to yours? I suspect this is a factor, particularily if the speakers aren't each, on their own, equidistant from listenner. So, possible additional factor is;

- SPL gradient of amp/speaker

It may well be that the only practically relevant factor is in fact simply 'listenner/loudspeaker(s) distance(s)' as you stated. Maybe the best approach is to forget about all the other factors and do some white noise tests on your setup, calibrating the new slider by ear, then have a bunch other folks do the same on their setups. That may give enough info to know whether or not to pursue the issue.

Maybe another solution is to rig the setup portion of your plug-in set with 5 gain sliders and a white noise button, and let the user manually fix their own settings, maybe a 'quietest' and 'loudest' set of tests, then the 'lite' version of the plug-in could use those upper/lower limits to scale the signals?

Wow, you know, somewhere in there I actually felt like I knew what I was talking about!

ROBSCIX

I use this plugin but I have volumes as well, to trim the system to avoid clipping. Those other caculations would those help with sound quality? would they help with getting the best setup possible with a users given speakers? I have used this plug since it hit the forum, it's part of my stock setup now. I don't know why it's not getting more of a fan fare. I would like to see it evolve sort of like the THX setup page of a CL driver. I think this is what you have in mind tril is it not? To be able to set these seemingly small delays and parameters that aid in getting the best possible sound quality and surround imaging possible is Awsome!!. I think you boosted Kx up another notch in terms of professionalism Tril. I can't wait to see how the plug in will evolve. I know the sound is the main thing but it would be so Awsome to have a Nice GUI for this plugin especially. Having that level of accuracy in setup is something KX did not have before, and now thanks to you it does. Great Job, I just wish maybe the guys with the skinning knowledge..Max,Tiger.etc..would aid you in development. Is it only me who see's the usefulness of this plugin? is it only me who thinks it should be added to the KX installer?- I know it's beta right now. Just my opinions though.

Tril

My plugin introduce no volume change. Why do you have to lower the volume to avoid clipping?


I can manage to do a skin myself. To insert it in the plugin I just have to look in the SDK to see what I need to do.


I have never used that THX setup page of the CL driver. I don't know what it does and how good it is.


From what I know, I can't add an automatic volume control but it could be manual. I could add a volume slider for every channel. aspectus idea of using white noise might be a good idea.


I'll add an option to choose between imperial system and SI system to my plugin. The calculations are all done in SI and the sliders range are in SI too so the imperial setting will only convert the graphical display that is in SI to decimal imperial. It will be in inches.


ROBSCIX, you never shared with us how and why you use this plugin. Usually, if your speakers are positionned correctly or if you don't have a special setup, you don't need the plugin. Please share your experience with this plugin with us.


I initially made this plugin for uipe but I never had feedback from him/her. I wonder if it works well in a car where you don't sit at an equal distance to all the speakers. If someone uses a sound system with a computer and a sound card with emu10kX and the kX drivers, please try the plugin and share your experience with us.

ROBSCIX

I don't use the voume plugs because of your plugin..I have them in my setup always...
I sent you the picture of the THX page..well a link to it, has a guy in the middle....lots of number and settings, for delays for distance from speaker to listener and such. I use your plugin to trim distances of my speakers... Am I wrong for the way I am using this? I am using it to set the exact distances from the speakers to me. I know you designed it for a car application for drastic changes but I thought you can use it for small changes(trimming) to improve spatial imaging. Works for me. Thats why I sent you the link to the pic of that THX set-up page. I thought thats what you were going for with this plugin. SO people could tune and trim their exact speaker locations and listener location within the surround soundfield.

Tril

You are not wrong. I use it like that too. Mainly to adjust the delay between the front and rear speakers.


Ok, I understand. My plugin might be doing something similar to what that THX set-up page does but I only saw that picture after writing my plugin. My goal was never to copy someone else work.

Which soundcard or driver does that THX set-up page come from?


I will add a slider for the temperature. This temperature would be used to calculate the speed of sound. There is an equation to get the speed of sound here : http://en.wikipedia.org/wiki/Speed_of_sound

It is : cair = sqrt(kappa * R * T)


I could also add a display of the angles (in degrees) between the speakers with the listener as the center point if it's needed. Anyone that finds it useful, tell me and I'll implement it. I don't need it myself so I won't implement it if nobody asks me.

ROBSCIX

No,No I am not saying your copying someone elses work. Um that idea of exact speaker set up is on a few cards. That one though I think is from the new X-fi. Well I guess the more slider to input data for equations the better IF it helps with sound quality.....do you still have the link to that THX panel. When I seen it I thought, that your plugin could be similar to this with the GUI and such. The concept has been used before. I think it's great we have it now for KX.

Tril

Here is the page I was refering to : http://www.tomshardware.com/consumer...5/x-fi-04.html

ROBSCIX

Yep, Thats it. See that idea is what I basically use your plug for. For tuning speaker positions as exact as I can. Now I do put a Volume slider on each channel but it is unrelated to your plugin. I us the volume as a final system trim, to prevent clipping. I thought before your plugin that such a setup plugin or page within the KX driver would be great. Then you came up with your plugin. I thought great..this is what I wanted..well in the beta stage anyway. When I seen the THX page I thought I would send you the link as maybe it would spark some ideas for GUI, or calculations to include within your plugin. Don't styop your development. I think having this adds more professionalism to KX. Any thought on a GUI design? I will help anyway I can, I imagine a few other will as well. TO see this plugin developed to what we all think it could/can be..just my opinions..

Tril

New version of the plugin. Both 3537 and 3538i are updated. Use the links in the first post. Tell me if you find any bugs. I'll correct them fast.

What's new :

- Temperature slider to control speed of sound
- Choice between Metric and Imperial

What changed :

- The text on the save button changed from "Save" to "Save to TimeBalanceV2 light""
- The labels for the distance between C-FL and C-FR were moved to place them more centered between the speakers.

What's to come :

- A skin
Probably more.