27 comments

[ 3.9 ms ] story [ 109 ms ] thread
I love the idea, but it looks less-than-ideal to "play" it live. I watched the first video and you can see the handler struggling to place & adjust notes.

Why not have the scanner sweep across a stationary circle? Not turntable enough?

I think the scanner is less precise if it moves instead of reading as a fixed arm
You're right. The turntable would have a lot more angular momentum. It has to be easier to maintain precise RPMs.
Scanner does not have to move though. Just taking an image and analysing that could work. Maybe from underneath. It would be nice to have large surface without strict grid to play around placing the objects.

I get the turntable reference, but if you can’t scratch it’s sort of pointless form.

I also noticed in one of the demos that it his a wrong note:

https://youtu.be/dYloQf7h0QY?t=60

I suspect if you're not in a well lit room with cool white lighting, there might be issues with reading the correct note.

If you're in a stage setting with flash lights all across the spectrum, it might really struggle to distinguish the notes.

Fun little device though! Could certainly see it in a science museum or hands on art exhibit.

One reason is so that the person controlling it doesn't have to be careful to time their hand motions to avoid colliding with an object rotating above the surface.
Obviously. I just think avoiding the arm is easier than trying to precisely move one of those tokens a few degrees around a rotating surface.
You need to have two, a soundmixer and a DMC turntabelist.
I was kind of hoping the inner orbitals rotate faster than the outer ones, with the rotation speeds in some "orbital resonance" whole-number ratio.

That would be a more complicated device, but maybe there's a reasonable way to do it with timing belts or gears.

That was exactly my first idea - have multiple of these in different speeds to create polyrythms.
A tangent but to anyone reading who isn't familiar, that would be a type of what's known as a Euclidean sequencer (after [0]), and a mechanical one would be awesome but there are some great electronic and software options. Lately I've been messing around with HY-RPE2[1] which I like for the most part; although I would like a bit more flexibility it's still powerful (and limitations breed creativity, as they say).

[0] http://cgm.cs.mcgill.ca/~godfried/publications/banff.pdf

[1] https://hy-plugins.com/product/hy-rpewin-mac/

I also recommend checking out an app called Fugue Machine. It isn’t laid out in a circle but functionally is in this same vicinity. Simple, approachable, and fun (and does MIDI).
Two repeating drum beats running at different speeds isn't quite the same as a Euclidean sequence. (The latter is probably more musically useful.)
That's a good point, I was just kind of assuming the related periodicity which is not a valid assumption to make. But the parent of the post to which I had replied specified whole number ratios between the periods.

Euclidean sequencers can be useful though in that they model a variety of common rhythms, and with tempo synchronized delay they can give forth a whole lot more common rhythms. Though nothing that can't be achieved a million other ways like anything else with music.

Whole number ratios isn't enough to make it a Euclidean sequence; the main thing is that the timing is quantized and events are sped up or slowed down to fit the quantization. So maybe you have 16 beats in the sequence, and some rhythm that happens seven times per sequence. 16 doesn't evently divide by 7, so you get a pattern that's slightly irregular.

Suppose this device had different speed orbitals and implemented some more sophisticated logic like, "if you see a green dot then don't trigger the beat then but hold it back until you see a red dot" then I think you could get behavior that's more like, but not quite the same as, a Euclidean sequencer.

Thanks for taking the time to explain! I got a bit mentally off track I guess, as the additional complexity for all this comes in when the user places tokens in the circular tracks to program rhythms. A euclidean sequencer forces them to be at that quantized equidistant approximation and slightly irregular pattern, which serves as the basis of so much music. But IMHO I haven't really found a way to turn that "theoretical purity" into something practically useful, and I always find myself wishing I could make non-euclidean sequences with it and abuse some of the same abstractions for other purposes.
But it is spinning! Fun DIY weekend project, but crazy that someone has guts to push this into mass market product.

Could use CCD sensor from old scanner for high res version.

OpenCV this with webcam and python script, but no spinning.

Computer Science departments should be supporting this project to buy this gadgets to teach students sensor inputs and event driven designs.
Neat, although it seems that bass should be redder and treble should be bluer to match color/sound frequencies. It kinda does that but not quite.
fyi there's a typo — "press realease" in the top-right corner