@jorbecke I am not qualified to opine on your mental health, but if you are referring to the hurleur links going nowhere, then it might be a Google Chrome thing. Is that what you're using? If so, try another browser. Otherwise I'd have more modest expectations of a 13 year old thread

@y0g1 My friend who uses Max/MSP just explained to me that phasor~ resets when the right input signal changes to a non-zero value, which means that in my fexpr~ version the test should be "$x != 0 && $x != $x[-1]"

Edit: argh, I even misunderstood my friend. @lacuna is correct below--it's when the signal changes to a non-zero value from zero

@y0g1 said:

"phasor~"'s phase is reset when receiving a non zero signal.

If this was a test in college I'd be there during office hours arguing that the question was misleading

@y0g1 Assuming the sample frequency is 44.1khz, the phasor frequency is fixed at 1, and you don't need to support any other feature than what you mentioned above, try [fexpr~ if($x != 0, 0, ($y + 1) % 44100)] to replace both the phasor and following multiplication.

@playinmyblues The object named a12 should be an array, not a canvas. Replace it and things should start working.

@y0g1 said:

How would you adapt metronome timer for getting the difference between 4 consecutive "onsets", then reset the sample counter to be ready for the next 4 onsets ?

Ugh, in audio domain? I dunno but off the top of my head I think it would be nasty/not worth it. Can't you just take a stream of timing intervals in control domain and process them in groups of 4? How you would align each group of 4 isn't obvious to me either, which is what I think @ben.wes was alluding to earlier RE "cooldown period". Edit: maybe [fexpr~] could help.

@y0g1 I'm unable to test, but your patch looks like [fluid.ampfeature~] and [fexpr~] is supposed to be outputting 1 when the signal is above some threshold and 0 otherwise, is that correct? Is it working as you expect?

If so, the only thing you need from my patch is the part that extracts the leading edge as a pulse, inverts it, and then counts the samples between pulses, but if the signal out of [fexpr~] isn't clean (i.e. outputs one and only one contiguous block of 1s for every drum note) then my counter will output junk. That's why I was asking about [lop~] and threshold in my patch, which is what I assumed you were using for signal conditioning, e.g. for novelty metronome sounds I had to adjust them to get clean square pulses.

@y0g1 What value are you using for the threshold? What frequency are you using for [lop~]? Can you please post a recording of several snare hits?

@donnerbono Yes, and you can even change the array at the same time, but one action, either the read or the change, will come first and will therefore make things sound differently. It's not obvious to see which will come first, which is a dead horse I've beaten previously

@y0g1 The formula for [rzero~] in help means "the output is the difference between the current input and (the previous input times the current coefficient)." Since the coefficient is always 1, it's just the difference between the last two inputs. So since the input is just a square wave toggling between 0 and 1, the output is going to be 1 on the rising edge, -1 on the falling edge, and 0 otherwise. By clipping it to 0..1, I just take the rising edge pulse.

"Convert to negative pulse" means instead of sitting at 0 with the occasional 1 pulse, it now sits at 1 with the occasional 0 pulse.

The formula for [rpole~ 1] in help means ""the output is the sum of the current input plus (the previous output times the current coefficient)." When both the input and coefficient are 0, the output is 0, and when they're both 1, it increments by 1 each sample (i.e. counts samples).

By now you probably know how to understand the formula for [rzero_rev~ 0], let me know if you don't. The reason you need it is so that [samphold~] grabs the highest previous count, not the reset value.

@y0g1 David asked all the questions I would've asked and now I get the benefit of added clarity . I wonder if this thing I made for @eeight has any useful ideas for you, especially the stuff up to the [rzero~] and [clip~] inclusive? https://forum.pdpatchrepo.info/topic/13739/sync-in-ms-between-2-audio-signals/6

Maybe if you just take the impulses on the leading edges and compare their timings (uh, somehow), that will give you the info you need. I'm hand waving because I don't know how you'd determine which impulse was first.

Edit: I think the premise of your project is that the sound of the bead of the stick hitting the batter head is dominant. I wonder if that's true for a snare drum.

@JuanMadrid Powers > 1 make the curve start out more slowly on the way up and more quickly on the way down. Powers between 0 and 1 do the opposite.

@JuanMadrid Here's a demonstration of what I suggested to you earlier.
adsr test 2.pd

@JuanMadrid Maybe use a 2nd [vline~] to sequence the exponent? I think you might have to do something similar to adjust the transition to/from the sustain level.

@lacuna Well, I blame you for my continued, irrational curiosity . I usually don't care about efficiency and care more about code clarity, but your original proposed solution intrigued me because it was both arcane and minimal. Plus I'm not even sure how to implement something like motex/shuffle in normal imperative textual languages like c or Java (which is how I think, even when patching).

Thanks for the links, I'll check them out later.

@lacuna, so as not to junk up @Dizzy-Dizzy's topic, I wanted to continue investigating in a new topic. For some reason I woke up this morning with the realization that your [array random] strategy (and therefore my version of it too of course) doesn't guarantee complete n-element permutations--it only guarantees that there are no successive repeats within any rolling window (which may be what @Dizzy-Dizzy wanted, which is another reason to start a new topic). I think that [array random] strategy only works if you are successively removing elements from the pool until it is empty.

Check out this test of your most recent version:
1776427700402-randompermutations2.pd

You can see that the permutations after the first two aren't complete. Maybe that wasn't your requirement?

@jamcultur Yes, right click on any message and choose help. Look at the bottom left. Also click on [pd dollar-variables]

I don't quite understand @Dizzy-Dizzy's issue description, but I did notice that @lacuna's patch doesn't generate complete permutations after the first one. I think you have to add the excluded # back into the pool at the right point. Sadly, my way of doing that significantly spaghettis-up the patch, but maybe someone can find a simpler way to do the same thing.
lacuna permutation wo repetition.pd

I also wonder if it's not the worst idea to just generate random permutations and simply throw out the ones you don't like, e.g. ones that start with the same # as the end of the previous permutation. I've done that in my own work, especially when I think the sound is more interesting than the programming.

@lacuna Clever! That [t f b] is doing all the work!

@arseniy Maybe this will give you some ideas (I see that I left the knob part out, but you can probably figure that out)
tableToSliders.pd

I guess the key idea here is to set each slider's receive symbol to something that you can iterate on since you can already iterate on array values.