• 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
  • seb-harmonik.ar

    similar to @ddw_music's solution you could also have each list be associated to a number and 2 arrays, one that maps indices to list number and one that maps from list number to index in the 1st array. When a list gets turned off, decrement the range of the rng/highest current index and swap the number with the number of the current highest-index list in the 1st array. Update the index numbers in the 2nd array to reflect that. When a list gets turned back on you do the reverse: swap it with the number lowest currently-off index, increment rng range and update both values in the 2nd array.

    Then when you generate a random number you look up which list to route to using the random number as an index into the 1st array. You could use [list prepend] plus [route], or [demultiplex] from zexy.

    hopefully that makes some sense.. it's similar to the "urn" algorithm (non-repeating random numbers)
    https://stackoverflow.com/questions/196017/unique-non-repeating-random-numbers-in-o1

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

    I took a shot at optimizing a bit. the main patch looks good but in addosc there are a few little things (which may add up bc you have 224 of them):

    [tabread~] is taking a control-rate input. So, it isn't doing anything that [tabread] couldn't do, and have it translated to a signal later down the graph instead. The difference is that [tabread~] will still process the last input every sample whereas [tabread] will only output when it gets a new message. (so you'll be doing about samplerate times fewer computations if you have a new input every second)

    similarly [+~ ] and [*~ ] are more efficient if you use the versions with a control-rate right inlet bc the loops can be vectorized and maybe predicted better. (to do this supply them with a float argument).

    generally the arithmetic objects are more efficient than the [expr~] family. And, [expr~ 1 - $v1] is also another case of not needing the signal version bc the input is control-rate (after changing it to [tabread]). Instead you can change it to [1 $1( going into a [- ]. (tho in this case idk if it is actually better than [expr 1 - $f1] bc we also have to process/send the list from the message box.. the main thing is making it control-rate tho)

    The final little thing is replacing the division [/ 127] in the adsr subpatch by multiplication with the reciprocal, bc processors are better at multiplying than dividing. You can do this any time you're dividing by a value that won't change.

    hope it helps
    addosc.pd

    as for locality I think the only way is to use $0 in your arrays like you say.. you might consider making addvoice an abstraction as well. Then you could supply $0 as the argument, and inside supply it as the 2nd argument of [addosc] with $1, which could then use it as $2 in the [tabread]s to refer to the grandparent's $0

    that way you'd only have to edit 28 [addosc]s instead of 224

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

    @FFW the norm is a real number but that's the "magnitude". the real part of the number itself is the "horizontal" (non-imaginary) component of the complex number

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!