Discussion in 'Effects and the DSP' started by Lex Nahumury, Mar 11, 2005.
No, it links to older msvcrt dll version.
I downloaded the msvcr80.dll. Does it just have to be there, in sys32 or so? What does it do?
If you add the kX 3550 directory to your System PATH, then Dependency Walker will be able to find the kX dll's (you should add kX to the PATH anyway, as it is needed for some other things).
Regarding msvcr80.dll, that is not a file installed by kX, or ProFX (if that is what you were thinking), it is a MS file that is usually installed from some Windows update, etc. Mine is in c:\windows\winsxs\... but you can probably just put it in the System32 directory.
Yep. Ok then it's solved; msvcrt80.dll is missing on your system.
I wouldn't mess with randomly copying windows system DLLs.
Either use the 3.11 kxl I compiled for you, or install some windows update like the .NET framework.
Either way it doesn't influence kX driver functionality or my plugins in anyway.
Like I said before, most people have msvcrt80.dll automaticly installed through windows update.
It is needed for some soundfont stuff (related to sfman32.dll).
thanx, thats a relevant piece of information. Is there any further documentation about that?
I havn´t gotten around to really testing the midi and synth functionality but on another machine I used to use soundfonts a lot with the creative drivers. There are a couple of nice tools around the sf2 format, some of them with driver support and realtime editing.
But I guess thats offtopic in this thread.
It is only with newer versions of kX (3548 and up). kX used to place these files in the System32 directory, but it does not do this in newer versions of the driver, so programs (like Vienna) that might be looking for these files cannot find them. Eugene mentioned it in the release notes for 3550 (and I mentioned it in the 3548 (x86) Bug Reports thread).
so shouldn´t the installer write that path information, too? Quite a few users might stumble over this one.
On my main machine I still use 3545
Maybe... or maybe registering the dll's... I do not know... But yeah, this is getting OT for this thread.
For those who missed it because of all the chit/chat;
ProFx 3.11_48/49/50 Update:
Note: This is for 32-bit x86 only
and works with 3548/49/50 kX driver versions.
Download Link in first post of this thread.
Read this post.
AW: NEW: ProFx (3538) Update Incl. MX6 and AC97
Zitat von geraldandreas
ProFX source in 3550 is not working, any idea why?
Zitat von Lex Nahumury
The 'Included' ProFx versions or these?;
NEW: ProFx (3538) Update Incl. MX6 and AC97
Please post in ProFx related thread.
it was the included version, but with the version for 3550 from your site, everything is working again.
a very big thank you for your excellent ProFX tools
Read more: http://www.driverheaven.net/bug-rep...rts-2.html?posted=1#post1302209#ixzz0Td9shgKr
Re: AW: NEW: ProFx (3538) Update Incl. MX6 and AC97
Good, ..your welcome!
I've never understood the re-mapping of ASIO on SB Live 5.1 cards. The "input pins" on the ASIO dsp page are asio0,1,2,5...15 and map to kx_fx2(14,15,0,3...13) respectively, which I can use in ASIO applications as "kx in" 14,15,0,3...13
While I understand the absence of 3 & 4 (kx_fx2 1 & 2), I don't understand the 2 place offset. It always catches me when I connect to, say, "pins" 6 & 7 in the DSP, I have to remember that it corresponds to kx IN 4/kx IN 5 in my app.
NOTE: my sound card is a SB0102 - which is interesting, as that is the same card used in http://members.home.nl/nahutec/kxtutor/cubase/kxcubasesx.htm in the section that describes the "ASIO mapping issue" - that example shows the 4th and 5th channel (kx in 3/kx in 4) as having no sound (due to the centre/lfe routing), in my case, it is the 2nd and 3rd (kx in 1/kx in 2)
The problem with the asio mapping issue is that it is not constant, so having the same card model doesn't mean the mapping is the same.
Moreover, the mapping can even change after several ASIO channel start/stop and/or reboots.
Although that doesn't happen often it has been reported.
Wow, I've never experienced that!!
I may just put in a simple "intermediate" to unmap the mapping so input 0...15 on the "remapper" ends up kx IN 0...15
I'm old and easily confused, you see
Well, usually setting up the ASIO app once is enough until the random mapping kicks in which, as I mentioned, doesn't happen often.
my setup is in a state of flux as it is
if the "random mapping" kicks in randomly ... why have remapping at all?
My system NEVER has never been different to how it is now - maybe the "random remapping" was an issue with older kx drivers - certainly seems stable and constant to me for the last two years
Separate names with a comma.