I can’t test this myself since I dont have any audio hardware capable of anything but 44100. But I got a report about my arpeggiator playing to fast when using 48000 (in tracktion btw), and I can’t think of any other reason.
So, is getSampleRate() reliable in processBlock() or is there a safer method for learning the samplerate?
It should be fine - you can see in the VST wrapper code that it gets updated in the resume() method, so as long as the host’s got it right, then it’ll be correct. Could be tracktion’s mistake, I guess…
Well I updated it to snag the samplerate into a local variable from the pre-play method. I assume it’s comming from exactly the same source though?
It’s already kept locally in the audio class - take a look at the code. Most likely you’re just getting your sums wrong, because if tracktion sent out the wrong sample rates, very few plugins would work properly.
there was a bug in jucevstwrapper.cpp a little while ago causing 44100 to always be returned… make sure your version is fixed…
ah yes! I forgot about that - sounds like the culprit!
Sure does. So, the fresh build should work then. I’ve posted it so we’ll see if he gets back to me.
Edit > yeah, I verified that the previous release of peggy was built with that bug. Case closed…except maybe some bitching about Jules questioning my sums. Stay tuned.
