0

I want to render a sound sequence using RecordNRT. It already works, but the duration of the rendered file is too short.

    var p;

    [\BPM, MasterSequencer.instance.globalBPM].postln;
    [\BARS, this.bars].postln;

    this.sequenceDuration = ((60 / MasterSequencer.instance.globalBPM) * 4) * this.bars;
    [\duration, this.sequenceDuration].postln;

    SynthDef(\sampler, { |out, buffer, rate=1, amp|
        var snd = PlayBuf.ar(2, buffer, BufRateScale.kr(buffer)*rate, doneAction:2);
        Out.ar(0, snd * amp)
    }).store;

    p = Pbind(
        \instrument,\sampler,
        \rate, this.slider2.value,
        \buffer, this.id,
        \dur, (1 / this.steps) * 4,
        \amp, Pseq(binarySequence) * this.slider1.value,
    ).asScore(this.sequenceDuration);

    p = p.score.insert(1, [0, ["/b_allocRead", this.id, this.samplePath, 0, -1]]);
    p.postln;
    Dialog.savePanel({ |path,score|
        var header = path.basename.split($.);
        if(header.size == 1){
            header = "WAV";
            path = path ++ ".wav";
        }{
            header = header.last;
        };
        if(header == "aif"){ header = "AIFF" };
        if(header == "aiff"){ header = "AIFF" };
        if(header == "wav"){ header = "WAV" };

        Score.recordNRT(
            p,
            path.dirname +/+ path.basename ++ ".osc", path,
            headerFormat:header,
            duration: this.sequenceDuration
        );

The calculation this.sequenceDuration=(60/BPM)*4*bars is right i guess, this.sequenceDuration=(4*bars)/(BPM/60) would do it as well. So the imput this.sequenceDurationdoes not match the duration of the outcoming file.

I have no idea what could be the problem. I check the duration and the BPM and the bars by posting them before. I post the duration, everything seems right. Rendering finishes and the file and it has not the right duration.

  • File with bars=4 BPM=70 _should be 13.71 sec, but is 11.71 sec long.
  • File with bars=8 BPM=70 _should be 27.42 sec, but is 23.43 sec long.
  • File with bars=4 BPM=140 should be 06.85 sec, but is 02.94 sec long.
  • File with bars=8 BPM=140 should be 13.71 sec, but is 05.87 sec long.

  • File with bars=4 BPM=120 should be 08.00 sec, but is 04.00 sec long.

  • File with bars=8 BPM=120 should be 16.00 sec, but is 08.00 sec long.
  • File with bars=4 BPM=150 should be 06.40 sec, but is 02.56 sec long.
  • File with bars=8 BPM=150 should be 12.80 sec, but is 05.12 sec long.

1 Answers1

0

You might be seeing a bug which is fixed in the upcoming 3.7 version, in which the last chunk of audio samples failed to get written to disk. The fix was 28th March 2015 here:

https://github.com/supercollider/supercollider/commit/73f779e

3.7 is not out yet but you can build from source or wait for the prerelease.

An obvious workaround is to use longer files than needed, and truncate them afterwards.

Dan Stowell
  • 4,618
  • 2
  • 20
  • 30
  • Thanks for your reply! Okay, well thats good to know, and your suggested workaround is really smart :) I might want to try that before i get build 3.7. – Steffen Jun 21 '15 at 10:33
  • So i tried it with the 3.7 download build from sourceforge, and it didn't work. the truncate idea is actually good, but supercollider does not have a truncate function build in, and my application has to work stand alone. But thank you very much for telling about that bug. – Steffen Jun 30 '15 at 16:21