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...)
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:
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!
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:
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:
... until you have a pack like this:
Then you start reading column wise and from left to right, obtaining:
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:
22211 -> invert -> 11122 -> reverse -> 22111
Solving in a matrix:
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.
PD: I appologise for the extension of this post
Perform operations on list without \[unpack\]
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.
Explanation of vector rotation/translation
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.
I'm having trouble to build a patch to measure the EUCLIDEAN DISTANCE between arrays (fiiled w/ audio data). I've started using expr~ to build the: pow($v2-$v1),2) but I couldn't make the 'sum' fction work in order to give the sum of the array N pts.
Attached is a PD patch ilustrating it.... Any help is appreciated,