• seb-harmonik.ar

    @morpheu5 to me your [pd ks] patch sounds exactly the same as the gen patch if you use the same values he's using: use [1, 0 10( into [vline~], use a [*~ 0.97] instead of [*~ 0.95], and use a [noise~] instead of [pink~]. It sounds brighter but the whole video sounds like the highs are cut to me.
    In the original algorithm the [vline~]'s message would be [1, 0 0 $1( where $1 is the period of the frequency in ms. There was also an averaging filter ([rzero -1]) between the read and the write (but then all feedback coefficients have to be multiplied by 0.5)

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

    @jameslo @whale-av I've been looking at this & I think it has to do with floating-point roundoff stuff.
    I think hypothetically the [hip~] reaches some point of equilibrium in the phasor's cycle, when the increment of the phasor offsets the highpass zero characteristic (but the pole part is still acting, so the pole + phasor increment kind of cancel out the zero, at a given state of the filter). But when the new internal value is subtracted from the last internal value it probably creates a periodic effect that's due to roundoff error when subtracting the 2. It probably depends on the current state of the filter and the current [phasor~] values coming in. The effect is pronounced at low frequencies because the numbers being subtracted are larger due to the pole location being closer to 1.
    that's my guess

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

    @driedstr I've never done it but basically the pure-data "front-end" is an application "shell" that is a wish (tcl/tk) interpreter. It and the actual pd program are separate processes that communicate over a pipe.
    That doesn't mean all of the graphics are all handled by tcl/tk. Tcl/tk reports mouse movements and button presses to pd, which then does all of the object geometry/object creation and then sends messages back to the tcl/tk process to draw the objects in the window.
    So yes, it should definitely be possible to have the tcl/tk process on a different computer than the actual pd process.
    I'm not sure how to actually go about it but you might start here: https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html

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

    thinking about this a bit more, I think it might be easier to just intercept the proc for making the bindings if they should be set to that thing exclusively (if you don't want the alt-click to do what it normally does as well as open a help file):

    rename ::pd_bindings::patch_bindings original_bindings
    # this is for canvas windows
    proc ::pd_bindings::patch_bindings {mytoplevel} {
        # set normal bindings
        original_bindings $mytoplevel
        set tkcanvas [tkcanvas_name $mytoplevel]
    
        # on Mac OS X/Aqua, the Alt/Option key is called Option in Tcl
        if {$::windowingsystem eq "aqua"} {
            set alt "Option"
        } else {
            set alt "Alt"
        }
    
        bind $tkcanvas <$alt-ButtonPress-1> {
            set win [winfo toplevel %W]
            if {[winfo class $win] eq "PatchWindow"} {
                set ::popup_xcanvas %x
                set ::popup_ycanvas %y
                ::pdtk_canvas::done_popup $win 2
            }
        }
    }
    

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

    @rvirmoors the issue is that tcl/tk is reporting %W as the canvas, not the toplevel window the canvas is in.
    this would work: (edit: changed to cross-platform version)

    apply {{} {
        # on Mac OS X/Aqua, the Alt/Option key is called Option in Tcl
        if {$::windowingsystem eq "aqua"} {
            set alt "Option"
        } else {
            set alt "Alt"
        }
        bind all <$alt-Button-1> {
            set win [winfo toplevel %W]
            if {[winfo class $win] eq "PatchWindow"} {
                set ::popup_xcanvas %x
                set ::popup_ycanvas %y
                ::pdtk_canvas::done_popup $win 2
            }
        }
    }}
    

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

    @60hz ok I just uploaded a version w/ tk 8.6.10 anyways

    posted in news read more
  • seb-harmonik.ar

    @60hz I replied in the bug report, but basically the event loop handling is supposed to be much more stable and improved on modern macos with 8.6.11 from my understanding. For instance, 8.6.10 required patching to get the scrollbars to show up on newer osx (also this is why there are 2 different releases for osx on miller's site I think). The patch was kind of hacked out of 8.6.11 which changed the architecture of its event handling since 8.6.10.

    I noticed the bug you mentioned in an earlier release with tk 8.6.10, and the fix was actually merged into main pd vanilla. I cannot reproduce on osx 10.14.6 so unfortunately I'm not sure how to go about fixing it..

    as for the ceammc bug, it is an issue with tk 8.6.11 with the ttk "alt" theme and has to be fixed in either ceammc or tk.
    However you can still package w/8.6.10, I suppose I can upload a version using it instead if it makes that big of a difference..

    posted in news read more
  • seb-harmonik.ar

    @60hz I figured it out, seems like you're right. Might be pertinent to mention in the bug report that it only doesn't work with tcl/tk > 8.6.10

    posted in news read more
  • seb-harmonik.ar

    @60hz do you get that with vanilla too or just w/ next? vanilla distribution is still using 8.6.10 afaik
    edit: I downloaded the library, which properties do you mean?

    posted in news read more
  • seb-harmonik.ar

    @60hz I'm not aware of any new features since 0.51.3 (which ones would ceammc need?), but I went ahead and updated anyways (w/ an improved "font" dialog & fix to "stretch")
    https://github.com/sebshader/pdnext/releases/tag/0.51-4

    posted in news read more

Internal error.

Oops! Looks like something went wrong!