discrepency in the order of arguments of slicers

[tremblap]

It seems that one tiny interface error slipped through...

FluidOnsetSlice.ar(in: 0, metric: 0, threshold: 0.5, minSliceLength: 2, filterSize: 5, frameDelta: 0, windowSize: 1024, hopSize: -1, fftSize: -1, maxFFTSize: -1)

vs

FluidNoveltySlice.ar(in: 0, algorithm: 0, kernelSize: 3, threshold: 0.8, filterSize: 1, minSliceLength: 2, windowSize: 1024, hopSize: -1, fftSize: -1, maxFFTSize: -1, maxKernelSize, maxFilterSize)

vs

FluidAmpSlice.ar(in: 0, fastRampUp: 1, fastRampDown: 1, slowRampUp: 100, slowRampDown: 100, onThreshold: -144, offThreshold: -144, floor: -144, minSliceLength: 2, highPassFreq: 85)

vs

FluidAmpGate.ar(in: 0, rampUp: 10, rampDown: 10, onThreshold: -90, offThreshold: -90, minSliceLength: 1, minSilenceLength: 1, minLengthAbove: 1, minLengthBelow: 1, lookBack: 0, lookAhead: 0, highPassFreq: 85, maxSize: 88200)

vs

FluidTransientSlice.ar(in: 0, order: 20, blockSize: 256, padSize: 128, skew: 0.0, threshFwd: 2.0, threshBack: 1.1, windowSize: 14, clumpLength: 25, minSliceLength: 1000)

I think we should unify the order in a way that makes sense in between them. For instance, minslicelength should be after the filterSize and frameDelta in OnsetSlice. And NoveltySlice filterSize should be before its threshold.

A review of this should happen if we agree it would be better.

[weefuzzy]

That would be a very breaky change though, no?

[tremblap]

it would for people not using the labels, but would help in the long run - I get confused by their order all the time...

[g-roma]

Each object has many parameters and they are quite different, I do not think it is so easy to memorise a pattern here. And as @weefuzzy says it woud break people's code, so I am not sure I see the point here. To make them more usable, I would probably try to put the most important parameters, like the minimum slice at the beginning, but maybe a meta-slicer class that can use any of these under the hood and only has high-level parameters would be even better.

[dyfer]

I have certainly been bitten in the past by changed argument order from one FluCoMa version to another. In a complex system it's not always easy to find what the problem is, especially that these changes from version to version are not explicitly documented (as far as I'm aware).

One way to deal with this is to deprecate the method, though that's not feasible with .ar. Another way is to deprecate the class and create a new one with the same functionality, but desired argument order. After some time the deprecated class can be removed, but that can be anytime in the future. That way users of the old argument order get a warning and know how to update their code.

[tedmoore]

Each object has many parameters and they are quite different, I do not think it is so easy to memorise a pattern here. And as @weefuzzy says it woud break people's code, so I am not sure I see the point here.

I agree with @g-roma 's analysis. I always use SC's argument order hints to enter parameters for all of these objects.