Logic, and likely also some other hosts, always processes plugins on tracks that don’t have live input monitoring enabled at a block size of 1024, no matter what’s the buffer size in the audio device settings. As soon as you enable live input monitoring or put the plugin on a virtual instrument track rather than one that has an audio file as source you can notice that the block size passed to the audio callback snaps to the buffer size that has been set in the audio device settings.
I’m currently exploring a rather unusual plugin use-case, where the plugin sends samples from the processing callback to a background thread, which will continue working on these samples and then try to apply some results back to the processing in the next block. What I’m doing here will be very tolerant to different block sizes etc – I’m totally aware of all the possible things that can happen with a plugin in a DAW. Still, if the values arrive with less latency, the user experience might be better. Therefore the user might want to lower the buffer size in order to achieve a better responsibility which works well in most major hosts with Logic being an exception here as lowering the buffer size has no impact at all when the plugin is put on a track with an audio file.
What I’m basically asking for is if there is any (hacky) way to convince Logic to not apply that large block size optimisation technique for the plugin but rather process it at the desired block size? I tried changing the type to kAudioUnitType_MusicDevice to make it a fake instrument plugin, but with that Logic no longer let’s me load that plugin on an audio track because it obviously now sees the plugin as an instrument rather than an audio effect.