• ddw_music

    @jameslo said:

    @whale-av I'm dying to show you how straightforward it is to port procedural algorithms to Pd but I want to enjoy your admiration a little longer :)

    I'm dying to see this, as I'm continually impressed with how obscurantist graphical languages are about procedural work. (I've actually gotten reasonably good at some cases that are not exactly simple. Recursion eludes me though, because it depends in procedural languages on local stack frames, which seem... inconvenient in Pd.)

    hjh

    posted in technical issues read more
  • ddw_music

    @vobb said:

    Hello and thanks for taking the time. FFT is not restricted to power-of-two but it runs most efficiently that way, unless this SE thread is completely off it's O(N log N) vs O(N^2))

    Good link, thanks, I knew that the optimal FFT recursively divides the frame in half, but hadn't thought about other small-integer factors. Actually I can't quite visualize how it works except for the optimal case, but I'll trust that the FFT library knows what it's doing.

    It's very likely, though, that the pitch will be a non-integer number of samples. And syncing the block size to a changing pitch is likely to be... amusing.

    Anyway hope you get some useful data from it.

    hjh

    posted in technical issues read more
  • ddw_music

    First, FFT is restricted to power-of-two frame sizes, so you can't match the window to an arbitrary pitch.

    Second, if I understand correctly, fft's frame size is controlled by a [block~] object in the same subpatch performing the fft.

    hjh

    posted in technical issues read more
  • ddw_music

    @kyro Was pondering that... does it need to be a one-sample delay? To go to a reasonable extreme, 24 ppq at 200 bpm, at 44.1 kHz = 44100 / 200 * 60 / 24 = 551.25 samples per tick. A full control block's delay should be fine, probably more reliable.

    hjh

    posted in technical issues read more
  • ddw_music

    Expanded my pulse counter a bit: Dividing the pulse magnitudes, and then re-doing the edge detection works.

    If the ratio is an integer, then it's more-or-less a classical modular pulse divider (though it assumes the pulses are single-sample, which [phasor~] --> {rzero~] --> multiply-and-clip does provide).

    If the ratio is rational but non-integer, then you get sorta like Euclidean rhythms for free! (1.75 is producing ONE two THREE four FIVE six SEVEN ONE two ... I also tried dividing by 8/3 and got one of the standard Euclidean clave rhythms, One two three Four five six Seven eight One two three...)

    pd-pulse-divider-2.png

    22-0504-pulse-divider.pd

    hjh

    posted in technical issues read more
  • ddw_music

    Here is another way to count pulses in the signal domain. It works only for rpole~ 1, but once you have the count, you can divide by some factor and watch for the scaled-down count to cross an integer boundary.

    pd-signal-pulse-counter.png

    (I'm not sure if I accidentally replicated techniques already discussed -- my thought was to try to make a simple pulse counter, rather than maintaining phase in between pulses. By integrating single-sample full-scale Dirac impulses, perhaps it avoids the trickier float precision problems.)

    hjh

    posted in technical issues read more
  • ddw_music

    My rule of thumb is: It's safe to have multiple patch cables from one outlet only when all of them are connected to cold inlets.

    Both of these were connected to hot inlets (broke the rule --> had problems). IMO if even one is hot, then order matters = use [t].

    Not that complex a guideline but it took me 2 years of Pd-ing to figure out = pedagogy problem.

    hjh

    posted in technical issues read more
  • ddw_music

    @seb-harmonik.ar said:

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

    Ah ok, overlooked that. "Exercise for the reader"...

    hjh

    posted in technical issues read more
  • ddw_music

    Alternate to oid's solution, if you'd rather focus on the random indices and keep a stable collection of lists:

    pd-random-list.png

    I had considered seb-harmonik's approach to removing the item, but you'd need to iterate to find the index to delete anyway, so I went with a filter operation.

    (This, btw, is easier in a text-based programming language where you have proper variables that can be defined once and used in multiple locations, eliminating the need to sync multiple [list] storage locations.)

    hjh

    posted in technical issues read more
  • ddw_music

    I'd suggest that an even more elegant solution is to generate the random index such that the undesired values are never produced in the first place.

    If you maintain a list of enabled indices, then you could choose randomly from this list, adding and removing available indices based on the toggles.

    I'm not at the computer right now, but I could build this in a little while.

    It's one of those cases in programming where formulating the problem in one way ("blocking output") biases the mind against other solutions ("constraining the random choices").

    hjh

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!