I am interested in implementing something like THIS:

http://www.hisschemoller.com/

in PD.

I know how the algorithm works on paper, but I can't figure out how to get started coding it.

This website:

http://ruinwesen.com/blog?id=216

give a little more info on how the algorithm works (especially in the PDF he links to, page 2 has the relevant example), and talks about coding the thing in Lisp, but i can't figure it out in PD.

any hints?

Could you please upload the patch? I'm curious about how you implemented the algorithm; can't quite figure out an easy way to do it. If you did it with lists I would prefer that to the matrix solution in order to keep it vanilla. thanks

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

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

hah, i spent ages coming up with a version in PD that worked by interleaving lists and this just blows it away. I tried to work out a simple/elegant way of doing it using the basic maths but couldn;t get my head around it, well done for doing it

Well, to be fair, my first attempt at an abstraction for this took the same list-based approach as everyone else's, and was probably much sloppier and messier, too. In fact it was such a tangled mess that I breathed a sigh of relief when I was able to delete it from my hard drive just now.

I completely forgot about this post. It is funny today to see how the patches turned from quite complicated to that simple. And very interesting, indeed.

Thanks for posting this. It had been on my to-do list for a while, and I wasn't really looking forward to it.

That is slick. My own implementation was list-based, and it was truly shit. Thanks!

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...)

Thanks for this - amazing little patch! Can't wait to try it out.