influx clutch: allow excepting influx destination parameters

[adcxyz]

This issue is for discussing two related proposals:

• Allow decoupling specific Ndef params from influx control,
  in order to set/tune/play them by hand (Thomas L)
• allow gradual decoupling/clutch for a random sequence of param names,
  going down to a minimum of two (Julian R).

Technically, both would require more dynamic destination parameter selection.

[adcxyz]

from @telephon mail:

• have a (fixed random) set of output controls that you can “hold with your random teeth”, that is move, hold, and only move the others (like a bit mask on the output part of the matrix). Then randomly shift the bit mask, and move on. Very nice movement, I’d guess.

[telephon]

Technically, both would require more dynamic destination parameter selection.

Wouldn't they just require an array of values that is multiplied with the output parameters, and which is by default [1, 1, 1, 1 ... ]?

[adcxyz]

Wouldn't they just require an array of values that is multiplied with the output parameters, and which is by default [1, 1, 1, 1 ... ]?

Depends on what your plans are with the uncoupled parameters:
in the dogmatic case, it is fine to set the uncoupled ones too, always to neutral;
in the mixed case, uncoupling means you can set the uncoupled params freely from elsewhere.
This requires a list of the params in the order they will be un/clutched in, and an index where the clutch/unclutch border is:

Ndef(\x, { |amp = 0.25, freq = 200, reso = 10, pan, grainy, dense | });

~influxParams = Ndef(\x).controlKeys.select(_ != \amp);
~influxClutchOrder = ~influxParams.scramble.postcs; // rescramble as desired
~clutchIndex = 0.5; // 0.0 to 1.0 
/// in the set func 
var numParams = (~influxClutchOrder.size * ~clutchIndex).round.asInteger;
var paramsToSet = ~influxClutchOrder.keep(numParams).postcs;

// then lookup which influx outs set those params, etc etc

[telephon]

Ah yes, I see, the previous value in the matrix isn't saved. If you would save the previous state of the whole output array of the matrix, then clutching would mean that you keep those and only change some.

matrixOutput = …
matrixOutput = matrixOutput.collect { |x, i| if(clutch @@ i == 1) { prevMatrixOutput } { x } };

No?

[adcxyz]

Even simpler:
always calculate all influx output values (which may be many),
and do the un/clutching on the influx-mapped process parameters only.
These are usually fewer than the influx outs, so we need some adjusting
for different numbers of process params anyway.

[adcxyz]

Since moving some of the NTMI interfaces to relative influx setting, the ideas here need some reconsideration.

[adcxyz]

as there are many variants proposed here, maybe best make one as an addable example,
and describe how to write others for personalization.