Something odd with latest tip.
Enabling ASIO I get the ASIO option in the audiodeviceselector, but no devices.
In JuceDemo, using Windows7-64bit, vs2010.
I’ve probably broken something with all my string changes… Thanks, I’m investigating now…
hmm, nope… ASIO’s working just fine for me here. Maybe the problem lies elsewhere - let me know if you can give me any more clues.
Same here, ASIO is working.
Ok,as a sanity check on my side i reverted to git from 12 days ago and everything is fine…
Certainly broken in last 3 commits. I will find the revision where it goes wrong.
I took the trouble of finding the breaking commit which is this one from 2 days ago:
“Many more String changes, so that finally the String class can store its internal data as either utf8, 16 or 32 - this is controlled by a flag JUCE_STRING_UTF_TYPE. It’s currently set to utf-8 by default.”
In the revision prior to that it works for me.
Jules, i found the problem:
In juce_win32_asio.cpp:
void addDriverInfo (const String& keyName, HKEY hk)
{
HKEY subKey;
if (RegOpenKeyEx (hk, keyName.toUTF16(), 0, KEY_READ, &subKey) == ERROR_SUCCESS)
{
// it never enter here... after revision 2 days agoWorth repeating.
If the argument to a Windows API function is going to be UTF16 no matter what (i.e. independent of the Unicode settings in the project), such as this call:
if (RegOpenKeyEx (hk, keyName.toUTF16(), 0, KEY_READ, &subKey) == ERROR_SUCCESS)Then it would make sense to always use the Wide version of every Windows API function call (formed by appending the letter W to the function name) as in:
if (RegOpenKeyExW (hk, keyName.toUTF16(), 0, KEY_READ, &subKey) == ERROR_SUCCESS)Fair point about adding the ‘W’ suffix, but juce always uses the unicode version of the win32 APIs - I set the _UNICODE flag in juce_win32_NativeIncludes.h before including windows.h, so it should never use the ascii functions.
I can’t really see how this could fail when you build the app, but work when I build it…? The only difference I can see if that you’re using vs2010, but even so, the compiler should be producing exactly the same code. Does it make any difference if you do what TheVinn suggested?
I should have known…you already thought of that! So project settings will still make no difference…adding “W” won’t do much then (except create extra work).
Yeah, making it possible to change that setting in the project would provide too much opportunity for people to break it…
Anything with toUTF16() fails for my driver…
This is the only solution i found:
if (RegOpenKeyExA (hk, keyName.toUTF8().getAddress(), 0, KEY_READ, &subKey) == ERROR_SUCCESS)
What’s up with toUFT16() here?
That’s really weird.
Does your driver’s name or path contain extended characters? (Seems unlikely, because if it did, then the UTF8 version probably wouldn’t work either, since I don’t think the win32 functions actually use utf-8, I think they expect a locale-specific encoding)
I’ve got unit tests for the toUTF16 methods so am pretty sure they’re robust, but you could also try setting JUCE_STRING_UTF_TYPE = 16, so that the strings are stored natively as utf-16 (I don’t really think this will make any difference but can’t think of anything else to suggest…)
I also encountered this problem. Enabling ASIO, run JuceDemo, but no devices in the audiodeviceselector.
This is my build results:
http://www.miti2000.com/temp/JuceDemo.zip
Windows XP 32b + VS 2008 + JUCE 1.53.40
My driver name has no special characters.
JUCE_STRING_UTF_TYPE 16 fixes this problem, so it must be about the string conversions.
Its not a solution for me though.
Any thoughts or can i help post more info?
That’s really utterly odd. If the string conversions were broken then nothing at all should run on win32, because they’re used in every place that a string has to be passed to the OS! And my unit tests all pass with no problems.
Could you let me know what the actual string is that’s failing? i.e. the value of keyName?
Well, I’ve figured it out at last - see this thread:
http://www.rawmaterialsoftware.com/viewtopic.php?f=3&t=6822&start=0
Yeah, i actually had considered odd memory addresses, but thought it was too far out to mention…