Re: running certain spectral(?) plugins faster-than-realtime ... issues
Re: running certain spectral(?) plugins faster-than-realtime ... issues
- Subject: Re: running certain spectral(?) plugins faster-than-realtime ... issues
- From: William Stewart <email@hidden>
- Date: Fri, 20 Aug 2010 19:38:55 -0700
No, at least AUPitch should not be sensitive to this. We deliberatly make no guarantee of calling size, and expect the AU to do whatever buffering it needs to satisfy its requirements.
There is a property that you should be setting: kAudioUnitProperty_OfflineRender (there is documentation for this in AudioUnitProperties.h).
Are you sure that you have set the MaxFramesPerSlice property up correctly and that you aren't getting any errors back from the AudioUnitRender call on any of the AUs in your chain?
On Aug 20, 2010, at 8:28 AM, Richard Dobson wrote:
> On 20/08/2010 15:33, tahome izwah wrote:
>> 2010/8/20 Paul Davis<email@hidden>:
>>> We've had reports from a few users that specific plugins (notably the
>>> Apple pitch plugin and the Michael Norris Soundmagic Spectral plugin)
>>> don't work correctly when used with Ardour/Mixbus' "Consolidate with
>>> Processing" operation. Almost all other plugins tested so far are just
>>> fine. I don't for sure if the Apple pitch plugin is using FFT or just
>>> AM pitch shifting, but the Michael Norris one certainly is.
>>
>> Not sure what AM pitch shifting is (are you referring to a frequency
>> shifter?), but AUTimePitch uses a modified phase vocoder and I would
>> assume that AUPitch is based on the same code.
>>
>
> Of course, there should be no problem. The only thing I can think of is that those plugins depend on or expect a particular block size in order to drive their FFTs. There has been a steady stream of posts over the years on the vst list, at least, from people asking variations on the theme of how they can ensure this or that fixed block size from the host as they need it for their FFT code - anything rather than having to handle their own buffering. If you are changing the block size, that might be what is precipitating the problem. It would be most surprising from such illustrious sources, but (if not already tried) worth a quick test.
>
>
> Richard Dobson
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden