Any known tricks to make Logic Process a Plugin on a track without live monitoring at a lower block size?

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.

1 Like

Why not have your own block size and segment incoming buffers into that?

The problem is not slicing the samples into matching blocks, I do that anyway.

My main goal is that the background worker thread will need some time to compute its results. When sample blocks arrive in a real time context there is usually some time between these callbacks which most of the time is enough time to let the background thread do its work, so I basically want to make use of the more or less regular pattern of process callbacks and do some stuff in the background in between those callbacks and use the result if it has been computed in between or use a fallback strategy if not.

1 Like