Synths speed

[ndr-brt]

fix #240

[bgold-cosmos]

If you really want the synths to behave in a similar way as samples do with regard to speed (and hurry), then you should probably at least rescale all the envelopes as well. Otherwise I think dirt_gate will cut off the sound before or after the envelope is done. Ideally you'd rescale all time durations and frequencies (including filter cutoffs) but that could get tedious.

Also, I don't know if it requires a change, but I would note that superpiano is special in that the underlying synth (MdaPiano) internally converts frequency back into integer MIDI notes, so it may behave a little weird when trying arbitrary speed values.

[ndr-brt]

I tried scaling only the pitch and they works well also without touching envelope. Another thing that could be added is the begin/end handling, not hard, but in the meantime the speed one can be enough

[telephon]

Wouldn't it be better to do this calculation in sclang? Then it would apply automatically to all synths.

[ndr-brt]

@telephon would be nice, so it would be easy also to rescale envelope like @bgold-cosmos suggested. But, doing that I imagine also the "buffer synths" should be changed, maybe it will become a breaking change?

[ndr-brt]

I tried scaling the envelopes on the samples, but it seems like the scaled envelope (eg. evelope length / 2 for a sample played at double speed) stops before the sample end, I tried with a spoken word one, it was easier to notice that.

[telephon]

Yes, for it to behave the same way as synths, you need to scale sustain and freq, and possibly you need to do other things, like to reverse the envelope etc. The first two can be done relatively easily for all synths without rewriting any synthdefs. The others need a special set of synths (like imp and psin).

One trade-off is to be considered though: all parameters one calculates in sclang can't be continuously modified, but only on an event basis. The upside is that one need not do this on the synth side for each synth def and each point in time.

[ndr-brt]

Maybe the "scale freq and sustain with speed in sclang" deserves a dedicated discussion in an issue.

Regarding this PR, do you think it's better to scale also the envelope length in the default synths?

[telephon]

Maybe the "scale freq and sustain with speed in sclang" deserves a dedicated discussion in an issue.

Well it is an either or, so if the decision is to do it in sclang, we can close this one and make a new one. But the discussion belongs together.

Regarding this PR, do you think it's better to scale also the envelope length in the default synths?

I don't know what is the best. I do think it will need to be optional.

[ndr-brt]

ok, but this PR is self-contained, so it could be merged?

[telephon]

ok, but this PR is self-contained, so it could be merged?

sorry, this is a misunderstanding. What I mean is: either we do one thing or the other, and depending on that we can merge this PR or do it differently. I am still not sure. It is an important decision, so we can't rush it.

[telephon]

Here is another suggestion, let me know what you think.

https://github.com/musikinformatik/SuperDirt/tree/topic/speed-scaled-freqs

https://github.com/musikinformatik/SuperDirt/pull/244

It adds a scaler UGen, that you can just multiply with your frequency. In Tidal, you can then set # speedFreq 1 (or globally in superdirt, ~dirt.set(\speedFreq, 1). This will then apply acceleration and speed to frequency, and you can modulate speed continually. This adds some ocst to those SynthDefs that use it, and makes them dependent on the superdirt class library, but given the possibilities gained it is simple and worth the effort, I think.

[ndr-brt]

already implemented with #247