Here an Euclidean Step Sequencer VST, testing dynamic patch using Camomile (thanks Pierre Guillot). It works!

Hello, I am a beginer and I found a very interesting patch that can feet almost exactly what I want to do.
The only issue is that I am currently limited by my knowledge to change its input. The patch is supposed to generate a euclidean rythm from a midi input. I would like to skip the midi part and to generate those rythms with simple click sounds.

Here is the patch with a couple of comments.
Thank you very much for your help.

@Jona Nice sequencer! I couldn't hear the sound because I don't have [Additiv-syntes] abstraction. I think one would be able to easily create some interesting polyrhythmic sequences using them.

yo... i totally forgot about this thread after i posted that video.

since doing that video i have lost my original patch, and cant really remember exactly what the patch looked like but the math was simple (not as simple as stutter's)

sorry i forgot all about it.

in other news, the IOS app 'figure' is using a euclidean algorithm to produce its percussion (i think...)

Hi all,

Just bumping this thread as I discovered a MUCH more elegant and simple implementation of the above.

I had a faint feeling from the start that the implementation of the algorithm as presented in the seminal paper on Euclidean rhythms, although easily comprehensible and human-readable, wasn't actually a very sensible implementation for computational applications - especially since Euclid's algorithm as it exists in mathematics is just a recursive numerical method for performing division and calculating remainders. Given that computers are pretty nifty with dividing and remainders already, I thought, they ought to be able to cut to the chase and get the results much more easily than that.

Today I finally sat down to some pen-and-paper work to try and figure out what simpler way there might be to implement the algorithm, and I suppose my intuition turned out to be right, as I managed to distill the whole thing down to a handful of operations (and without needing to pregenerate a list, either!) Behold:

[inlet]
|
[+ A]
|

• |
  [% C]
  |
  [< B]
  |
  [select 1]
  |
  [outlet]

does the trick, where integers B and C are the desired number of hits per 'bar' and the total number of beats per 'bar', respectively, and A is the 'rotation' or 'offset' applied to the rhythm. Then you feed the [inlet] with a metro-powered [f ]x[+ 1] counter, and you'll get a 'bang' out every time the drum should trigger. Have attached an abstraction which performs the same.

Would have preferred to get this out back when there was a lot of buzz surrounding the Euclidean algorithm so that more people might've seen it, but I guess it's still better than nothing. Also, forgive me if this is all old news and has already been figured out elsewhere!

http://www.pdpatchrepo.info/hurleur/euclid.pd

I do a lot of algorithmic composition. Usually there's a fairly rapid [metro] as the master clock, and I divide it with various counters. It's easy to make polyrhythms this way. These drive different sequencers that do something or other. Usually I'll record each part to its own .wav file and arrange it with a DAW, export and then reprocess through Pd for effect processing. Or I'll make some chaotic or drone patch and just record some length of that, and arrange later. I never really do "one patch per entire piece". It's too much of a headache.

Hello everybody:
I tried to learn about the implementation of that algorithm but got sort of lost inside the guts of euclidean.pd, so I went through G. Touissant's publication and made something like that using a table and lists, as @sebfumaster was asking for.
As far as I could read in a PhD Thesis (Musical Rhythms in the Euclidean Plane) from Perouz Taslakian, a student at the same university as G. Touissant, the original patch uses two different algorithms depending on the proportion of hits to remaining rests. The matricial approach is adequate for that but quite troublesome (IMHO) in pd. If your amount of hits is less than the amount of rests (k <= (n-k)) it goes somewhat like this: It consists in putting a whole bar like this on the first line, for instance:

n=8, k=3
22211111 (twos are hits and ones are rests, the rest of the empty matrix is zeros)

Then you begin moving the remaining ones one row below the twos, which stay on first line, and moving what remains at the second line "out of the shade" of the previous line to the third one:

222
11111

... until you have a pack like this:

222
111
11

Then you start reading column wise and from left to right, obtaining:

21121121

where: '211' comes from the first column, '211' from the second and '21' from the third one.
The method for more twos than ones is something alike but with slightly different rules.
I saw that for this second condition the answer is the same if one inverts twos and ones and reverses the bar, then solves it using the first method. After that one must invert again and reverse. For instance:

k=3, n=5:
22211 -> invert -> 11122 -> reverse -> 22111

Solving in a matrix:
22
111, etc...

...until:

22
11
1

Read columnwise and from left to right: 21121
Then reverse again: 12112 and invert: 21221.

I found that euclidean rhythms can be made by using a table, putting the starting vector in the same manner and reading it in an alternate way, using division reminders to find out the pointers to the table. Well it's done like that in my patch and it's very easy to follow. However, the rhythms are not exactly the same as euclidean.pd patch gives but since phase shifted euclidean rhythms are equivalent, it doesn't matter to me at least. No matrix button this time.
I think that with not so much work you can turn it into what you are looking for.
Thank you very much @kyro and @mrcold to introduce me to this. It has been something I was going to need soon.

Sumidero

PD: I appologise for the extension of this post

http://www.pdpatchrepo.info/hurleur/euclideasy.zip

Here's my implementation with a matrix. It outputs a list of 1's and 2's for weak and strong steps respectively.

http://www.pdpatchrepo.info/hurleur/euclidean.pd

thanks, that actually helped in a different way. a follow up: is there a way to square or use other exponents in [expr]? I'm basically trying to code Euclidean distance formula in one [expr] without having to use [pow 2] and [sqrt] (the latter of which I know I can use in the formula as sqrt(x)). What I think all of this should look like:

[expr sqrt(pow2(abs($f1 - $f3) + abs($f2 - $f4)))]

Getting hung up on "pow2" part

It just occurred to me that maybe there is already an external that does this and I don't know about it.

thanks,

hdez

http://www.pdpatchrepo.info/hurleur/euclidean-distance.pd

Are there Pd Objects for vector translations? Do you mean a matrix translation? What's the diff?
For the unitiated: Vectors used by graphics software are usually 3-dimensional datatypes which describe location as a coordinate vector(that's the XYZ ), or a euclidean vector: usually represents acceleration, velocity or somesuch. There is sadly no 'vanilla' public vector object in Pd(that I've found), making 'from scratch' particle generators and physics impossible.

I'm no linear algebra ringer, so please correct me if you can.

I'm assuming that the rotation and translation objects in GEM are essentially matrix math objects, affecting the current location vector of the Gl chain (the GEM chain, basically). When you create an instance of [translateXYZ x y z], you are applying a translation matrix:

1 0 0 x
0 1 0 y
0 0 1 z
0 0 1 1

Check it out on wikipedia for all the hairy details.