-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
time stretching of samples #149
Conversation
Sync to master
Release to master, in sync with tidal v1.1.0
Small fixes to master (LATEST)
initial commit, mostly seems to work but the parameter name(s) and implementation details may change
just to be sure: have you checked the PitchShift UGen for comparison? Your implementation has the advantage that it could be combined with the https://github.com/musikinformatik/WavesetsEvent Quark, that sounds much better to my ear than overlap add. In the end, of course we shouldn't load the standard player with extra things, but add a switch when timestretch is set, to save electricity. |
Whenever I've tried the PitchShift UGen I've gotten really choppy results regardless of windowSize. However, I should check again to do a sound comparison, and I'll take a look at the Wavesets stuff. I wasn't sure how best to conditionally apply the effect. My understanding is it's not really possible to have true branching in a SynthDef, so would there have to be a whole new set of |
…SuperDirt into stretch" This reverts commit 1d6ce85, reversing changes made to 563cda1.
Why don't you implement it as an effect? |
The current version can compress time too, so to do that as an effect would require looking into the future. I don't know how to do that except for samples that've already been loaded. Also, I think working with the sample indexing will be much more efficient, it only ever has two overlapping windows --- whereas as an effect I think it would need to be implemented using a network of staggered delays, some potentially with a very long delay time for large stretches and long samples. Might be interesting to try both, though... |
The current version can compress time too, so to do that as an effect would require looking into the future. I don't know how to do that except for samples that've already been loaded. Also, I think working with the sample indexing will be much more efficient, it only ever has two overlapping windows --- whereas as an effect I think it would need to be implemented using a network of staggered delays, some potentially with a very long delay time for large stretches and long samples. Might be interesting to try both, though...
… On Oct 24, 2019, at 8:37 AM, Julian Rohrhuber ***@***.***> wrote:
Why don't you implement it as an effect?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#149?email_source=notifications&email_token=AB7AIZWKJJLHAJBYJ4575H3QQGQJBA5CNFSM4I7ORIPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECFBVOA#issuecomment-545921720>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7AIZV5LKKQTUVV6GGUZSTQQGQJBANCNFSM4I7ORIPA>.
|
The time-scaling effect is now implemented as an alternate sample playback SynthDef that is only called if the `timescale` parameter is used from Tidal.
OK, the timescaling has now been moved to a separate SynthDef so no extra work is done if it isn't used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The extra complications introduced are worth it, I think! Thank you.
once $ sound "fooloopReset" | ||
-- reset buffers. But do only one time (d1 $ silence), | ||
-- since d1 $ once $ sound "fooloopReset" does not work at my installation (1.4.3) | ||
d1 $ sound "fooloopReset" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe my installation
is ambiguous here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I accidentally merged in something from the develop
branch here, and I thought I undid it but apparently not. I didn't make this change.
@@ -68,13 +68,13 @@ live coding them requires that you have your SuperDirt instance in an environmen | |||
|
|||
numFrames = BufFrames.ir(bufnum); | |||
windowSize = numFrames * timescale / 29.0; | |||
windowSize = windowSize.clip(1000.0*timescale, 4410.0); | |||
windowSize = windowSize.clip(1000*timescale, 4410); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will that work on all sample rates? If not, replace 4410
by 0.1 * SampleRate.ir
).
btw. sorry, I had overlooked your changes. |
out: ~out | ||
]) | ||
if(~timescale.notNil) { | ||
dirtEvent.sendSynth(~stretchInstrument, [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd change this to:
var instrument, args;
...
args = [ ... ]; // the shorter arg list
if(~timescale.notNil) {
instrument = ~stretchInstrument;
args = args.add(\timescale).add(~timescale)
} {
instrument = ~instrument
};
dirtEvent.sendSynth(instrument, args);
…
Then you don't need the same list twice.
out: ~out | ||
]) | ||
} { | ||
// argumets could be omitted using getMsgFunc, but for making it easier to understand, we write them out |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: argumets –> arguments
Shall we make these smallish changes and @bgold-cosmos ? |
I'll refresh my memory on this and look into getting it updated. A lot of things got put on pause during 2020. I suspect given all the SuperDirt changes lately it'll be much cleaner to just redo this as a new PR - the semester is just starting Monday here but if I don't do something within a week or so don't feel bad about pinging me again. |
I think it won't be hard to resolve any conflicts. |
I've redone this, see #229 |
This implements time-scaling for sample playback using an overlap-add (OLA) algorithm.
I tweaked the code with speed and flexibility as priorities rather than output sound quality, but for modest scaling amounts (0.8 to 1.3 or so) it usually sounds fairly good. I'm not aware of any method that will consistently timescale transient-only sounds (most drums) in a "nice" way.
The timescaling should play well with
speed
,begin
,end
and similar parameters, but I'm sure I haven't tested every possible combination.Examples of usage in Tidal would be