Ari Russo
Friday, January 3, 2014
Moved
Sunday, October 21, 2012
HTML5 Spectrum Analyzer: In 3d
Check it out here
Where it used a d3 bar chart before, the frequency amplitude is now represented in changing the size of some classy wood-paneled 3d cubes.
You can use mouse and scroll over the scene itself to orbit the camera around the cubes.
Like the older version, the default audio is some music I made but you can enter any URL or use live input in Chrome Canary. All of the other slider controls are the same too.
3d version on Github
Thursday, October 4, 2012
HTML5 Spectrum Analyzer: Live Audio Input
http://d3-spectrum.herokuapp.com
Click the button that says Use audio input and then click Allow when prompted to give your browser access to your computer's audio input. You can then click Use audio file to switch back to the audio file.
I've also added an intensity control that allows you to juice up the visual intensity without sacrificing volume or accuracy.
Of course, it may not work in your browser:
Is it ever that simple? At time of writing HTML5 live audio input is only supported in Chrome Canary. You need to go to about:flags in the URL bar, and then enable Web Audio Input near the bottom of the list
Spectrum Analyzer on github
Monday, October 1, 2012
Quick Project: D3 / HTML5 Web Audio Spectrum Analyzer
Here it is running on Heroku with some of my music as the example track
http://d3-spectrum.herokuapp.com
And the github page here:
https://github.com/arirusso/d3-audio-spectrum
Increasing the curve setting gives the spectrum a more logarithmic display, traditionally more common for audio spectrum analyzers.
The other controls are pretty straightforward
Enjoy
Updates:
Adding live audio input in Chrome Canary (10/4/2012)
Sunday, April 29, 2012
Quick Project #2: Ruby Methods for Protecting Against Timing Attacks
Breaking with my usual style, Quick Project #2 doesn't necessarily relate to music programming.
Today I came across a nice little article and demo on r/compsci about timing attacks.
Timing attacks are something that I had learned about a few years ago but for whatever reason had dropped from the forefront of my engineering consciousness. In order to bash myself over the head with it (and provide a universal solution), I created Ruby wrapper methods for Object#send and block evaluation that are padded with a fixed timing delay.
Here 'tis, including some basic String comparison examples at the bottom:
https://gist.github.com/2554841
To use it, just pass in a "safe" duration (in seconds) that likely exceeds any possible amount of time it could take to evaluate the code. In the following example I use the greatly exaggerated value of .75 seconds. In the wild, you'll most likely be working in smaller durations
is_match = ExpressionTimer.block(0.75) { "password attempt!" == "my password!" }
When the example is run, no matter how quickly the block actually evaluates, it will always take exactly 3/4s of a second to return. As a result, actual timing information is lost in the ether and can not be gleaned by any outside observer.
Wednesday, April 25, 2012
Quick Project #1: Extract Audio Samples From Online Video
As I get ready to move once again (this time to the Ridgewood/Bushwick border) there's not a whole lotta time for personal projects. Yesterday I decided that I would find a quick one and do it no matter how useless it was.
Turned out, I came up with something that's going to be pretty useful (for me). Last week, a coworker pointed me to marcel's awesome Ruby giftube script which extracts animated gifs from online videos. I've been looking to incorporate more audio samples in my music for quite some time, so I forked his script and changed it to extract audio samples instead of gifs, complete with mp3 conversion.
Here's the result:
Sunday, March 25, 2012
MicroOSC: a Ruby DSL for OSC
Being on my way to the west coast and out of arm's reach of the synths, I've had a few hours to switch gears and put together a quick Ruby gem, MicroOSC. It's a utility and DSL for dealing with OSC messaging.
gem install micro-osc
I applied the same principle to OSC that I applied to MIDI with MicroMIDI: distilling the simplest messenger interface that I could think of.
Unlike MIDI, OSC deals with generic user-defined messages. This eliminates the need for describing different concrete message types, something that added a lot complexity to MicroMIDI.
MicroOSC can function as a server, a client or both. In this example, I'll demonstrate them separately, having the two programs talk to each other over a local network.
Here is a server:
require "osc" OSC.using(:input_port => 8000) do receive("/greeting") { |val| p "received #{val}" } p "Ready to receive OSC messages on port(s) #{input_ports.join(', ')}..." wait_for_input end
Once you have this running, you should see "Ready to receive OSC messages..." in your Ruby console. Switch to another window and run this client program:
require "osc" o = OSC.using(:output => { :host => "localhost", :port => 8000 }) o.out("/greeting", "hullo!")
After running it, flip back to your server program and see “received hullo!”, confirming that your two programs were in fact talking to each other!
Notice that in the second program I didn't use a Ruby block style. Doing it this way would generally be better for live coding, and probably some other scenarios as well.
That's it!
Look for another post with real-world examples, advanced techniques and combining with MicroMIDI soon.
Friday, February 24, 2012
Shift
I'll post here soon when I have anything of note to show for what I'm doing.
Here's a video of me on some hardware synths that a friend posted last year. It sounds somewhat similar to what I'm doing now.
I can never stay away too long; I'm sure I'll be back to grinding out some music tools once I have a few tracks done. Just not enough time for both at the moment...
Wednesday, October 19, 2011
OSC Access: Build OSC into Ruby objects
I've created a Ruby library called OSC Access for binding OSC directly into Ruby classes and objects.
It conveniently wraps a lot of functionality from osc-ruby, handling server/client sharing and management as well as other tasks commonly associated with OSC.
gem install osc-access
All of OSC Access' functionality is available by including the OSCAccessible module into a class. The module gives you a lot of functionality but you'll want to know about these three methods in particular to get up and running
osc_receive
All OSC input is handled by using the osc_receive method. Here's an example of using osc_receive in a simple way:
class Instrument include OSCAccessible osc_receive("/1/fader1") do |instance, val| instance.velocity = val end def velocity=(val) puts "setting velocity to #{val}" ... end end i = Instrument.new i.osc_start(:input_port => 8000).join
When this example is run, the method velocity= is called on all instances of the Instrument class whenever OSC messages for the address /1/fader1 are received.
A couple of things to note here...
In order to enable OSC input, an input port must be specified for each instance. I've done that in this example using the osc_start method but there is also a method osc_input which just takes a port number. You can also add multiple input ports and share ports across various objects. (see example...)
Another thing to note is that val is, by default, the value of the first argument of the received OSC message. (OSC messages can have an unlimited number of arguments). You can modify which arg is used, or pass in all of them, by setting the :arg option on osc_receive.
You can also use osc_receive as an instance method. (see example...) However, more usefully, you can create a Hash map spec of osc_receive calls and pass it to an instance like this:
map = { "/1/fader1" => { :translate => { :remote => 0..1, :local => 0..127 } :action => Proc.new { |instance, val| instance.pitch = val } } } class Instrument include OSCAccessible def pitch=(val) puts "setting pitch to #{val}" ... end end i = Instrument.new i.osc_start(:map => map, :input_port => 8000).join
This kind of approach gives you more flexibility by decoupling the OSC spec for your object from the class -- like a controller and model in MVC.
Osc_receive has a few options:
:translate
There's another difference between those two examples: the :translate option means that val will be translated from a number between 0 to 1 to the analogous value between 0 and 127 before being passed to the code block. So for example if the first argument of the received OSC message is equal to 0.5, val will be equal to 63.
:thru
By setting the :thru option to true, any messages that are received for /1/fader1 are sent immediately to the output (as well as calling the :action block). For example, using the Instrument class from the last example:
map = { "/1/fader1" => { :thru => true :translate => { :remote => 0..1, :local => 0..127 } :action => Proc.new { |instance, val| instance.pitch = val } } } i = Instrument.new i.osc_start(:map => map, :input_port => 8000, :output => { :host => "192.168.1.9", :port => 9000 }).join
As you can see, I also specified an OSC output host and port for this example. If you're ever missing input or output port or host info, your object simply will not perform IO -- it won't raise any kind of exception.
osc_send
Osc_send gives you the ability to output arbitrary OSC messages. The first argument is the address of the message and any arguments after that are the content. Here is an example of our class definition from this first example with output added
class Instrument include OSCAccessible osc_receive("/1/fader1") do |instance, val| instance.velocity = val instance.osc_send("/velocity", val) end def velocity=(val) puts "setting velocity to #{val}" ... end end i = Instrument.new i.osc_start(:map => map, :input_port => 8000, :output => { :host => "192.168.1.9", :port => 9000 }).join i.osc_send("/greeting", "hi!")
In this example, I'm sending a message from both osc_receive's action block and in the main program block after i is instantiated.
osc_start
Osc_start starts all of the OSC servers that are connected to your objects. You must call it on an instance before osc_receive will function.
I'll be adding OSC Access to Diamond and coming up with a way to use it with MicroMIDI in the next few days. Thanks for reading.
Monday, October 3, 2011
Selecting a MIDI Device With Unimidi
There are a couple of recent changes to how MIDI devices can be selected with Unimidi.
Prompting the UserThe first is the addition of a handy console prompt that asks the user to select a device and waits for input. The code looks like this
require "unimidi" @input = UniMIDI::Input.gets
on my computer, this results in
Select a MIDI input 1) IAC Device 2) Roland UM-2 (1) 3) Roland UM-2 (2) >
Note that when the user makes a selection, the device is returned enabled so you don't need to call @input.open on it.
Hard CodedThere's also been some changes to how hard coded selection can be done. As with the user prompt, now you can select and open a device at one fell swoop. Here's a couple of examples which both open the same output. (Device#use and Device#open are the same)
@output = UniMIDI::Output.open(0) @output = UniMIDI::Output.use(:first)And of course, you can select and open the device separately if you wish
@input = UniMIDI::Input.all[0].open @input = UniMIDI::Input.first.open