interpretation of speed, begin, and end

[dktr0]

Hello!

I was working on making WebDirt conform better to SuperDirt and came across this issue/question.

In DirtEvent.sc we have this:

orderTimeSpan {
        var temp;
        if(~end >= ~begin) {
            if(~speed < 0) { temp = ~end; ~end = ~begin; ~begin = temp };
        } {
            // backwards
            ~speed = ~speed.neg;
        };
        ~length = absdif(~end, ~begin);
    }

Which seems to me to be somewhat inconsistent in terms of how speed begin and end are related - although I could well be missing something (especially something relevant elsewhere in the code). (1) If end is greater than begin, but speed is negative, begin and end are swapped so that end is before begin - I understand that, makes intuitive sense to me. (2) If begin is greater than end, then the sign of speed is inverted (by .neg) without regard to whether it was positive or negative to begin with - I don't understand that. Is this a bug or am I missing something? Thanks!

FYI: I am kind of thinking it is a bug and so have implemented the following in WebDirt, basically applying the principle of rule 1 in the preceding paragraph to both situations - something like this:

  if( (this.msg.begin < this.msg.end && this.msg.speed < 0)
   || (this.msg.begin >= this.msg.end && this.msg.speed > 0)) {
      let x = this.msg.end;
      this.msg.end = this.msg.begin;
      this.msg.begin = x;
  }

Thanks for any clarification!

[telephon]

could be a bug, I've never tested it myself (maybe).

But here is the code that actually uses the values:

phase = (speed.sign * LFSaw.ar(sawrate, 1)).range(begin, end) * numFrames;

Maybe one would have to change that as well, if it balances the semantics out.

[dktr0]

I think that second piece of code (where it is used) makes sense, and fits with "rule 1" above but not rule 2. My sense, then, is that the first code might need to be changed to operate more like the JS code I gave. I'm going to go forward with that in WebDirt anyway. Thanks!

[telephon]

I just realised that the ordering is unnecessary in my implementation. It now reads:

orderTimeSpan {
        var temp;
        if(~speed < 0) { temp = ~end; ~end = ~begin; ~begin = temp };
        ~length = absdif(~end, ~begin);
    }

probably I should rename it.

The idea is (and was before): begin and end are the relative positions in the sound file at start and end time. A negative speed reverses these positions.

So when

• begin < end, and speed is negative, we hear the file backwards
• begin > end, and speed is negative, we hear the file forwards, because the two cancel out

I think this may not match the semantics you had in mind? It really depends on the implementation in the backend.

[dktr0]

Ah yeah - I like that better. I'll make WebDirt match that instead. Thanks!

[dktr0]

Closing - WebDirt now matches this too. Thanks again!