• seb-harmonik.ar

    @ingox I usually use something like [list-abs/list-map] (possibly using [drip] from zexy inside [list-map] instead of [list-drip] for efficiency)

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

    @fferri looks like it's working here! (tho haven't tried building since OP.) thanks for tracker!

    posted in news read more
  • seb-harmonik.ar

    @atux not sure which version of else you're using, but often they require an up-to-date pd. Also since pd-l2ork and pd-vanilla diverged it's increasingly unlikely that externals being continuously developed for one after the split would work on both (different apis, different objects, etc.)

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

    @schitz you can probably build for linux by guessing stuff from the windows instructions. just use the linux equivalents of the msys2 packages
    edit: maybe there is some platform-specific tcl/tk code but I would still try it

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

    @Worik use the pdsend program to send fudi to pd. Inside pd receive with [netreceive]
    a man page is in the "man" folder of the pd source tree.
    pdsend is installed into different locations depending on your platform. for MacOS it's in the app bundle (in the "bin" folder). linux probably installs it to the same place it installs pd.

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

    @bklindgren you're running into 32-bit representation issues. a 32-bit number only has 24 bits of representation (the "significand") that is multiplied by 2 to some exponent. So after you store 2^24, or 16777216, you can no longer add one to it since the "ones" place isn't present in the number representation. (because the significand now goes from 2^1 to 2^24).
    you can explore that here: https://www.h-schmidt.net/FloatConverter/IEEE754.html
    (try entering 16777217 - it is not possible to represent. "Value actually stored in float" is still 16777216)

    afaict your options are to:

    1. use the right inlet of [tabread4~] somehow
    2. use the iem_dp library to do the same thing but with its version of [tabread] and [+ ] (probably easier than writing your own) https://git.iem.at/pd/iem_dp
    3. use david's suggestion of breaking up the sample somehow so that it is in chunks < 2^24

    or, if you can skip samples then instead of adding 1 add 2 when you get to 2^24. when you hit the next power of 2 add four, etc

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

    @dfkettle said:

    @seb-harmonik.ar For now, I don't need to cross-compile. And even if some day I do decide to share on Github or whatever, I don't really feel comfortable releasing something for all platforms if I'm unable to test it myself. But I guess most people are faced with the same problem, unless they have access to machines running all three OS's.

    I use osx and run VMs for windows and linux, which seems to work ok.. (except for this unconfirmed slowness on windows)

    posted in extra~ read more
  • seb-harmonik.ar

    @dfkettle I use MSYS2 with mingw64. However I've seen a comment that when I compile pd-next using this method the resulting binary is slower than vanilla. (but it was just 1 comment so idk). and I also use a VM so maybe it's that.

    I think I've heard that if you decide to cross-compile it's easiest to do from linux. (I believe it's possible to cross-compile for osx from linux at least)

    posted in extra~ read more
  • seb-harmonik.ar

    @ddw_music you'd use a 2nd array to keep track of the indices

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!