Any plans to include 64-bit float capability?
I’m getting some good sounds out of 32-bit, but distortion and reverb tend to accentuate the rounding errors, and more subtle effects sound grainy on close inspection.
Dave Heinemann
Oh no, not one of those “I can hear the difference between 64 and 32 bit” people… 
Which bit of the audio code are you talking about? The i/o or the signal-processing bits?
The difference is mostly noticed in reverb tails and with distortion. No I can’t hear the difference between 0.75 and 0.7500000000001! Not without some feedback.
IO and AudioSampleBuffer are what I was after. AudioSampleBuffer is easy enough to hack on my own, but upstream from that I’m not sure how involved it is.
I might give it a spin, but also I didn’t want to waste the effort mucking around with it if you had it on the to do list anyway.
I just make everything with typedefs and templates so it’s easily portable from that end, and I get about 0% speed difference between float and double (using double internally).
Then there’s always the chance that finer detail will expose more flaws!
So you’ve got a 64-bit sound card? Are there any such things? I can sort of see the argument for doing your internal processing with 64 bits (if you’re using effect chains or algorithms that feed back a lot), but as soon as it hits an output you’re straight down to 24 bits, so there’s really no point worrying about the i/o not being 64 bit.
Sorry I meant the host, not hardware. 64 bit host, doing process double.
Oh, for a plugin? I see. Not many hosts and formats can support that yet, though. Does the latest VSTSDK do 64 bit?
VST2.4 has processDoubleReplacing.
I’m using Sonar 6, which does have a completely 64 bit signal path. No it’s not twice as good, but a little less rough around the edges.
Like I said, reverb tails, heavy compression or anything that magnifies the quieter parts of the signal or adds a bunch of quiet samples together. Great for mastering quality and for using a bunch of effects together.
If other hosts aren’t doing 64, it’s not worthwhile to make any huge changes.
I’ll give it a try. If it’s just a couple lines (canProcessDouble = true and declaring a process double function) that might be worth putting in, but it could always be more compl- uh, FUN…
Dave Heinemann
The sound? Slightly better - if you told me it was 36 bits I’d believe it. Subtle with a capital B.
Implementing it? Not as hard as I first thought - just a canProcessDouble, processDoubleReplacing, AudioSampleBuffer64 and a few defines, and making sure my existing code could handle it.
The shocker? It’s FASTER.
I would have expected the same speed or a hair slower, but it’s significantly faster. Identical code except for #define AudioFloat and #define JuceAudioBuffer.
With multiple instances in debug mode I’m getting high 20’s CPU usage with 32-bit, low 20’s and high teens with 64-bit. That’s debug mode, presumably with equal overhead for both, suggesting a possibly huge difference in release mode.
VCExpress, Pentium 4 3.0 lonely core.
I’m doing analog modeling, and the sound difference is mainly in the quirks; the hiss when there’s too much distortion, the sizzle in the reverb tail on cymbals.
Of course I’ll do further testing - release mode, as well as making sure the host doesn’t have stupid amounts of overhead for converting to and from 32-bit - that should be about instantaneous, but you know hosts…
I also want to check if it’s worth converting incoming 32-bit signals to 64, processing , then converting back to 32, even with a less elaborate processing chain (my major project has 6 different effects, part of the reason I’m so glad for an improvement in speed and detail).
And I though “double” just meant precision…
Dave Heinemann