• ddw_music

    @oid said:

    @ddw_music [expr~] is not terribly expensive for CPU, [fexpr~] is the one to avoid and never use unless you have an actual reason to do so.

    Good to know (and easy to get confused about).

    hjh

    posted in technical issues read more
  • ddw_music

    alexandros -- Sure. I was also thinking of the advice to avoid expr~ wherever possible, for performance. (Come to think of it... aren't you the developer of omniFilter_abs~, which reworks the mmb filters to avoid fexpr~?)

    seb-harmonik.ar -- I wonder whether tabread~ or clip~ is faster.

    lacuna -- Ooh, that's very good. I had half of this idea (recognizing that the signal, clipped to the range, would be equal to one of the endpoints for out of range inputs) but I hadn't come up with the rest.

    Thanks!
    hjh

    posted in technical issues read more
  • ddw_music

    Wondering if there's a more efficient way to do the bit in gray. It's an approximation of InRange.ar(signal, low, high) from SuperCollider (except that InRange is 1 if low <= signal <= high, while this Pd patch produces 1 for low < signal < high, close enough).

    (I never understood why signal-rate comparators aren't in vanilla...? I know they're in cyclone but that doesn't explain the reasoning why they didn't make the cut for vanilla.)

    pd-inrange.png

    hjh

    posted in technical issues read more
  • ddw_music

    @lacuna said:

    Who hears clicks when switching at zero-crossings?

    It's always been absolute nonsense that it's safe to edit at zero crossings -- as you demonstrated :grin:

    I think: to avoid clicks, not only the signal itself should avoid discontinuities, but also the derivative (the slope) of the signal should avoid discontinuities. A sharp cutoff at a zero crossing will feature a break in the slope even if there isn't a large jump in the signal itself.

    This is also why a sinusoidal envelope is smoother -- because the slope of the envelope is itself a sinusoid (derivative of sin = cos and vice versa).

    hjh

    posted in technical issues read more
  • ddw_music

    Amplitude modulation of any sort, including envelopes, always distorts the spectrum to some extent.

    Normally we don't notice because typical sounds have a complex spectrum, which masks the distortion.

    But here, you are applying it to an artificially simple spectrum, containing only DC offset. DC offset is silent, and the spectral distortion is not, so there is nothing to cover it.

    I generated an audio file with a 30 ms ramp up and 50 ms ramp down. For comparison, I applied this envelope to a sine wave in the right channel. Then I opened this file in Audacity and looked at the spectrogram.

    env-puff.png

    I think it's pretty easy to see here why the envelope might be audible in the case of DC * envelope, but not perceptible in the case of the audible signal * envelope.

    Bottom line is, just because you hear spectral distortion in an artificial scenario which you would never encounter with audible signals, doesn't mean that it will be noticeable in real world scenarios.

    (Carrying it further: If there is no envelope, there's a risk of an instantaneous transition from non-zero to zero or vice versa. Instantaneous transitions require a lot of high-frequency content, which we hear as a click. A linear transition effectively lowpass-filters the instantaneous transition -- there are still artifacts, but they are relatively low amplitude, and in a frequency range normally occupied by musical tones at a much higher amplitude. A ramp-enveloped sound will never be perfect, but it's better than a rectangular envelope.)

    "replaced by something better" -- A sinusoidal envelope shows a smoother spectrogram. You might try that: cos * 0.5 + 0.5 -- from pi to 2pi is your ramp up, 0 to pi is the ramp down.

    Edit: You can eliminate the +0.5 by squaring the cos and halving theta, because cos^2 x = cos(2x) * 0.5 + 0.5. Actually cos~, IIRC, scales radians down to 0 .. 1, so you could do line~ --> cos~ --> [*~] (cos~ to both inlets) and drive it by "0.25, 0.5 30" for the ramp up, and "0, 0.25 50" for the ramp down. Haven't verified this at the computer but I think it's right.

    hjh

    posted in technical issues read more
  • ddw_music

    I got confused by two seemingly contradictory comments here:

    ingox: "In that case [sel all stop] can help. But it cannot deal with [all(..."

    Obineg: "sending 'foo' to [select foo] works as expected"

    From these, I'd have to conclude that one of the following is true:

    A- a message consisting of a single untagged symbol doesn't match in [select], and the second quoted comment is mistaken (neither "all" nor "foo" would match);

    B- most symbols match in [select] (hence "foo" would be ok) but there's something special about "all" that select doesn't like.

    "A" seems more plausible... but ingox's remark could also mean that "stop" is ok while "all" is not (B)...?

    [list] --> [select] is a useful trick.

    It's a bit tricky that [route values...] matches the first item (which it kinda has to) while [route types...] matches the type of the entire message. That threw me off at first. It sorta makes sense though.

    hjh

    posted in technical issues read more
  • ddw_music

    Ok, bug report time. Thanks for clarifying that I didn't overlook something.

    hjh

    posted in technical issues read more
  • ddw_music

    Yes, I think I covered all those bases in the posted patch (including the conversion of e.g. "all 123" to bang, rather than 123).

    I wonder, though, what is the reason for [select] to choke on "all."

    hjh

    posted in technical issues read more
  • ddw_music

    Is there a message one can send to an [array define] to open its window programmatically?

    You can click on the [array define] object to display a graph in a separate window.

    But if the [array define] is contained in an abstraction, then the user would have to open the abstraction and then click on the array object.

    I would like the abstraction to respond to a message such as "vis 1" / "vis 0" by opening or closing the window.

    hjh

    posted in technical issues read more
  • ddw_music

    If pd-extended could differentiate visually between control and signal ports, then it's already known how to do that... would it then be terribly much trouble to do in pd-vanilla?

    Or does it depend heavily on other stuff from pd-extended?

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!