Should slicers slice each channel of a multi-channel buffer separately? In the maxref it says that @numchans configures how many channels of a multi-channel buffer will be summed. What is the intended way that one slices many channels of a multichannel buffer individually. Should I be bufcomposing out to separate buffers or running @numchans 1 and cycling through the various channels? IMO, the default behaviour should be slice each channel separately and if the user wants a slicer running on the sum of (likely) a stereo file then that is their job. Am curious to hear what the motivation is for the slicers working the way they do in their current iteration 
Hmm, I remember the helpfiles having a handy āmultichannel behaviorā tab before.
Without testing it properly, does it presently just dump all of the individual channel info into a single buffer? That seems like odd (default) behavior.
So in that sense, I agree with @jamesbradbury intuition/thinking that if you feed something a 4-channel audio file, that you would get back a 4-channel file with indices in them. (though I guess it gets tricky since they are likely to have different amount of slices in each, so all but one channel would be zero padded at the end?)
This has always been how the buf slicers work. Because they dump indices in the buffer, and because it doesnāt make sense to have a ragged buffer (i.e. a different number of valid samples in each channel), they run in mono.
IIRC, the rationale was that lots of zeros and the odd spike in a buffer gives a lot of redundant data, and is then harder to use, because you then have to scan through looking for 1s. Which is more faffy than running multiple times with numchans 1, if you really want multichannel onset detection like that.
They still do, but the buf slicers never did.
Hmm. Less redundancy than not using indices, so maybe a sensible compromise.
As @weefuzzy says. Many zeros to get the slices is very irritating to work with, and so easy to reconstruct (check all the views in the helpfiles). As for mono summing, it is for me much more āintuitiveā, because slicing independently stereo signal makes very little sense. If it is needed for you, just iterate with @startchan X and @numchans 1, where X is zero-counting the channels. That is why we provide this interface
1 Like
makes sense! I was just curious if my feely-crafting was indeed correct. The CLI is very easy to work around that kind of loopy behaviour, Max not so much.
Not to bad either considering we are bending the thingā¦ qline, or counter, or uzi, depending of how you need things to be actioned afterā¦ or just the queue mode on on our object - although for short jobs you need to be certain to action destinations buffers before you overwrite them.
Itās almost as if buffers arenāt a good container for this kind of info 
.
(I jest)
Ok, that makes sense, and is solvable doing some iterating/looping.
thanks for clarifying. I almost had an heart attack 
@weefuzzy agrees with you and he likes dictionariesā¦ he will convert me one day very soon
1 Like
I know, but itās not like we disagree, although Iād say the problem is rather one of finding good ways of talking to a buffer~ in this context (i.e. interface), than buffers themselves being a problem.
In Max (and SC) there other kinds of container (such as dicts or colls) that would support ragged data, and a longer term mission is to discover some generic conversions we can provide in hosts, whilst retaining the universality of buffers as a base condition. Weāre, of course, hoping that by observing the pain points people encounter them, and the tactics they develop to get round them, that weāll be able to develop a useful range of tools to make the Buffer Thing feel more transparent.
This applies to multidimensional features (like MFCCs) as well, and @spluta has already made some great suggestions on how we could make things less gnarly. Fortunately, some of the plumbing work thatās gone into the second toolbox will make these ideas easier to incorporate.
2 Likes