Not entirely unexpectedly the multi-channel read API is a little clumsy to use and reflects the implementation more than desired use cases.
I see two use cases that can solve this and we probably want both (which will actually wrap the current read implementation)
read_channels_2d(&[&ChannelPath], &[f64])
This would treat the f64 array as a 2d array and read channels in as rows (assuming a row major format). Internally we would have to use split mute to then call the existing API.
read_channels(&mut [&mut {ChannelPath, &mut [f64]}])
This would take a struct which provides both the path and the output buffer in a single place. I went to this because it fits the existing API but not sure if it is actually superior to read_channels_2d.
Not entirely unexpectedly the multi-channel read API is a little clumsy to use and reflects the implementation more than desired use cases.
I see two use cases that can solve this and we probably want both (which will actually wrap the current read implementation)
read_channels_2d(&[&ChannelPath], &[f64])This would treat the f64 array as a 2d array and read channels in as rows (assuming a row major format). Internally we would have to use split mute to then call the existing API.
read_channels(&mut [&mut {ChannelPath, &mut [f64]}])This would take a struct which provides both the path and the output buffer in a single place. I went to this because it fits the existing API but not sure if it is actually superior to read_channels_2d.