Hello! I’m back after a rather long holiday… where I actually saw met Juce(*), er, Jules in the flesh, as well as his charming gf.
While I was vacationing, I turned on all the (useful) compiler warnings from my codebase and removed them.
In practice, this turned out to be various arithmetic warnings - signed/unsigned comparisons and narrowing conversions. Quite instructive and found at least one latent bug and a lot of potential bugs have been noted for “very large sample files” (with > 2 gig file sizes).
However, there seems to be an inconsistency between the usage of int64 aka long long int and int for sample counts.
In some places, like AudioSourceChannelInfo, Juce uses ints; in other places, like PositionableAudioSource, Juce uses int64s; and as a result, I have downcasts in various places.
Now, I can see the reasoning in those two - you might be thinking that PositionableAudioSources might be very large and need 64 bits, which is certainly true, but that AudioSourceChannelInfo represents “small” areas of memory and we’d never have 2 gigs worth of samples in memory - but that isn’t necessarily true in a 64-bit world, there might be large offsets at the very least.
I just have a single type for all sample counts and offsets - it’s called Samples<44100> and you can see the comment here where I had to add another method when I turned on strict arithmetic warnings. (You can see its sibling RealTime here…)
Certainly not an “action item” but just a data point for future changes.
(* - I really did type Juce initially)