• seb-harmonik.ar

    @cfry Pd is composed of 2 processes: The "c" code is compiled into the main process, which handles all of the audio and message processes and some of the gui logic, and the tcl/tk/wish process which handles the actual visual interface/gui.
    The 2 processes communicate by sending strings over a pipe

    Whenever pd creates a new patch window, it creates a tk "canvas" object and gives it a name according to the value of the pointer for the patch. I haven't looked into how pdtk_text_set works but somehow pd is sending the tcl/tk/wish process the name of a canvas that doesn't exist on the tcl/tk/wish side

    This is a bug, so if you can give steps to consistently reproduce it we should file a bug report

    posted in technical issues read more
  • seb-harmonik.ar

    I don't get it,, why not just multiply by the reciprocal of 127 (~0.00787402) using [* ]? (multiplication is more efficient than division I think)
    To get 0-100 just multiply by 100/127=0.78740157480315

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo said:

    A couple of us noticed that the low pass outlet attenuates at high cutoff frequencies

    no idea, sorry. I haven't sat down and tried to wrap my head around vcf (especially how the 2nd outlet functions as a lowpass)

    posted in technical issues read more
  • seb-harmonik.ar

    @pure_raspberry yes the response will still be a 1-pole lowpass, it's just the pole location that's approximated

    posted in technical issues read more
  • seb-harmonik.ar

    @pure_raspberry the frequency setting only goes up to sr/2pi, so in your case ~7639.44
    see here for a full explanation about the frequency-warping and patch https://forum.pdpatchrepo.info/topic/9723/lop-object-argument

    posted in technical issues read more
  • seb-harmonik.ar

    @bgarton just fyi, aside from the object-specific destructor it's also possible to have a class destructor with class_setfreefn (I only mention it bc it isn't documented in the writing externals tutorial)

    posted in technical issues read more
  • seb-harmonik.ar

    updated to 0,51-0
    https://github.com/sebshader/pdnext/releases/tag/0.51-0
    added many more colors (documented in doc/7.stuff/colors-plugin.txt)
    colors have changed names

    added option to use tk Bezier cords (don't look great, selection is a bit off), however the functions to draw the cords have been moved to tcl code, allowing gui plugins to overwrite them (this allows patch cables to look however the tcl plugin author might want, with whatever tk can do)

    also added preference menu item for bezier cords
    they can also be turned on/off by setting the tcl variable "::curve_cords" e.g. "set ::curve_cords 1"

    A couple fixes for help menu getting greyed-out on osx, and to display the array name when it's created
    Screen Shot 2020-06-06 at 8.13.07 AM.png
    edit: fixed message/audio cable bug 8:10 PST 6/6/2020

    posted in news read more
  • seb-harmonik.ar

    @whale-av that makes sense bc powers of 2 are easily represented exactly in binary floating point (so the increment can be represented exactly without roundoff error)

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo yes, @ddw_music was correct. It's a combination of double and single precision (and I edited my last comment, this prediction is consistent w/ the 1st patch at least). The value "conv" in the source code is stored in a t_float, which is generally a 32-bit float these days (though maybe that will change soon..). This is set to 1/samplerate. every sample conv is multiplied by the input frequency (which is also a 32-bit float) and then added as a double to the current phase, which is a double with value 1572864 + actual phase, (1572864 is 3^19, a float value that makes bit 32 of the entire 64-bit double value the 1s place, leaving the remaining 32 bits as the fractional part). Every sample the top 32 bits of the phase are set to the top 32 bits of 1572864, and when the phase is output, 1572864 is subtracted from it.

    tldr: the phase accumulator is basically 32-bit fixed-point

    posted in technical issues read more
  • seb-harmonik.ar

    @jameslo just investigating further: the closest that a 32 float value can come to representing 1/44100 seems to be 0.00002267573654535226523876190185546875. However, since bit value 32 must be 1 and because the exponent of this number is 2^-16, that means that once this number is added to 1572864 as a double the fractional part can only represent
    0.0000226758420467376708984375

    0.0000226758420467376708984375×44100 = 0.00000463426113128662109375
    as the fractional part of the first "wrapped-around" sample (I might be missing something, but something like that is probably happening)
    edit: actually after testing this matches exactly with the behavior of your first patch :-) (1st wrap-around is that # after sending "1" to the phase of phasor~ and the toggle at the same time)

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!