Inbuilt effect parameter groups

[jarmitage]

Parameter groups would look like this:

let adsr = grp [attack_p, decay_p, sustain_p, release_p]
    del = grp [delay_p, delaytime_p, delayfeedback_p]
    lc = grp [cutoff_p, resonance_p]
    bp = grp [bandf_p, bandq_p]
    hc = grp [hcutoff_p, hresonance_p]
    io = grp [begin_p, end_p]

And be used like this:

let env = "0.1:0.4:0.3:0.4"
...
# adsr env

Questions:

1. Any other suggestions for groups?

~~2. Is it possible to remove the colon notation? For readability I would prefer:~~

~~# adsr "0.1 0.4 0.3 0.4"~~

Seems this is necessary to do e.g.:

# adsr "0.1 0.2:0.4:<0.3 0.1>:0.4"

3. Is the below also a good idea, or is it possible to do this in a neater way?

let eq = grp [
      cutoff_p, resonance_p,
      bandf_p, bandq_p,
      hcutoff_p, hresonance_p
      ]

4. Are there considerations for tidal-midi required for this?
5. Any SuperDirt considerations?

[telephon]

5. Any SuperDirt considerations?

Is the idea that: a) a synth / effect may take several arguments at a time b) every arrayed parameter creates a series of corresponding synths

Both exist in sclang, it is more about specification. I think for effects only (a) is reasonable unless we really restructure everything considerably.

You can send arrays over OSC, there is a specification for this, using $[ characters. This is even recursive. The thing is that parsing them on the other side does have a bit of an overhead for all the rest (I don't know how much though).

[jarmitage]

Yes (a) is what is intended here.

The tidal notation described actually works already, this is just documented so that a PR can be made to add these to the source.

It doesn't seem to me that there would need to be any changes to SuperDirt but I just wanted to ask.

[bgold-cosmos]

I don't think any changes are needed to SuperDirt or tidal-midi, but it's worth keeping in mind that they may interpret parameters a bit differently, most notably sustain and decay. That's not necessarily a problem, but it might confuse users.

Also, I'd actually suggest lpf = grp [cutoff_p, resonance_p] etc; lpf is already used as a synonym for cutoff but this doesn't really break that and IMO makes it better. Could do the same with hpf and bpf, I think those might be easier to remember.

Might be nice to group speed and accelerate together into something short, but I can't think of a good name.

[telephon]

ah i see. good!

[jarmitage]

I just played a show using the following groups which worked at least for me:

let adsr = grp [attack_p, decay_p, sustain_p, release_p]
    del  = grp [delay_p, delaytime_p, delayfeedback_p]
    gco  = grp [gain_p, cut_p, orbit_p] -- I use this a lot personally
    lpf  = grp [cutoff_p,  resonance_p]
    bpf  = grp [bandf_p,   bandq_p]
    hpf  = grp [hcutoff_p, hresonance_p]
    spa  = grp [speed_p,   accelerate_p]
    rvb  = grp [room_p,    size_p]
    io   = grp [begin_p,   end_p]
    eq   = grp [
      cutoff_p,  resonance_p,
      bandf_p,   bandq_p,
      hcutoff_p, hresonance_p
      ]
    tremolo = grp [tremolorate_p, tremolodepth_p]
    phaser  = grp [phaserrate_p,  phaserdepth_p]

I definitely miss not being able to use non-strings though. Is there a way we could maybe do a grp' that could work something like e.g.:

let rvb = grp' [room_p, size_p]

d1 $ sound "bd" # rvb [scale 0.2 0.4 sine1, "0.2 0.4"]

[bgold-cosmos]

Something similar would be

let rvb a b = room a # size b

d1 $ sound "bd" # rvb (scale 0.2 0.4 sine1) "0.2 0.4"

If you really want the list notation exactly as your example you could define it as

let rvb ps = room (ps!!0) # size (ps!!1)

but that feels a little weird somehow.

[jarmitage]

That makes sense. I'm going to try that for a bit.

[yaxu]

@jarmitage The tidal notation described actually works already, this is just documented so that a PR can be made to add these to the source. Is this still the case?

[jarmitage]

@yaxu I’m still using grp as above yes

[yaxu]

This is the second oldest issue and seems a rather easy one to fix!

adsr = grp [attack_p, decay_p, sustain_p, release_p]

Am I right that sustain in superdirt (and supercollider?) means something a bit different than the usual meaning of S in ADSR? I think sustain in superdirt is the duration of the sound, and in ADSR is the level of the sound.

delay  = grp [delay_p, delaytime_p, delayfeedback_p]
cutoff  = grp [cutoff_p,  resonance_p]
lpf = cutoff
bandf  = grp [bandf_p,   bandq_p]
bpf = bandf
hcutoff  = grp [hcutoff_p, hresonance_p]
hpf = hcutoff
room  = grp [room_p,    size_p]

As @bgold-cosmos says, the first one could potentially stand for the others, as with sound. I'm not sure if this works with numbers though. e.g. how would it deal with delay sine?

(I think the 'del' abbreviation is a bit too ambiguous.)

gco  = grp [gain_p, cut_p, orbit_p] -- I use this a lot personally
spa  = grp [speed_p,   accelerate_p]

I think these are probably in the realm of a personal aliases/style.

io   = grp [begin_p,   end_p]

Nice!

eq   = grp [
      cutoff_p,  resonance_p,
      bandf_p,   bandq_p,
      hcutoff_p, hresonance_p
      ]

With the above, that would be a group of groups, so wouldn't work..

tremolo = grp [tremolorate_p, tremolodepth_p]
phaser  = grp [phaserrate_p,  phaserdepth_p]

Useful!

The issue with not being able to treat groups as numbers could be a problem though.. Maybe solvable

[jarmitage]

I'm not sure if this works with numbers though. e.g. how would it deal with delay sine?

For that I have:

tremolo' r d = tremolorate r # tremolodepth d

It's easy when you're typing to switch between grp and the above:

# tremolo "1:1"
# tremolo' sine "1"

More recently I also have:

tremolo'' r (#) d = tremolorate r # tremolodepth d

This means you have more choice over where structure comes from.

[yaxu]

I find it a bit unsatisfying to add primed versions of functions.

@ghalestrilo has been doing nice things with varargs: https://github.com/ghalestrilo/libtidal

I feel that given a list of 'pF' functions, there should be a way of accepting a list of patterns of variable length to match them. The literature on functional dependencies etc is a bit beyond me though..

[jarmitage]

That would be fantastic if it works. I had assumed this wasn't possible :)