@bellyband Fwiw... Did you try starting Pd without loading a patch immediately?

That was suggested above but it's not clear to me whether you tried it or not.

For "differential testing" this would tell the difference between a pd startup problem and a patch-loading problem.

In any case plugdata's interface has a lot to recommend it. As tcl/tk ages, it becomes more and more likely to run into weird problems like this, so it's good that there's a modern alternative.

hjh

I don't have an answer to this question (and can't report other results, since I also use Reaper), but I have to admit that I'd expect extremely low impact on any actual projects where I'd be using Plugdata. Typically one would export a bit of silence at the beginning -- that first empty block from Pd is technically incorrect, but unlikely to be noticed in practice.

Maybe log a bug for it? But if I were Timothy, I wouldn't treat it as a critical bug. (Now, if there were a 64-sample shift throughout, that would be critical.)

hjh

Right channel of one audio file was broken -- plugdata was a nifty way to use only the left channel, and throw in a little Haas delay too.

@timothyschoen plugdata recent versions have gotten to be really convenient -- super easy audio Swiss army knife for any DAW, great stuff.

hjh

@jameslo said:

Edit: I just looked it up. The spec lists F7 as a status byte, so I guess sysex has two status bytes. Confusing.

Yeah, this was the sense in which I meant status byte (any byte in MIDI whose most significant bit is set).

hjh

If there's no status byte, how do you know when the message is finished?

In SuperCollider, the backend packs up the bytes as an Int8Array (there's no user-facing byte-by-byte interface), which sidesteps that question. But if the sysex object is emitting a stream of bytes, it seems to be that a closing delimiter would be necessary.

hjh

@ben.wes said:

i was surprised first, since it would certainly feel intuitive to dynamically change the channel count that way.

I get the feeling that changing a channel count dynamically is something that's obvious to humans but harder to implement than one might have thought. In SC, you can change a channel count by stopping the synth node in question and starting a new one with the new topology -- and there's no other way. Multichannel send/receive has at least one restriction that's noted in the help file (changing receive size requires switching DSP off and on again).

One possible tricky point is that an upstream change of channel count would have to cascade through downstream objects.

Anyway I don't know Pd implementation details so I haven't got much to add to what I just said.

hjh

Ohhhh... Thanks for clarification. I had just assumed 4-point interpolation would be cubic.

hjh

@jameslo said:

That's gotta introduce some fidelity loss, no? Has that bothered you enough to make you write something clever to get the indexing back to integers?

A/ maybe? but B/ no.

One way to measure the error is like this:

But this is just measuring the difference between integer-indexed samples and fractionally indexed ones, which doesn't necessarily indicate a perceptible difference in the sound. Basically the [+~ fraction] is a phase shift. You could phase shift a sine wave by 180 degrees and see a large deviation, but both still sound like sine waves (0 perceptible difference).

(I tried listening to the phase shift -- basically a bit HPF-ed result -- nothing disturbing.)

My opinion is: cubic interpolation is a well tested formula. Nothing significant to worry about here.

hjh

Also, past a certain point, the extra precision doesn't make much difference... diminishing returns.

(
f = { |rand = 100, pct = 25, num = 1000000|
    var sum = 0;
    num.do {
        if(rand.rand < pct) { sum = sum + 1 };
    };
    sum / num * 100
};
)

// 100 divisions
a = Array.fill(100, { f.value }); [a.minItem, a.maxItem, a.mean, a.median]
-> [24.9017, 25.1103, 24.999769, 25.0032]

// 1000000 divisions
a = Array.fill(100, { f.value(1000000, 250000, 1000000) }); [a.minItem, a.maxItem, a.mean, a.median]
-> [24.9156, 25.1133, 24.996608, 24.9942]

hjh