There is a bug in the Juce distribution, file :
juce\build\win32\platform_specific_code\juce_win32_DirectSound.cpp
In the function DSoundAudioIODevice::openDevice, there is this code (somewhat simplified here) :
for (i = 0; i < inputChannels.getHighestBit(); i += 2) {
...
if (inputChannels[i])
left = inputBuffers[numIns++] = ...;
if (inputChannels[i + 1])
right = inputBuffers[numIns++] = ...;
...
}
...
for (i = 0; i < outputChannels.getHighestBit(); i += 2) {
...
if (inputChannels[i])
left = outputBuffers[numOuts++] = ...;
if (inputChannels[i + 1])
right = outputBuffers[numOuts++] = ...;
...
}
You can see that in the output loop, this is also the input bit array that’s checked.
So for a filter, with similar input/output configuration that’s ok, but for a soft synth, this is not working.
Yes, it’s old code (though it’s the one from the latest distribution), I know that, but I have mixed blessings about using the svn tip.
How could you possibly guarantee that the svn tip is bug free at all time ?
You are currently moving the Mac version from Carbon to Cocoa. This is not the right time to pick the whole distribution.
And picking that single DirectSound file, how to be sure that nothing else will break ?
Yes, I could check that, but since I have pinpointed the problem, it’s fom my point of view safer and quicker to simply fix it.
And since it’s part of the current archive, I think that other users could find that information useful.
To end this post on a more positive note, I have a suggestion to improve the process.
My suggestion is that from time to time, for instance once a week, when you are pretty confident that the svn tip is consistent, you make a tag on svn.
This is faster than producing a new version, and that would gave us insurance that we don’t grab an halfway work.
All very sensible points. The tip is actually usually pretty good, as I tend to get a bunch of stuff working and check it all in at once. E.g. at the moment, I’m keeping all the cocoa stuff well away from SVN, and will check it all in when it’s looking stable.
If it’s possible, I’d suggest grabbing the whole Dsound file from the tip and using it, as I fixed a few other bugs in there. (It might not compile of course, if it has dependencies on other changes - I can’t remember offhand if this is the case)
How recent would this Dsound changes be which you talk about.
We are using Juce revision 552 at the moment, any changes since then for the better in the Dsound code?
