Hacker News new | past | comments | ask | show | jobs | submit login
Beats Drum Machine (beatsdrummachine.com)
129 points by thmzlt on May 14, 2011 | hide | past | web | favorite | 31 comments



I propose an enhancement (stolen from Roland MRC operating system of yore): instead of a x to mark a note, use numbers from 0 to 9, to allow for varying velocity (0 sending a note-off, useful for many drum effects)


0 to F gives you 16 - it will be easier to use with midi, which has base 2 amount of divisions


I mentioned it because I genuinely enjoyed drum programming on the MC500 MkII; I still think its interface is the fastest and the best for this (not so much for other things :). 10 velocity levels are enough for drums generally.


How about a hex nibble or byte so you don't have to draw individual x's and .'s (this leaves out velocity entirely)


Then maybe add a binary file format for storage efficiency. Give it a standard file extension so we can recognize the files, maybe '.mod'?

Can't wait! We live in exciting times of limitless opportunity! The future is now!


... and that's the story of how come there's only one programming language.


Can't wait till people are composing full songs as a series of YAML files and samples, then publishing them on Github.

After all, there's not a huge amount of difference, conceptually, between remixing and forking!



Interesting. Not really sure how much mileage there is in an XML representation of MIDI, other than as an implementation detail for bigger packages. I'd venture a guess that 'end-user' adoption is low? In the sense of, for example, people exporting as midi-xml from their sequencer to email to each other?

To be clear, I was more enthused with the collaborative potential and the extremely low barrier to entry, rather than with the notion of a text-file-based representation of sequencing. This project seemed more immediate, hackable, 'tactile' in a way, and more shareable than other formats/tools that I know of; although of course much less powerful.


Yeah, MIDI is pretty big and nasty, but most likely the key missing link is user adoption of a non-binary (plain text) format. See also http://en.wikipedia.org/wiki/Extensible_Music_Format_(XMF)


Super cool, this is the kind of neat stuff that happens when programmers have hobbies apart from programming. Love it.


Add the possibility of sub-second timing errors, that way the music will feel more real, as performed by a human.


Great idea, that's an interesting approach. Lay down a score, and play it - truly a 21st century player piano. There's plenty of programs that will do this with confusing graphical interfaces and binary formats, of course. The yaml interface is the best touch.

I'm a musician as well as a programmer, and my favorite mobile/touch apps are the instruments. Now there's one I can play from the command line, too! To the tune of 'scrathing your own itch', my goal is to make an iOS music app or two. I'll definitely be reading the sources for this.


This reminds me of the good old time when trackers like Scream Tracker 3 and Impulse Tracker were the hot thing! They too were programmed by writing sequential "code". This felt more natural and easier to use than most GUIs of that time.


I started off building something like this a while ago (and never got round to finishing it). I like your implementation better.

One interesting feature I had which you don't is polyrythms http://code.google.com/p/drumscript/source/browse/PolyTest.p... which I found quite interesting. Would be cool to see them included in this.


I know it's a no-content comment, but: Thank You. I didn't know I had been waiting for this. But oh, I had :)


This is the author - thanks for the comments! Interested to see what beats people cook up.


This is incredibly refreshing and inspiring, congrats!

I don't see a lot of audio-related Ruby projects around. How did you implement the audio engine? A quick look in the source files seems to show it's all pure Ruby.

A nice extra feature would be to edit/save and update live, while the loop is running, but I don't know if pure Ruby can fit the bill. And this reminds me of a language I've heard a lot of good things about: Chuck [1], which allows you to modify the code live (apparently it's used in Smule's iOS apps). Has anyone here played with it?

http://chuck.cs.princeton.edu


I'm totally illiterate when it comes to music, but I do like electronic music. If you do end up creating something you really like with Beats, please do share the source code. Thanks!


This looks amazing! Going to test it right now!


On OS X:

beats song.txt song.wav && afplay song.wav

Provides really quick feedback. On Linux you could probably just use aplay. No idea for windows?


Trying to imagine Keith Moon hunched over a keyboard, laying out drum tracks... nah, can't do it.


Looks great.

Can't wait for the emacs mode.


Emacs, yea.

Also, perhaps one can modify the program, so that it ignores characters other than period and X.

Then you can run it on regular text files or, alternatively, source code, to get cross-domain puns (text domain, rhythm domain, code domain).


my first though, after seeing this, is to write a vim mapping that will let me listen to a file instantly.


Cool idea.

This is currently the online drum machine to beat, IMO: http://www.soniccharge.com/patternarium


This is not an online drum machine... But if we're going there, allow me to suggest these: http://burn-studios.audiotool.com/app http://seaquence.org/4v


I wonder why set linespacing for pre tag to almost a average char width


That's it, I'm getting the band back together. It's a quartet: vim, emacs, pico & elvis.

Best. Program. Evar.


This is cool but only a toy. I do look forward to a more elaborate version. Maybe an api where you can just feed tracks right in the browser.

Check out http://audiotool.com for a very advanced electronic music composer online.


> Notepad is cool but only a toy. Check out Eclipse for a very advanced IDE.

Apples to oranges?




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: