Got bitten by this gotcha last night... it's cute, isn't it?

22-0622-samplerate.pd

hjh

@ddw_music Is that OSX or Linux?
Widows 7 reports correctly even with the delay.
David.

@whale-av said:

@ddw_music Is that OSX or Linux?
Windows 7 reports correctly even with the delay.

Linux, with JACK.

It's not terrible to work around, though the danger is, if some OSes don't require the delay, then a patch made in one of those OSes may not work in one that does require it.

I guess I'll check the help patch later and see if this is noted.

hjh

This looks quite serious. Perhaps you should file a bug report.

@alexandros said:

This looks quite serious. Perhaps you should file a bug report.

Sure, I can do that. Actually I agree that it's a quite nasty behavior if it's different in different environments.

hjh

@alexandros Ah, it turns out there's already a solution for this:

(Well, "funny" above should be "fixed.")

hjh

So this:

[r pd]
|
[route dsp]
|
[sel 1]

gives different results than this?

[r pd-dsp-started]

I guess this should be fixed as well? Shouldn't it?

@alexandros in one case you're telling pd to start DSP
In the other pd is telling you that it has indeed been started

@seb-harmonik.ar said:

@alexandros in one case you're telling pd to start DSP
In the other pd is telling you that it has indeed been started

"telling pd to start DSP" = [s pd]

But here, the message is coming out of [r pd] -- so it isn't telling pd to start DSP. (Don't get confused by the "; pd dsp 1" -- to demonstrate the issue, it is of course necessary to start DSP. But the troublesome chain begins with an [r].)

@alexandros said:

So this:

[r pd]
|
[route dsp]
|
[sel 1]

gives different results than this?

[r pd-dsp-started]

I guess this should be fixed as well? Shouldn't it?

Not necessarily.

"dsp 1" / "dsp 0," as far as I can see, only reflect the state of the DSP switch.

The pd-dsp-started "bang" is sent not only when starting DSP, but also any time that the sample rate might have changed -- for example, creating or destroying a block~ object. That is, they correctly recognized that "dsp 1" isn't enough. If you have an abstraction that depends on the sample rate, and it has a [block~] where oversampling is controlled by an inlet, then it may be necessary to reinitialize when the oversampling factor changes.

It turns out that this is documented, quite well actually! I missed it at first because [samplerate~] seems like such a basic object, why would you need to check the help?

hjh

@ddw_music but how is it different in your example? There's no change of the sampling rate, so essentially, you should be getting the same result, or am I missing something with your two patches here?

@alexandros said:

@ddw_music but how is it different in your example? There's no change of the sampling rate, so essentially, you should be getting the same result, or am I missing something with your two patches here?

As I understand it: [r pd] may be sent before the sample rate has been established, so using it to trigger a samplerate~ object may (in some OS/backend combinations) produce an incorrect result.

Therefore [r pd] is the wrong way to trigger samplerate~.

[r pd-dsp-started] is guaranteed to be sent after any operation that affects the sample rate, including establishing the sample rate the first time dsp is started. Therefore it is the right way.

The help patch for samplerate~ does illustrate use of pd-dsp-started. So really, my "gotcha" is a RTFM situation -- had I read the docs, I wouldn't have made the mistake in the first place. So there's nothing to argue about, in the end. There's a right way and a wrong way, and if you do it the right way, it works.

hjh