Personally, I would keep s_n as the number of samples /per channel/. The total number of samples is simply s_n * s_nchans. Existing externals - that do not know about s_nchans - would effectively operate on the first
i think the idea is that with "s_n = s_nchans * s_length" existing externals would automatically process *all* channels.
that's nice if the external does not do any delays or so (as they would automatically become multi-channel aware), but not so nice if they *do* things in the time domain (as there would be weird cross-talk between the channels).
i'm not favouring any of the two approaches, just wanted to point their differences.
Yup, that's exactly what I had in mind. Any object that is not-multichannel aware and relies on previous input/output samples would produce bogus results. Now, with things like oscillators, the mistake would be very prominent, but with filters it could be very subtle. And subtle errors are the worst of all :-) That's why I think it makes more sense for such objects to only process the first channel.
I think it's worth pointing out that this problem only occurs when the outlet of a multi-channel object connects to the inlet of a legacy object because. The opposite case - legacy object feeding into a multi-channel object - would be perfectly fine.
Now back to the first case: should we consider it a user error? If yes, Pd could even post warnings, but for this we would need a way to tell Pd that an object (class) is multi-channel aware. This could be done with an API method, with a flag for class_new(), or something else...
I'm just brainstorming...
Christof