fx terminology

[felixroos]

is the reverb terminology set in stone? there is room , size and dry. imho dry is a bit generic for reverb (any effect can be dry / wet), also it seems more natural to have the values flipped (0 = dry, 1 = wet). The way delay does it seems more logical: delay is the wet value + any additional param X is declare with delayX (like delaytime). for reverb, this would mean room = wetness and roomsize = reverb decay. or rename to hall / reverb to not confuse tidal users.

[yaxu]

Yes it would be nice to have better names and to feed the changes back into superdirt via deprecation. Some stray thoughts..

.delay(0.2).delaytime(0.25).delayfeedback(0.7).lock(1) (where lock(1) says delaytime is relative to tempo) is a lot to type for one action.

There are delayt and delayfb aliases in tidal and many people have custom aliases for them to make them shorter still. So yep it would be good to think these through properly and rename them in a way that is easier to remember and type.

It would be nice to have the option to combine them like .delay("0.2:0.25:0.7:1")

[felixroos]

it would be practical if patternified functions could have optional arguments, then delay could have 1-3 arguments with default values like delay(wet, time = .25, feedback = .5) . iirc multiple arguments are now implemented to be a sequence, but that functionality could still be used with square brackets: .delay([0.5, 0.25]) (or mini notation).

For now, I have now added room (wet) + roomsize (decay) to #224 , which we can change in the future if we find a more compact solution

[felixroos]

after watching some foxdot performances I realized the following alternative syntax would be quite neat:

s("hh").delay(wet=.5, time=.25, feedback="<.5 1>")

This could be transpiled to

s("hh").delay({wet:.5, time:.25, feedback:"<.5 1>"})

Of course, the object syntax would be valid too, but imo it looks much cleaner without those 2 extra characters + it's faster to type.

This makes it much easier to reason about which number does what (as opposed to multiple nameless arguments) + having a local namespace allows for shorter properties in general. Also, The order of arguments does not matter and it does not matter if all arguments are passed

// lowpass
s("hh").lpf(f=1000,q=10) // s("hh").lpf({f:1000,q:10})
// vs
s("hh").lpf(1000).resonance(10)

// highpass
s("hh").hpf(f=2000,q=10)  // s("hh").hpf({f:2000,q:10})
// vs
s("hh").hpf(2000).hresonance(10)

This also shows that it's possible to name the same concepts with a same name, like f and q for both lpf and hpf, leading to less memorization needed. A mapping could work like this:

// this maps local namespaces to global keys (only global keys are understood by the outputs
const namespaces = {
  lpf: {
    f: 'cutoff',
    q: 'resonance',
  },
  hpf: {
    f: 'hcutoff',
    q: 'hresonance',
  }
}

const name = 'lpf';
Pattern.prototype[name] = function(value) { 
  let pat = this;
  if(typeof value === 'object' && !isPattern(value)) {
    const entries = Object.entries(value); //  [['f', 2000], ['q', 10]]
    entries.forEach([k, v] => {
      const globalKey = namespaces[name][k]; // cutoff | resonance
      pat = pat[globalKey](v); // pat.cutoff(2000) | pat.resonance(10)
    });
    return pat;
  }
/* do the usual thing */
}

[yaxu]

Yes this looks nice but would transpilation to {} imply that the order of arguments doesn't matter? Because due to the default of the righthand argument being applied in to the lefthand pattern, hpq(1,2).hpf(300) is two whole events and hpf(300).hpq(1,2) is one.

It would be nice to support different ways of aligning these different patterns which complicates things as well (will start a new discussion about that).

As an aside there is hpf and hpq in tidal, so I guess the 'f' stands for frequency rather than filter. So perhaps hp(f=400,q=0.2) makes more sense.

[felixroos]

yes, good call. actually the order matters if you use patterns instead of plain values, this would be picked up by Object.entries, which takes the properties as they come from the object, so

hp(q="1 2", f=300) // = hpq("1,2").hpf(300)
hp(f=300, q="1 2") // = hpf(300).hpq("1,2")

I'd say this follows the same intuition as when it's flat..

naming hp / lp without f def makes sense

[felixroos]

btw the above code does only implement the chained method style, but the implementation should be similar for the factory function

[yaxu]

Ah great, I'm used to associative arrays being unordered. If the order is preserved then I don't see drawbacks (but as I say new discussion incoming)

[felixroos]

Maybe this idea is not that great, see #615 (comment)