when there is a spread of 0s at the ‘sample’ pin, s+h starts sampling the spread count at its input pin, yet not the actual values at the input pin. don’t know how to word this better, have a go at it yourself:
edit: all the way back to 33beta12 (how did this slip me?) ;)
snh4016bug.v4p (4.4 kB)
at the same time its funny that the output stays at a one sliced spread if the sample pin gets an empty spread, while it usually just follows the spread count.
bascially i think there could be two possible variants or modes of the s+h, one which basically sample and holds a full spread, and one which does a slicewise sample and hold. The current version mixes that a little bit.
but changing the intrinsic details of the functionality would need a very slick compatibility mode, as tiny changes in the empty spread semantics will probably break many legacy patches in their most subtle parts. but an additional mode pin (legacy, slicemode, spreadmode) which defaults to “slicemode” but gets set to “legacy” for all older patch versions might do the trick.