You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This however can be unsound in the case where the host sends in-place (i.e. aliased) input and output buffers for different ports (which is weird but still valid according to the CLAP spec), where the current PairedChannels abstraction cannot detect it.
This was attempted to be solved in #26, but after some discussions it turns out this solution of preventing to borrow buffers as &[f32]/&mut [f32] was too restrictive for many use-cases.
Considering the only unsound case is the simultaneous borrowing of input & output, I think the solution should be some sort of in-between:
First, remove multiple port-pair borrowing, or only allow it in a sort of lending-style iteration.
Replace it with the AudioBuffer abstraction from Safe plugin buffers #26, which safely allows the common use case of copying inputs into the output buffers.
Currently, the
Audiostruct inclack-pluginallows to borrow multiple different inputs and outputs simultaneously, e.g. like this:This however can be unsound in the case where the host sends in-place (i.e. aliased) input and output buffers for different ports (which is weird but still valid according to the CLAP spec), where the current
PairedChannelsabstraction cannot detect it.This was attempted to be solved in #26, but after some discussions it turns out this solution of preventing to borrow buffers as
&[f32]/&mut [f32]was too restrictive for many use-cases.Considering the only unsound case is the simultaneous borrowing of input & output, I think the solution should be some sort of in-between:
AudioBufferabstraction from Safe plugin buffers #26, which safely allows the common use case of copying inputs into the output buffers.