• lacuna

    @raynovich fill an array, sum with [array sum] and divide by array size

    posted in patch~ read more
  • lacuna

    With a crossfader you can even do continious morphing.
    Yes, with large arrays you'll get resolution issues. These already happen with [phasor~][*~ highnumber], too - because it does the rounding between the range of 0 to 1, some circles not reaching 0 or 1, while keeping its frequency perfectly stable
    https://forum.pdpatchrepo.info/topic/12865/samphold-noise-phasor-noise-round-off-error-or/15

    posted in technical issues read more
  • lacuna

    @JMC64 I currently can't run pd here, as im writing on a phone, but I'll explain
    @lacuna said:

    @JMC64 phasor~ is part of the sound, because when reading the wavetable, a jump is occuring at it's rising edge . Better use a triangle.

    Sorry, that was wrong: the jump is at the falling edge.
    Looking at the shape of phasor~s waveform: / / / /
    it is a ramp from 0 to 1. Then it jumps within one sample back to 0. That's a sawtooth.
    With a triangle ^^^^
    you can [tabread4~] parts of the array back and forth, without any glitch.

    As you change its range from 0-1 to 0-2048 by multiplying with [*~ 2048] ,
    [+~ 2048] is adding an offset: 2048-4096

    snapshot~ and all other control-objects (everything without tilde ~ ) have a resolution of one blocksize, not updating the right inlet of [tabread4~] on each sample, but up to 64 samples too late.
    Control objects calculate and output between the blocks with 64 as fastest rate (even if the blocksize is changed by [block~] )
    (Bela is running a modified PD with 4 or 8 samples blocksize as minimum, I think - but still. )
    Signal ~ objects calculate between the blocks and output continiously samplewise within the block of the realtime audio stream.

    posted in technical issues read more
  • lacuna

    @JMC64 said:

    I am struggling with creating a externally synched LFO receiving a clock from an external source. For instance a sawtooth (phasor~) .

    receiving a tick( bang) from the emitter

    But the emitter of the clock is of course is not perfect and the clock not completely steady.

    What clock-source is this?
    An audio signal? A Midi clock?
    Keep in mind that PD's control/message domain, including Midi i/o and most control-objects, (such as [snapshot~] ) have a resolution of 64 samples only.
    Is this the cause of jitter here?

    With [tabsend~] you can use every sample of a block~ in the control-domain.

    I tried averaging the value of the time interval with a running average but this is not satisfactory.

    I also wish not to change the average value of the frequency of the LFO every time a tick is received is received, but only when a significant change occurs.

    Maybe try the median, instead of a moving average?
    Together with a hysteresis detecting greater changes, as @whale-av has suggested.

    leading to a desynch with the incoming clock and a slow respond to real change of the external clock (i.e. 120 -> 130 BPM).

    Every averaging filter won't be exact by definiton.
    And to be "on time" at a change, you have to "look-ahead".

    posted in technical issues read more
  • lacuna

    @JMC64 phasor~ is part of the sound, because when reading the wavetable, a jump is occuring at it's EDIT: falling edge . Better use a triangle.
    Instead of using snapshot~ in the slow control domain, you could shift by the right [inlet~] with [+~] in the signaldomain faster.
    To shift at 0, 2048, 4096 exclusively, run a [phasor~] synced to the triangle and flush a [samphold~] with it's falling edge at the start of a phase.
    Or clip the triangle by a very high number to get a rectangular shape flushing [samphold~] at the falling edge: [*~ 9999999999999] connected to [clip~ 0 1] connected to [ samphold~] .
    All this is switching or alternating, not morphing continiously.

    posted in technical issues read more
  • lacuna

    @sdaau_ml said:

    what this .dek file is supposed to be

    it's a Deken-package.
    Deken is build-in PD-vanilla: search & install packages easily
    https://github.com/pure-data/deken

    You can also browse libs available in Deken in the webbrowser:
    https://deken.puredata.info/


    then you can right-click the object and see the Help

    @mganss on Win Vanilla 0.50 and 0.51 the help-patch doesn't load correctly:
    The patch loads but doesn't get drawn: The patch stays in background on the taskbar and appears to be blank. Might be a GUI issue!?
    Could anyone post a screenshot of the helpfile, please?

    EDIT:
    managed to find a screenshot, but still doesn't load in Win Vanilla.

    js-help.gif

    EDIT: @mganss Now I have redrawn the helpfile in Vanilla
    js-help-vanilla.pd

    posted in technical issues read more
  • lacuna

    Py/pyext is currently outdated, not supporting Python 3 but still available https://grrrr.org/research/software/ and still active?

    pdjs lib should run in Purr Data, doesn't it?

    posted in technical issues read more
  • lacuna

    Connect to [% 4] a [sel 3] or [sel 2] and connect this to your up/down toggle.

    Other improvements to your patch:
    Learn [t b f] , you should use it in conjuction with your [2( and [/ 12] to define execution order towards [pow] .
    You might have a look at [mtof] too and use it instead of your conversion.

    If you don't want the envelope to retrigger by changing the numberboxes of attack and release, you can store them in an [f] for each and flush them with your [r metro] and [r attack]

    posted in patch~ read more

Internal error.

Oops! Looks like something went wrong!