Hi all,

I'm looking for a well done patch for midi Euclidean rhythms generation, with the possibility to vary steps, pulses and offset.
Thanks for any advice.

[I use Purr Data on Ubuntu 18.04]

a.

Mike Moreno has made these Euclidean rhythm things based on the Stutter patch I think...
https://github.com/MikeMorenoDSP/mian-
https://github.com/MikeMorenoDSP/Euklid

or here in the 'sequencers' folder
https://github.com/MikeMorenoDSP/pd-mkmr

@beem said:

Mike Moreno has made these Euclidean rhythm things based on the Stutter patch I think...
https://github.com/MikeMorenoDSP/mian-

Thanks, at the link above the patch that interests me is:
eucgui-help.pd

But I don't know how to use the [midirealtimein] object, there is also no help file: connecting an external keyboard and pressing some keys nothing happens, not even when printing with [print( from outlets.
What should happen?

(I specify that [notein] object, for example, works correctly with my midi keyboard.)

Anyway I tested the patch by putting a metro and works fine.

[I use Purr Data on Ubuntu 18.04]

a.

@atux Do a google search for...... pdpatchrepo midirealtimein
It is easier to search this forum like that than through the forum itself.
You will find some help and a few patches, plus some info about more complex problems with iac and active sense etc.

Also @noDSP made this a while ago and I imagine the control values are the same as those you should receive on the left outlet of [midirealtimein]
midirealtimeout.pd

David.

If you follow the algorithm in http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf, E(5,13) = 1001010010100, But if you use the much simpler one from @Stutter you get 1001001010010. Yes, they are the same if you ignore rotation, but in normal musical practice nobody would say they are the same--they'd say one had flipped the beat (or something). Sometimes the algorithms agree; both algorithms output the same pattern for E(3,8).

[1] Is there a base rotation for Euclidean rhythms?
[2] For arbitrary E(k,n), what is the offset between these algorithms?

@jameslo well in the paper they ignore rotation a bit also in that they consider the algorithm to stop when the remainder is 1
I doubt @Stutter is checking the forum anymore unfortunately, maybe someone can re-derive thons work..

@jameslo said:

If you follow the algorithm in http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf, E(5,13) = 1001010010100, But if you use the much simpler one from @Stutter you get 1001001010010.

If you flip stutter's result three digits to the left you get banff's. It's a matter of a [- 3] somewhere.

some more insight might be found here https://paulbatchelor.github.io/sndkit/euclid/

I put this vanilla patch with very lightweight drum sounds together recently-ish - it wouldn't take much to add midi in/out for it https://github.com/dr-kd/eucalyd

ELSE has the [else/euclid] abstraction

just use different counters to trigger a line~ to create a different envelopes for different oscilators, or even buffers. another thing which you may effectively need to do is to, within certain regard, to adjust the length of the counters. but that shouldn't be difficult to be made. in ableton live and m4l, there are already a bunch of devices with such an approach. in pd, you may need this, and you may need a few further things,but the basic foundations are those. please note that in the case of the buffers, the only thing you may need is a message triggered by the counter. what about using the zl object combined with a uzi, to generate different list streams, in order to generate complex idm patterns

I have this one (Windows only)
```