• ddw_music

    @whale-av said:

    @jameslo It's not a rounding error........ it is drifting for some reason.

    https://github.com/pure-data/pure-data/blob/d07e6efbaef57442d11ca6a83810187256db6292/src/d_osc.c#L95

    ... seems to show that phasor~ is integrating floating point values.

    These floating point values necessarily have some inaccuracy. So their integration will have some inaccuracy, which will accumulate.

    If the result of adding 1/44100 to itself 44100 times is not exactly 1.0, over time this would manifest as drift.

    That is, rounding error can be drift. ...?

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo OK, I skipped over that. Must be some roundoff error, then (particularly if phasor~ is adding a phase increment for every sample). I don't have a solid explanation.

    hjh

    posted in technical issues read more
  • ddw_music

    I would guess the issue isn't the phasor period.

    [metro] can bang only on block boundaries.

    If you're using the standard control block size 64 samples, and the typical sample rate 44.1 kHz, then the block does not evenly divide one second. So you're getting snapshots at a period that doesn't exactly equal half a second, and the snapshots would drift relative to the phasor's cycle. (44100 has only 2 prime factors = 2, so the largest power-of-two block size that evenly divides 44100 is 4. Actually I was a bit shocked a few weeks ago to notice that 44100 = 2*2*3*3*5*5*7*7 :-O )

    But 48000 / 64 = 750 exactly, so that problem might disappear at 48 kHz.

    hjh

    posted in technical issues read more
  • ddw_music

    @ingox “To set variables via inlet is certainly a feature of dataflow/Pd.”

    I guess, the inherent conflict is: the text in the box can't change, because you need it to be saved as is to restore the proper initial condition when reloading the patch -- but this also means there's no way to inspect an object's current state. So the real state is invisible, and must be invisible. (The same is true of local variables in SC, unless you post them periodically.)

    It might be nice if you could mouse-hover over an object and see a tooltip with the current actual parameter values (up to a reasonable amount of text, of course).

    hjh

    posted in technical issues read more
  • ddw_music

    @jameslo "Was there ever anything accidentally connected to the middle inlet that you deleted just before this started happening...?"

    I didn't think so, but there must have been. Replaying it in my mind, that's a distinct possibility though my memory isn't 100% clear.

    That's a prospect that is easy for me to forget about. In SuperCollider, if I write something.clip(0, 300), there is absolutely no chance of anything clobbering those parameters. If I want the boundaries to be variable, then I have to write a variable expression. I understand why it's not the same in dataflows and I'm not complaining about it -- but it did confuse me in this case.

    Thanks for the possible/likely explanations.

    hjh

    posted in technical issues read more
  • ddw_music

    I recreated the object and it works now.

    But... the text in the object box is correct. Why would the object not have been created correctly? I assume object creation is deterministic? But, it wasn't, just now.

    hjh

    posted in technical issues read more
  • ddw_music

    Am I completely and totally misunderstanding the purpose of [clip], or is this a bug?

    clip-failed.png

    I fail to understand how an output value of -1500 has been clipped to the boundaries of 0 and 300. -1500 is going in, yes, but my understanding of [clip] was that it should never come out with these parameters.

    The more reasonable conclusion is that the object simply doesn't work?

    hjh

    posted in technical issues read more
  • ddw_music

    There's one case where you might use [noise~] and [samphold~] -- if the random step function is needed in the signal domain and you expect the sample/hold unit to update in the middle of an audio processing block. (There might be a way to use [random] in this case too, but I'm on my phone and won't work it out just now.)

    When the random number is triggered by a control message, then [random] will absolutely be more efficient (by being idle while "holding").

    hjh

    posted in technical issues read more
  • ddw_music

    @RayManiac If I recall correctly, [oscformat] shouldn't have slashes for the arguments. (That's parallel to the way that [oscparse] removes slashes.) Try [oscformat string]...?

    hjh

    posted in technical issues read more
  • ddw_music

    All good suggestions, thanks!

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!