• ddw_music

    @alexandros Ah OK, I had overlooked [rzero_rev~] -- I suppose even without that, I might have thought of [rzero~ -1] and subtracting the input -- (signal - (-1 * signal[-1])) - signal -- but I didn't. [rzero_rev~] is a good trick.

    hjh

    posted in technical issues read more
  • ddw_music

    Here's the final version.

    At first, it didn't seem to work -- the "old" and "new" [samphold~] objects were outputting the same value. Eventually I figured out that it was because I was trying to clean up the patch's appearance by passing the [phasor~] through a [send~] / [receive~] pair (going into the "old" [samphold~]). Apparently (which I didn't realize at first) this introduces a one-block delay -- so I was reading the "old" value too late.

    Using direct signal connections for all of them, this does exactly what I want.

    This is part of a multimode LFO abstraction that I'm giving to students. I'll go ahead and attach that -- -1 .. +1 range, LFO shapes are sine, triangle, sawtooth, pulse, random sample-hold and random with linear interpolation.

    Thanks for the tips! Learned something.
    hjh

    lfo-line-ok-final.png

    lfo-norm-hjh~-help.pd
    lfo-norm-hjh~.pd

    posted in technical issues read more
  • ddw_music

    @jameslo I think the fexpr~ trick is the missing piece -- the right answer is probably a combination of your two approaches. I'll probably delay the output of one samphold~ and feed that into a second samphold~ (both driven by the phasor~), which would be a literal translation of the SC code.

    Thanks! I hadn't thought of fexpr~ as a way to get a one-sample delay.

    hjh

    posted in technical issues read more
  • ddw_music

    @Il-pleut thanks, but I was avoiding line~ on purpose. Say the LFO rate drops to 0.001... you'll be waiting a thousand seconds before it can speed up again. (SC has that problem in LFNoise1; LFDNoise1 was added to address that. It's the latter behavior I'm trying to emulate.)

    I might try the lop~ approach later. I think I'd tried something like it before, for a different technique, but it didn't work out so well because noise~ hasn't enough low frequency energy.

    hjh

    posted in technical issues read more
  • ddw_music

    @whale-av hm, I'm not sure.

    The problem I ran into is that phasor~ usually jumps to 0 in the middle of a block. The random number needs to flip at that exact moment -- if the line formula is (b-a) * phase + a, then the previous random number needs to go into a and a new random number into b, and if this happens synchronously with the phasor reset, then the output was almost exactly the previous endpoint, and becomes exactly a, so it runs continuously.

    If there are any control objects involved, then they don't fire until the next audio block boundary, which is too late. So I think I can't use any messages at all for this. (I had tried that at first but there are very obvious discontinuities in the output.)

    Sometime later I may try a short delay line. SC happens to have the convenience of a dedicated one-sample delay. Or... hm... I just realized I could use a 0 ms delay but arranged as feedback.

    (Should also say, I was using phasor~ to allow modulating the LFO frequency. I could do it all in the control domain feeding a [line~] but it won't update the LFO rate until the next endpoint.)

    hjh

    posted in technical issues read more
  • ddw_music

    I would like to create a Pd equivalent of SuperCollider's LFDNoise1 LFO (random line segments).

    It's basically like this. In Pd, I can see how to do almost all of it, except for sample/holding the previous random value.

    (
    a = {
        // pd: phasor~
        var phasor = LFSaw.ar(1) * 0.5 + 0.5,  // 0-1
        // pd: [rzero~ 1] --> [<~ 0]
        trig = HPZ1.ar(phasor) < 0,  // 1 when phasor drops
        // pd: [samphold~]
        nextEndpoint = Latch.ar(WhiteNoise.ar, trig),
        // pd: I don't know how to do this
        prevEndpoint = Latch.ar(Delay1.ar(nextEndpoint), trig),
        // pd: easy math
        line = (nextEndpoint - prevEndpoint) * phasor + prevEndpoint;
    
        // simple test signal: map bipolar LFO exponentially to freq
        SinOsc.ar(400 * (2 ** line), 0, 0.1).dup
    }.play;
    )
    
    a.free;
    

    I made one failed attempt using [phasor~] --> [rzero~ 1] --> [*~ -1] --> [threshold~] --> [random], but if the phasor jumps to zero in the middle of a control block, then the random calculation is out of sync and the output glitches slightly. So I need to keep all of it in the signal domain (no control objects).

    Thanks,
    hjh

    posted in technical issues read more
  • ddw_music

    @whale-av I see, recursion is the only way, then. zexy is probably easier to explain to the students.

    Thanks!

    hjh

    posted in pixel# read more
  • ddw_music

    @Jona "because you send the gem pointer to the second inlet of [translateXYZ] which expects a float."

    I don't think so:

    x.png

    The [f] box is whale-av's suggestion above, to deal with a different error.

    hjh

    posted in pixel# read more
  • ddw_music

    @whale-av

    Alas:

    consistency check failed: gpointer_copy
    inlet: expected 'float' but got 'pointer'
    Couldn't convert gem_state to float.
    

    It's funny... seems like this "should" work.

    hjh

    posted in pixel# read more
  • ddw_music

    @whale-av I'm trying your [repeat] substitution but it seems not to work with gemlists.

    repeat-subpatch-wtf.png

    repeat-vs-gem.png

    [gemglxwindow]: Direct Rendering enabled!
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    translateXYZ: no method for 'symbol'
    consistency check failed: gpointer_copy
    consistency check failed: gpointer_copy
    inlet: expected 'float' but got 'pointer'
    inlet: expected 'float' but got 'pointer'
    translateXYZ: no method for 'symbol'
    consistency check failed: gpointer_copy
    inlet: expected 'float' but got 'pointer'
    inlet: expected 'float' but got 'pointer'
    translateXYZ: no method for 'symbol'
    consistency check failed: gpointer_copy
    inlet: expected 'float' but got 'pointer'
    inlet: expected 'float' but got 'pointer'
    translateXYZ: no method for 'symbol'
    

    etc.

    Am I doing it wrong? Or are gemlists "special" somehow?

    hjh

    posted in pixel# read more

Internal error.

Oops! Looks like something went wrong!