I’m writing a Midi Fx AU plugin. I’m running it in Logic Pro X 10.4.4.
It runs fine when Logic sample rate is 44100. When I change Logic project sample rate to 88200 or 96000 PrepareToPlay() is called but the provided sample rate is always 44100. It is also 44100 in ProcessBlock() even though host runs at 88200.
Since I’m generating midi based on sample rate and bpm (samplesPerTick) my plugin winds up playing at double rate.
i’m currently using Juce 5.3.2 but I also tried 5.4.3.
Any ideas how to get the correct sample rate from Logic?
I’m sure someone will correct me if I’m wrong, but I believe Logic resamples that way it never changes the same rate of your device and it’s limited by the sample rates of the device. Therefore you would expect to keep getting called with the sample rate of the device not the project.
Thank you for your reply Anthony!
If I understand you correctly the external device SR stays 44100 but Logic internally works at 88200. This makes sense. However the buffers sent to ProcessBlock() are in the project SR i.e 88200. So if ProcessBlock() runs some SR based calculations they will be incorrect (as it happens in my case). Any idea how to work around this problem?
I have the same problem. Logic feeds plugins with the true project sample rate. A simple JUCE audio plugin does follow the host’s changing SR,
If it’s a MIDI FX- plugin, the changed SR is either not sent by Logic (like, why bother, it’s just a MIDI FX), or not received/acknowledged by the plugin (like, why bother, I’m just a MIDI-FX), so it’s the MIDI-FX flag which prevents this from working.
PrepareToPlay does get called when changing the host’s SR, but the plugin’s SR always reports at 44100.
Until I have a better solution, I’ll create a 44.1- and a 48kHz-version of the plugin.
Fair enough. I would still shy away from going down the road of hardcoding separate sample rates into multiple plugins, seems like a ball-ache and then what about 88.2, 96, 192, 384…
Rather annoying that MIDI plugins can’t know the sample rate of the host.
Instead of creating several versions for different sample rates, I made the base number for the calculations remote-controllable via a MIDI Control Change message, like:
if (CC65 Val == 0) {x = 44100};
if (CC65 Val == 1) {x = 48000};
etc;
I am counting the time in samples between a live drummer’s (MIDI) snare hits and calculate and display the tempo from that. That’s the upper number.
The lower number is the target tempo, this can be set manually or via a MIDI CC message and thus can be saved per song or section. The target tempo serves several purposes:
it’s a direct visual guide in comparison to the actual tempo
it sets up a corridor in which precise snare hits are rewarded with the number in green
it sets up several other corridors in which half time, double time, dotted eights etc are detected correctly and all displayed as the source tempo, in blue
By counting samples (instead of milliseconds wall clock), I get to an accuracy of 0.001 bpm, rounded to 0.1 for the display.
Cool project! So wouldn’t you want to have an audio stream as well to measure the actual hit?
Oh, I just see, that AudioPlayHead delivers timeInSamples, that value makes no sense indeed without the correct sample rate…
And the midi events also have timestamps in samples…
No, since a snare drum more often that not is triggering something anyway and thus the MIDI note is available already, no point in doing the same twice and deal with crosstalk supression and stuff.
Sounds like the whole thing is pretty much broken when the host sample rate is not 44.1kHz, I can think of a number of examples where you would need to know the host sample rate in a MIDI plugin that would fall apart in that case
I’ve used the lower label, which takes numerical input for the target tempo, to accept the strings “44k”, “44.1k”, “48k” to choose the sampling rate and to accept “a”, “A”, “auto” and “Auto” to re-engage sync to the host tempo which automatically got dis-engaged by setting the target tempo manually. Best of many worlds within the current limitation.
