• seb-harmonik.ar

    @Jona I think the issue with your method is that the value stays the same over the entire block, so using it to drive a function would only output changed values at the beginning of every block.

    you could use your method of adding the samples of a block in conjunction with a [tabreceive~] reading from a table that contains every integer from 0 to blocksize-1 and that would work though.
    (btw I also have an object in my library [pinb~] that simply outputs the current sample # in the block for situations like this)
    also if you do run it at a samplerate of 8000 hz it will take a ~5.5 times longer for rpole~ to not be able to represent than @ 44.1k so in this case it might not be as much of an issue (though obviously a counter that doesn't do that at all is preferable)

    of course any method will lose precision between samples, especially if the counter isn't reset to 0 after 2^32 -1 samples (assuming "t" is a 32-bit integer)
    in pd-double it would probably be better to use phasor~ with / and *~ to scale phasor to increment 1 every sample, with a period of 2^32 samples. Unfortunately in 32-bit float pd you can only represent up to 24 bits of precision so you can't divide or multiply by 2^32 exactly

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

    you can see the formulas here https://www.dspguide.com/ch13/4.htm
    here's a little patch to generate the cosinesum message generate_square_wave.pd

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

    you can use rpole~ with a "1" going into it to generate a signal that counts up every sample. If I understand the code correctly everything is put into a character, which I assumes just truncates the extra bits. so this means you have to divide the output by 256 and wrap~ the result: (and I did a [-~ 0.5] to get rid of dc)
    Screen Shot 2020-09-17 at 11.21.44 AM.png
    and it seems like the sample rate was 8000 hz originally?

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

    @60hz ok I lied.. I decided to get it done now..
    new release
    https://github.com/sebshader/pdnext/releases/tag/0.51-2
    it's msg_iolet_border and signal_iolet_border

    posted in news read more
  • seb-harmonik.ar

    @60hz I've been thinking about that too.. thought it would be cool to have the cables always be the same color as the outline, and also to cut down on "option bloat"

    but I might put it in just to have the option.. I probably won't compile/release again until the next major pd version tho.

    posted in news read more
  • seb-harmonik.ar

    @60hz putting these lines in some .tcl file in the pd path (maybe even in the colors-plugin.tcl file..) will do the trick

    proc redraw_cords {name, blank, op} {
        foreach wind [wm stackorder .] {
            if {[winfo class $wind] eq "PatchWindow"} {
                set canv ${wind}.c
                foreach record [$canv find withtag cord] {
                    set tag [lindex [$canv gettags $record] 0]
                    set coords [lreplace [$canv coords $tag] 2 end-2]
                    ::pdtk_canvas::pdtk_coords {*}$coords $tag $canv
                }
            }
        }   
    }
    
    trace variable ::curve_cords w redraw_cords
    

    posted in news read more
  • seb-harmonik.ar

    @60hz right now the menu item just sets a tcl variable that is referenced whenever cords are drawn or moved.

    it's a bit bigger than the planned scope of the bezier cables feature (it was a small feature just to take advantage of native tk bezier lines) and it didn't seem like that big of a deal for it to be the user's responsibility to redraw by minimizing or re-opening the canvas..

    But, if there's an easy way to loop through open windows in tcl and send a redraw message to pd (or maybe just redraw the cords directly in tcl) I might put it in later

    posted in news read more
  • seb-harmonik.ar

    @60hz and anyone else: I think I got the windows binaries & installer working through virtualbox. They are on the release page.
    There is also the built binaries & tree in "windows files" if the installer fails.
    https://github.com/sebshader/pdnext/releases/tag/0.51-1

    I tested compilation and installation on arch linux & that worked fine also,

    posted in news read more
  • seb-harmonik.ar

    @ddw_music said:

    That's unfortunate. Kind of underscores the point about being out of date -- that will continue as long as the buck gets passed (Pd: "Line drawing is Tk's problem"; Tk: "Line drawing is xlib's problem" and xlib will have some reason not to catch up with modern line drawing). It's a shame that an important part of the computer music ecosystem get held back by dependencies that aren't catching up.

    personally I think it's tk's responsibility to update with an option for modern system libraries or implement something (or provide an option for compiling with a library like cairo or something.)
    of course, as I stated above, there are already tk extensions like tkpath and the developers might just point to those as the preferred way to get modern looks.

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

    @oid as I stated in my first comment in the thread, the reason for the disparity is the different system rendering libraries tk uses.
    on osx it uses core graphics, which supports antialiasing (though I believe you can modify it at runtime with some tcl variable)
    on windows it uses gdi, which does not support antialiasing and on linux it uses xlib, which also does not support antialiasing

    there are no options in either pd or tk currently for enabling/disabling antialiasing. Tk renders how it will render no matter the compilation flags afaik. Antialiasing is always available on osx and always not available on the other platforms due to the nature of the system rendering primitives that tk calls

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!