To round off the recent wave of teensy based DIY drum machines, here's my take on the subject, the polaron (one can never have too many drum machines). The project is driven by my curiosity to understand and experiment with interaction patterns on digital musical instruments and how to achieve playful workflows that foster experimentation with sound and yield surprising results.
The polaron is a circular 16 step, 6 track digital drum machine and it combines features from other drum machines that i know and love (e.g. parameter locks / ctrl-all style editing of the elektron machinedrum) with some unique new features that i found useful while developing the polaron (e.g you can switch patterns for each instrument track individually).
Thanks Paul and everyone involved in making the teensy so awesome for audio projects. Working with the audio-library really was a breeze and almost feels like patching a modular synth.
Last edited by a_guy_called_tom; 11-22-2018 at 03:47 PM.
Reason: embedded video not shown
The PCB/hardware works fine for me (but i'm not a electrical engineer, so there might be things a pro would do differently). There is an annoying ground loop, when the polaron is powered via Laptop USB and the audio goes back into the laptop via soundcard. I don't think i can do much about this, apart from trying out one of those audio ground loop noise isolators. The software also works fine, timing of the sequencer is fine and i haven't had any crashes. But the software is still in constant development, the sounddesign might change, features might be added, changed or dropped. So no major blockers IMO, just an evolving thing (which is why its fun)
ok. one other thing i noticed, (and i'm not an e.e. so if there is an obvious valid reason for this i would not know), is the teensy/chip sector is flipped in relation to the rest of the board and was wondering why? also, is the bare pcb something you have extras of at this time you might want to sell to interested parties to increase testing? thanks.
The main reason for putting the chip and shiftregisters on the back is of aesthetic nature, i didnt like the green pcb of the teensy combined with the black of the main pcb. Secondly, i want to keep the front as flat as possible, so that its possible to put everything behind a faceplate or even inside a case. Also it is possible that the space above the teensy on the front might be used for other user-interface elements in a future iteration of the pcb.
i only have 4 extra pcbs at the moment, and need around 2-3 of them for myself, but if you're interested in the last one, please send me an email with your post address (my email is on the github page) and we can probably arrange something. My plan is to order a bigger quantity of pcbs somewhen before christmas.
Thanks, glad you like it! Interesting concept also on the shapeshifter project, love the included breadboard for trying out different sensors! Looking forward to see what people do with it.
Made another video of the Polaron and Blofeld both synced to ableton live. The patterns have been programmed in advance and during the video i'm playing with track mutes and pattern switches and of course the cutoff knob on the blofeld
@a_guy_called_tom
in your github i see that you use the delay function for the step's leds..
but this introduce a latency? is not better with millis()?
I ask you because i have the same problem, i have 2 shift register for the steps led but the leds are lid only for a fraction on seconds without the delay
@a_guy_called_tom
in your github i see that you use the delay function for the step's leds..
but this introduce a latency? is not better with millis()?
I ask you because i have the same problem, i have 2 shift register for the steps led but the leds are lid only for a fraction on seconds without the delay
I use delay() only in the setup function. Its used for a short animation that lights up all leds when the unit its powered on. In the main loop i don't use delay (for reading the shiftregisters i use delayMicroseconds(5), but this is so short, it should not matter in the timing of the sequencer).
The timing/stepping of the sequencer is handled in Sequencer::shouldStepInternalClock(). This method doesn't block the main loop like a delay() call, it just returns false until it is time for the next step of the sequencer.
Ah, ok
I need to check my code because the shift registers that drive the led do not keep the LED lid but only make a very brief (almost invisible) pulse.
Reply With Quote
Originally Posted by urbanspaceman
