@synthdef Alternative

[JordanHendersonMusic]

Hi, first, I love this project!

As you may know, there is a long standing argument in supercollider (lang) over args vs NamedControl (I'd link to the forum post, but it is quite toxic...).

Whilst the @synthdef decorator goes some of the way to completely solving this issue, I was wondering what you thought about this instead?

@synthdefTyped()
def my_synth_def(freq=ar(440)):
    sine = SinOsc.ar(frequency=freq)
    Out.ar(bus=0, source=sine)

One downside with the implementation (@synthdef) is that it requires the control definition to be split between the argument (where its name and default value are located) and the decorator (where the rate is). This can be quite confusing when you have many arguments.

I've made a pretty simple implementation of this (I don't know too much about python, but I think this works well):

def ar(value: Union[float, Tuple[float, ...]] = 0.0,
       lag: Optional[float] = None,
       range_: Optional[Range] = None,
       unit: Optional[Unit] = None):
    return Parameter(
        value=value,
        lag=lag,
        range_=range_,
        unit=unit,
        parameter_rate=ParameterRate.AR)


def kr(value: Union[float, Tuple[float, ...]] = 0.0,
       lag: Optional[float] = None,
       range_: Optional[Range] = None,
       unit: Optional[Unit] = None):
    return Parameter(
        value=value,
        lag=lag,
        range_=range_,
        unit=unit,
        parameter_rate=ParameterRate.KR)


def synthdefTyped():
    def inner(func):
        signature = inspect.signature(func)
        builder = SynthDefBuilder()
        kwargs = {}
        for i, (name, parameter) in enumerate(signature.parameters.items()):
            given_param = parameter.default
            if not isinstance(given_param, Parameter):
                raise TypeError
            given_param.name = name
            kwargs[name] = builder._add_parameter(given_param)
        with builder:
            func(**kwargs)
        return builder.build(name=func.__name__)

    return inner

One improvement might be assuming kr if presented with a Union[float, Tuple[float, ...]].

Again, I think this project is great and can't believe I only just found out about it!
Jordan

[JordanHendersonMusic]

Here is the big debate about this sort of thing

Its shares a lot of similarity with the current impl.

Also, this doesn't appear to work with #340

[josiah-wolf-oberholtzer]

Can you be more specific about what's not working?

[JordanHendersonMusic]

Nevermind, just a typo (ar((440, 431)) over ar(440, 431)) I forgot to check last night. It works fine.

[josiah-wolf-oberholtzer]

SynthDefBuilder already implements the idea of "named controls". When you're inside the builder context and lookup names on the builder, you're getting back Parameter instances associated with those names. That's also effectively what's happening with this @synthdef decorator when the decorated function is called, as I'm sure you've surmised.

TBH I'm not a big fan of the decorator. It's a little magical for my taste, and it doesn't play well with static type analysis. That latter is really my least favorite thing about it - when the decorated function is called, all the values are Parameter instances, but when it's defined they might be floats or tuples of floats. mypy can't square that we're saying one thing and doing another, so you can't type check these functions.

Now that said, I'm into the idea of supporting Parameter instances as keyword values for functions decorated by @synthdef. Not into the idea of supporting various combinations of floats, tuples of floats, or various combinations of the above - gets confusing too quickly for my taste. I implemented @synthdef because someone on scsynth.org complained that supriya was too verbose. FWIW I'd rather be more verbose than confusing any day - I don't want to remember what the order of arguments in a tuple is supposed to imply 😆. If using the decorator is cumbersome, just use SynthDefBuilder directly and wrap it in a function.