Yes, no one uses it, as it does not exist. However, I can think of quite a number of users who attempt to put it in like this…
I have this same problem. Working on a MIDI Plugin. But it’s not just Logic. JUCE’s own AudioPluginHost does the same thing with an AU plugin. JUCE 5.4.4.
Just hit this problem too. Surprised that this hasn’t been fixed yet.
Any comments on whether this can be fixed or we need to add sample rate options to our plugins? thx
can’t you find it using two consecutive block and check https://docs.juce.com/master/structAudioPlayHead_1_1CurrentPositionInfo.html
and compute the SR according to the new timeInSeconds from the previous one ?
I think you need to specify an audio input for the MIDI plugin; then you will get the correct sample rate.
I once wrote some code to calculate Sample Rate, but I no longer believe that’s a useful approach. Anyway, for more information on that and where in JUCE’s code this problem lies, see:
but if this is in the code and not passed through to MIDI plugins, why can’t the core code be changed to pass it through? why add audio channels that aren’t needed?
Rhetorical answer: because platform developers hate MIDI plugins and rarely even test them.
I added a channel configuration of {1,1} for the plugin to create an audio input and now processBlock() doesn’t get called.
@jules, @t0m, @ed95
some advice here on what to do would be much appreciated, thx.
Some advice please - I have a client waiting on me to solve this issue and I need to know what’s the best way to go about it. thanks
If your client needs a solution that urgent, you could patch the JUCE au wrapper yourself. I think all it would take is adding a AudioUnitGetProperty() call with kAudioUnitProperty_SampleRate and the right scope inside the AU Wrapper. If that still returns 44.1kHz then the problem is not JUCE, but the host.
1 Like
thx for the suggestion.
added a call to this and it returns 0 (well, it doesn’t update the out parameter)
edit: returns invalid element error code.
Where did you put the call? What scope did you use? I see that the AUWrapper skips this call in prepareToPlat if isMidiEffectPlugin is set and I guess that is where it should be added. I don’t know what would be the right scope, I’d just try most of them.
Where are you seeing that?
I’ve tried all scopes, but it needs what I assume to be the audio bus number and none are set up for a MIDI plugin so I guess that’s why it’s returning invalid element. Maybe this info just isn’t available for a midi fx plugin.
So, just seen this:
double getSampleRate() { return AudioUnitHelpers::getBusCount (juceFilter.get(), false) > 0 ? GetOutput (0)->GetStreamFormat().mSampleRate : 44100.0; }
which fixes the sample rate at 44100 if there are no buses defined.
I needs to be available as otherwise the sample offset is meaningless.
I gave creating my own midi fx plugin a go and see now that the spot I found isn’t even called… I think that’s for hosting 3rd party AUs. What I see is that during the plugin prepareToPlay, JUCE fetches the samplerate using GetSampleRate() inside the wrapper. This code is in there:
double getSampleRate() {
return AudioUnitHelpers::getBusCount (juceFilter.get(), false) > 0 ?
GetOutput (0)->GetStreamFormat().mSampleRate : 44100.0;
}
That’s where the constant 44.1k comes from I guess ! There probably is no streamformat for midi plugin.
LOL at the same time!
1 Like
just checked and this is fine on VST, so appears to only be an AU issue.
I tried getting the sampleRate during the AU Render() call using
inTimeStamp.mRateScalar
Unfortunately it is 0.0 when hosting inside the JUCE AudioPluginHost.
Ideally there would be some Apple sample code showing how to get the SampleRate inside a midi-only AU.
From Apple:
If you’re using an audio unit of type kAudioUnitType_MIDIProcessor, it has at least one output bus. For these AUs, the output bus carries only silence, but you can use it to get the sample rate.
Pretty sure I tried this and it didn’t work.
Thanks for your patience with this issue, I’ve now pushed some changes which should partially resolve the issue:
It looks like adding a single output bus to a MIDI FX AudioUnit allows the samplerate to be detected correctly in Logic. Making the same change in the AUv3 wrapper allows MIDI FX AUv3 plugins to correctly determine the samplerate in AUM. Adding an output bus to an AudioProcessor allows the samplerate to be detected without any further changes to JUCE code. However, this setup isn’t particularly ergonomic (we can’t easily warn users that they need to add an output bus, and conceptually the bus shouldn’t be required in the first place). In an attempt to make MIDI plugins “just work”, I’ve adjusted the AU and AUv3 wrappers so that MIDI FX will always have at least one output bus, even if no buses are requested by the AudioProcessor.
The changes on the develop branch should resolve sample rate detection issues in AU plugins, and with AUv3 plugins on iOS.
Unfortunately, it seems like Logic always passes a samplerate of 44.1KHz for MIDI FX AUv3 plugins regardless of the project sample rate, so this combination remains broken. I don’t think this can be worked-around in JUCE.
As always, please let us know if you encounter any issues with this change.
2 Likes