If you want to draw a line, say, from (0, 0) to (13, 5) by setting values in a pixel buffer (with no anti-aliasing) you have the same problem.
The classical solution (Bresenham's algorithm) is basically to draw pixels in the direction of the longer axis (in this case the X axis), adding a fractional increment of 5/13 to an accumulator to represent the subpixel movement on the shorter axis (in this case the Y axis). When the accumulator exceeds the threshold, you move a pixel on the short axis and subtract 1 from the accumulator.
You can equivalently start the accumulator at 0.5 with threshold of 1, for an accumulator range of [0, 1], or start at 0 with a threshold of 0.5, for a range of [-0.5, 0.5]. Instead of tracking the accumulator directly, you can track the product accumulator*13, which lets you use all-integer arithmetic.
The explanation based on Bjorklund's algorithm seems less intuitive and more convoluted than one based on Bresenham's algorithm.
I also don't really see the connection to Euclid's algorithm.
In one sentence: Most "interesting rhythms" are integer approximations of repeatedly adding a fraction.
I have an irrational aversion to sequencers so I've been working on rhythm synthesis using oscillators to build a drumming robot.
early prototype: https://www.youtube.com/watch?v=zeHJXyyhJ70
Rather than operating on preset sequences, I'm using a series of oscillators in Puredata that can have their frequencies set to various ratios of a primary frequency. The oscillators get added together and a drum hit is triggered on the zero crossing of the result. The patterns can be modulated by changing the amplitude and phase of the oscillators in realtime. The early prototype was made in Puredata but now I'm trying to put all the rhythm synthesis into the robot microcontroller using the Mozzi library.
I'd love be able to initialize the oscillators with these Euclidean patterns and then be able to modulate them using the oscillator controls. I'm curious if any one knows of a way to take an existing drum pattern and calculate a small series of sine waves that would express that pattern. Kind of like FFT but for rhythms. This seems like something someone might have already figured out.
I really like this. It feels musically coherent in a way that's far better than what I'm used to hearing in other non-euclidean approaches. Typically other people's attempts are unpredictable and lack a coherency or internal logic to their development that ends up making them feel "random". Your example manages to keep an underlying rhythmic motif going that helps glue the whole thing together. It all feels very Autechre. Congrats.
Could you discuss the example in the video a little more? How much are you "performing" and changing the phases and amplitude of the oscillators in this example? Are you tweaking them steadily, or are you able to leave the system to run by itself and let it's "emergent" rhythms occur naturally?
I'd love to know much more about this, as I'm also pretty disenchanted with sequencers these days and am searching for a better way to generate systems like this. Great work.
I don't totally remember what I did in that video, but I would have set up some ratios on the oscillators, and then shifted the amplitudes and phases a bit.
Here's a copy of the Puredata sketch https://stefanpowell.ca/project/Robodrummer/drumming_v4.zip
I'm not sure if anything in there makes any sense. I'm not a drummer. I can't drum. I feel like my body has a palsy that completely prevents me from being able to keep a rhythm, so this is why I'm working on this drumming robot project.
For this sketch I'm using a Korg Nano Kontrol v1 with an abstraction to hook connect the knobs and sliders to Pd, and then I abstract it further to turn the sliders and knobs into floats. This patch, and variations on it, have been serving as a mental sketch board for thinking about rhythms. The output can be used to trigger a modular synth using L/R channels, but I'm using it to send OSC commands to my drumming robot. I'm not sticking with this setup because I don't want to send the individual hit instructions over the network, rather I want to only send parameter changes.
Yes, this approach can generate some interesting emergent patterns especially when you play with the ratios like using something very slightly off and then you get phasing patterns.
My general goal is to make an autonomous drummer that will jam my other autonomous instruments.
The claim that "almost all of the most important world music rhythms are Euclidean rhythms" requires some serious cherry-picking and arm twisting. I would agree on much weaker claim that all Euclidean rhythms can be recognized in world music, but then most of random arrangements on 8 and 7 grid will sound familiar after couple of repetitions. Humans are just good at recognizing rhythmic patterns.
The paper that the notebook is based on goes in fascinating encyclopaedic detail, with the math and music theory to support the thesis. The claim in the paper is closer to yours, that some of the most popular rhyhms in music cultures around the world are Euclidean patterns.
> The Euclidean algorithm (which comes down to us from Euclid’s Elements) computes the greatest common divisor of two given integers. It is shown here that the structure of the Euclidean algorithm may be used to automatically generate, very efficiently, a large family of rhythms used as timelines (rhythmic ostinatos), in traditional world music. These rhythms, here dubbed Euclidean rhythms, have the property that their onset patterns are distributed as evenly as possible in a mathematically precise sense, and optimal manner.
ive been fascinated by euclidean rhythms for the past 10 years or so, and while playing with the pattern ended up coming across a more general flexible abstraction built upon euclidean rhythms that can generate every rhythm, which ive laid out over at https://github.com/clumsycomputer/clumsy-math#recursive-eucl....
euclidean rhythms are also great for generating / selecting musical scales and chords among other things
No good discussion of Eucridian rhythms ends without bringing up the Buchla 252e Polyphonic Rhythm Generator, so here's a demo for the uninitiated: https://youtu.be/iekVNSaXPz8
Buchla had a lot of neat modular instruments along the same lines as this one, definitely a rabbit hole worth falling into if you haven't already. Now I just hope that Uli Behringer hears my prayers and designs some Buchla recreation modules.
The king of Euclidean rhythm hardware sequencer (MIDI/CV) is still the Squarp Pyramid[1] to my knowledge. Some crazy stuff you can do. Sold mine a few years ago as you really need training and muscle memory to get the best out of it though...
> Sold mine a few years ago as you really need training and muscle memory to get the best out of it though...
Me too, for the same reason, so I’m not sure it’s quite right calling it the ‘king’ of Euclidean rhythms. There’s plenty of others that do pretty much the same as the Squarp that aren’t as frustrating to use.
I like Torso T1 [1], and a variety of Eurorack modules I have, like Euclidean Circles, Metropolis, Eloquencer, amongst others.
I never thought I'd see the issue of pulse selection in spallation neutron sources referred to on HN, let alone linked to music theory. In practice, most systems that select a subset of these pulses will select 1 pulse in every 2^n pulses, so fancy patterns aren't needed. But I work at a facility where 1 in every 5 pulses are removed in order to supply another part of the site, and where the particular instrument I work with uses 1 in every 2 or 3 pulses. At the moment, the selection of 1 in 2-3 pulses is accomplished with a spinning disc ('chopper') with a hole in it, to let though the required fraction of pulses. But the spin speed of the disc must generally be constant once set, meaning sometimes it lets though one of the missing 1-in-5 pulses that were already diverted somewhere else. We would need a better switching method to let through arbitrary irregularly spaced patterns of neutrons. I think I worked out once that it could offer the most advantage when running in our 1-in-3 mode.
The article says "they have the property that their onset patterns are distributed as evenly as possible", but their appeal seems to lie in the fact that they cannot be distributed completely evenly, on account of the number of onsets and the number of steps being coprime integers.
Euclidean rythms are well supported in the Tidal Cycles family of live programming environments. Here's a demo that you can play with online: https://strudel.tidalcycles.org?fTGy0eTiAUox
Cool - this is sort of reversed for me, it's using the Euclidean algorithm to illuminate the structure of traditional rhythms, but I'm very knowledgeable about the latter and have never studied / have forgotten the former, so I've just learned the Euclidean Algorithm by drumming on the table..
function eu(index,length,beats,offset)
return b2n((((index + offset) * beats) % length) < beats)
end
function euquence(length,beats,offset)
local l = {}
for i=0,length do
local r = eu(i,length,beats,offset)
table.insert(l,r)
end
return table.concat(l,’ ‘)
end
Relax. Complaining about down votes is both against the rules and a waste of your time. Don't worry about it. You might feel like your initial contribution was highly relevant and insightful and you might be right, but you're up against countless others who disagree, of whom a very very tiny few have decided your contribution was in fact not relevant or that it violated some other etiquette. It's OK. Rather than get riled up about how your message was received, instead consider how you might refine it for the future.
The classical solution (Bresenham's algorithm) is basically to draw pixels in the direction of the longer axis (in this case the X axis), adding a fractional increment of 5/13 to an accumulator to represent the subpixel movement on the shorter axis (in this case the Y axis). When the accumulator exceeds the threshold, you move a pixel on the short axis and subtract 1 from the accumulator.
You can equivalently start the accumulator at 0.5 with threshold of 1, for an accumulator range of [0, 1], or start at 0 with a threshold of 0.5, for a range of [-0.5, 0.5]. Instead of tracking the accumulator directly, you can track the product accumulator*13, which lets you use all-integer arithmetic.
The explanation based on Bjorklund's algorithm seems less intuitive and more convoluted than one based on Bresenham's algorithm.
I also don't really see the connection to Euclid's algorithm.
In one sentence: Most "interesting rhythms" are integer approximations of repeatedly adding a fraction.
[1] https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm