supporting stereo buffers is a highly requested feature.
of course we can simply have multiple SoftCutHeads with the same parameters and different buffers+inputs; drift should not be an issue. but this is massively wasteful since every calculation is done twice, including loop logic and fade calculation, not just the read/write/resampling.
i see two architectural options:
somehow, extend every subroutine that touches the buffer to deal with >1 input value and >1 channel count in the buffer.
allow SoftCutHead to maintain extra SubHeads for extra channels. these should simply share phase / fade / wrIdx parameters with the "main" subheads instead of recalculating them.
option (1) is sort of the more obvious way, but option (2) actually sounds less painful.
supporting stereo buffers is a highly requested feature.
of course we can simply have multiple
SoftCutHeads with the same parameters and different buffers+inputs; drift should not be an issue. but this is massively wasteful since every calculation is done twice, including loop logic and fade calculation, not just the read/write/resampling.i see two architectural options:
SoftCutHeadto maintain extraSubHeads for extra channels. these should simply share phase / fade / wrIdx parameters with the "main" subheads instead of recalculating them.option (1) is sort of the more obvious way, but option (2) actually sounds less painful.