I know blogging's been light for the past several months. Work here at Almer/Blank has had me pretty consumed.

But, as I gear up and prepare for a busy autumn of talks and courses, you can expect some heavier posting.

First up, I'll be presenting at FITC San Francisco — the first SF installment of the really amazing FITC conferences.

On day one, August 17th, I'll be giving my talk, 'Hearing Pictures with Synthia' — you can see an earlier version of that talk, from FITC Toronto in April, here, and play with Synthia at SynthiaHearsPictures.com.

Then, on day three, August 19th, I'll be giving a talk on 'Getting Started with Adobe Open Source Media Framework (OSMF)' in the 'Adobe Under the Hood' room — a version from FITC Toronto in April you can view here.

It will be an amazing conference, with a ton of great talks. Early bird pricing ends July 2nd, so get your tickets now!

Share and enjoy!

-r

OSMF certainly has features and functionality for hard-core developers to build powerful media-rich experiences. But OSMF also makes basic media player code really easy for those users of Flash who might not consider themselves developers, but who still are comfortable coding on the timeline.

One of the issues with the still nascent, but growing at an impressive rate OSMF documentation, is that almost all the sample code is for users of Flex Builder / Flash Builder — and all of the sample code for Flash assumes use of external class files.

But using OSMF does not require coding in external class files. So, to illustrate that point, I've gone ahead and modified the simplest possible OSMF video player from Adobe's documentation to code that works on the timeline. Which I'm posting here.

So this is code (OSMF Sprint 10 v0.93) you can paste onto any timeline that will play video with OSMF.

Want to make it stream the video instead of playing it progressively? Point it to an RTMP URL instead, and it will automatically play.

import org.osmf.containers.MediaContainer;
import org.osmf.elements.VideoElement;
import org.osmf.media.MediaPlayer;
import org.osmf.media.URLResource;
// Create the container class that displays the media.
var container:MediaContainer = new MediaContainer();
//add the MediaContainer instance to the stage
addChild(container);
// Create the resource to play and point it to the FLV
var resource:URLResource=new URLResource("my.flv");
// Create the MediaElement
var videoElement:VideoElement=new VideoElement(resource);
//add the VideoElement to our container class
container.addMediaElement(videoElement);
//create the MediaPlayer instance
var mediaPlayer:MediaPlayer = new MediaPlayer();
// Set the MediaElement on a MediaPlayer.
//Because autoPlay defaults to true, playback begins immediately.
mediaPlayer.media=videoElement;

Share and enjoy!

-r

ex. PlaylistMediator

package com.project.view
{
	import org.puremvc.as3.patterns.mediator.Mediator;
 
	public class PlaylistMediator extends Mediator
	{
		static public const NAME:String = "PlaylistMediator";
 
		public function PlaylistMediator( viewComponent:PlaylistView )
		{
			super( NAME, viewComponent );
		}
 
		public function get playlistView():PlaylistView
		{
			return getViewComponent() as PlaylistView;
		}
	}
}

As I've worked on PureMVC projects with other developers I've had the opportunity to see different approaches at writing application code in a PureMVC setting. The view getter was a pretty common practice, but as I've seen the way its used, and abused, I started wondering to myself, why? Why is this method necessary? Well obviously, it is necessary to retrieve the view component, without having to cast the type each time its needed. The real question is, why is it public?

The purpose of the Mediator is to listen for events on the view and send notifications to the Controller, and to provide an API to manipulate the view. And to a lesser extent, to listen to notifications that should update the view. However, I am not a fan of this either, and I try to keep notification handling in Mediators to a minimum. But that is beside the point I am trying to make about the view getter. With an API to the view provided by the Mediator I feel like the view getter should actually be protected or private, instead of public.

ex. PlaylistMediator

package com.project.view
{
	import org.puremvc.as3.patterns.mediator.Mediator;
 
	public class PlaylistMediator extends Mediator
	{
		static public const NAME:String = "PlaylistMediator";
 
		public function PlaylistMediator( viewComponent:PlaylistView )
		{
			super( NAME, viewComponent );
		}
 
		protected function get playlistView():PlaylistView
		{
			return getViewComponent() as PlaylistView;
		}
	}
}

Using protected or private enforces that you should manipulate the view via the Mediator's API, and also stops promoting code like this:

ex. PlaylistLoadedCommand

package com.project.controller.command
{
	import com.project.view.PlaylistMediator;
 
	import org.puremvc.as3.interfaces.INotification;
	import org.puremvc.as3.patterns.command.SimpleCommand;
 
	public class PlaylistLoadedCommand extends SimpleCommand
	{
		override public function execute( notification:INotification ):void
		{
			var playlist:Array = notification.getBody() as Array;
			var playlistMediator:PlaylistMediator = facade.retrieveMediator( PlaylistMediator.NAME ) as PlaylistMediator;
 
			var playlistItemView:PlaylistItemView;
			for (var i:Number = 0; i < playlist.length; i++)
			{
				playlistItemView		= new PlaylistItemView();
				playlistItemView.data		= playlist[ i ];
				playlistItemView.x		= 0;
				playlistItemView.y		= playlistItemView.height * i;
				playlistMediator.playlistView.addChild( playlistItemView );
			}
		}
	}
}

And instead, promotes code like this:

ex. PlaylistLoadedCommand – Registered to a notification sent when a Proxy is done loading playlist data

package com.project.controller.command
{
	import com.project.view.PlaylistMediator;
 
	import org.puremvc.as3.interfaces.INotification;
	import org.puremvc.as3.patterns.command.SimpleCommand;
 
	public class PlaylistLoadedCommand extends SimpleCommand
	{
		override public function execute( notification:INotification ):void
		{
			var playlist:Array = notification.getBody() as Array;
			var playlistMediator:PlaylistMediator = facade.retrieveMediator( PlaylistMediator.NAME ) as PlaylistMediator;
			playlistMediator.updatePlaylist( playlist );
		}
	}
}

In this example the Command simply calls the updatePlaylist() method on the PlaylistMediator, which encapsulates the logic required to actually update the playlist. The PlaylistMediator can now also offer this functionality to another application system if it is required later in development due to another action. Perhaps when the playlist is done and a refresh call is made, or if the user manually refreshes the playlist.

ex. In PlaylistMediator…

public function updatePlaylist( playlist:Array ):void
{
	var playlistItemView:PlaylistItemView;
	for (var i:Number = 0; i < playlist.length; i++)
	{
		playlistItemView		= new PlaylistItemView();
		playlistItemView.data		= playlist[ i ];
		playlistItemView.x		= 0;
		playlistItemView.y		= playlistItemView.height * i;
 
		playlistView.addChild( playlistItemView );
	}
}

This was just a small example, where I only showed accessing one mediator. There are instances where a notification might need to update two or three views. Instead of writing 10-20 lines in a Command per Mediator that needs to have a view updated, its much neater and easier to read to simply call a method on each Mediator. This has other benefits other than short code. If you are following some code that you are trying to debug it is easier to understand what happens if a notification is handled directly by a Command, since you will be able to see all affected actors, Mediators, Proxies, in a single centralized location. Listening to the notifications within all the mediators makes it more difficult to find all of the places that a single notification effects, as the example illustrates below. The alternative would be to listen to the notifications in each mediator, and have a command that triggers the proxy method. I think its more maintainable and easier to debug if all notifications go directly to a command. It makes more commands, and its more tedious, but in the end its far more maintainable and easier to debug.

package com.project.controller.command
{
	import com.project.view.PlaylistMediator;
	import com.project.view.MenuMediator;
	import com.project.model.proxy.ApplicationDataProxy;
 
	import org.puremvc.as3.interfaces.INotification;
	import org.puremvc.as3.patterns.command.SimpleCommand;
 
	public class PlaylistLoadedCommand extends SimpleCommand
	{
		override public function execute( notification:INotification ):void
		{
			var playlist:Array = notification.getBody() as Array;
 
			var playlistMediator:PlaylistMediator = facade.retrieveMediator( PlaylistMediator.NAME ) as PlaylistMediator;
			playlistMediator.updatePlaylist( playlist );
 
			var menuMediator:MenuMediator = facade.retrieveMediator( MenuMediator.NAME ) as MenuMediator;
			menuMediator.resetMenu();
 
			var applicationDataProxy:ApplicationDataProxy = facade.retrieveMediator( ApplicationDataProxy.NAME ) as ApplicationDataProxy;
			applicationDataProxy.getPlaylistInfo( playlist );
		}
	}
}

The idea originated from a 1943 Hermann Hesse novel, The Glass Bead Game (also published under the title, Magister Ludi, after the protagonist). The novel focuses around the life of Magister Ludi, who is a member of a monastic-style order at a time in the future.

The central activity of the order is the Glass Bead Game — it is their form of meditation. Although it is the central activity of the order, it is rather vaguely defined over the course of the text. Despite the lack of detail, the game has fascinated me since I read the novel. In the game, a glass bead represents an idea — any idea — such as an historical event, a work of music, a painting, a philosophical concept, anything. When it's your turn, you must play a bead — that is, you must play an idea on the game board. But the idea you play (the bead you place) must be related to the idea (bead) placed by the previous player, thus over the course of an entire game creating a thread uniting widely disparate parts of human knowledge and experience. In this way, being a successful player of the game requires an agile intellect with the capacity to relate any idea to a wide variety of other — seemingly unrelated — ideas. Playing the game well requires fluency in math, music, language, history, art and science.

Ever since I started working with Flash 11 years ago, I'd always sort of envisioned Flash as a mini-Glass Bead Game. The term isn't really used any more, but when Flash was young, it was considered a multimedia tool. And, Flash took the idea of multimedia to a new level — that is, despite its drawbacks, Flash has, since version 4, made it ludicrously simple to work with information of many different kinds. Flash supports character animation, motion design, text, audio, video, images, 3D data, live data, interactivity — Flash basically supports any type of digital information (this is, more or less, literally true with the Flash Player 10 FileReference powers). So, using Flash, we can establish relationships between different types of information (which is what many of the early Flash luminaries did, in one form or another). Hence, my picture of Flash as a mini-Glass Bead Game.

The fact that, especially early on (until Flash 9), the most successful Flashers also tended to be the most eclectic, only strengthened this notion for me. Flash is really the only technology in the world that could give birth to a significant population of designer/developer hybrids (a.k.a., the deselopers), which speaks to the multi-disciplinary nature of the tool and the unique skill-sets that lead to success within Flash.

So, the idea of Flash as a Glass Bead Game kept percolating in my head for years, until I eventually decided to start trying to formalize the notion. The notion of creating a computer program that could translate anything into anything.

But of course, that's an insanely complex endeavor. So, I wanted to find a more focused niche that could serve as a starting point.

Then, Flash 9 came out, with its enhanced sound powers. All of a sudden you started seeing real-time audio analysis in Flash movies — sound visualizers translating sound into pictures. Now, of course, sound visualizers have been around for a while, but now I could build them myself, using the ActionScript code I already knew. And the thought occurred to me to create a machine that worked in reverse — translating pictures into music. Still, even with Flash 9's powers, it was a frustrating go. But, when Flash 10 came out, with the SampleDataEvent, I lost all excuses and picked things back up.

Of course, with the amount of time I've been able to spend on the project, it's not even properly called a 'hobby'. And so, I'm now six months into what I consider to be a 40 year endeavor, and I have a few little experiments to show for the effort. Those experiments — and the thought that went into them — is what my talk at Wednesday's LA Flash End-Of-Year Party is about.

But, that's not what this post is about.

One key limitation of this entire process is that I'm working with digital information. Now, I'm not complaining — the fact that all information is digital is what permits us to execute the cross-modal translations with relative ease (i.e., it's easier to translate a picture into music, if both the picture and music are stored as 0s and 1s). However, working in digital is also a bit creatively limiting. When composing music on the computer, I'm composing from audio information already stored on the computer — more like playing a synthesizer than a piano. Again, that's fine, but I thought it would be fun to start experimenting with analog inputs and outputs (which I can read and control from Flash using my MakingThings Controller Board).

About a month ago, I picked up a copy of Handmade Electronic Music: The Art of Hardware Hacking, which describes, in a series of clearly written chapters, how to go about assembling synthesizers from inexpensive, easily available hardware.

I'm not done with the book yet, but in the early chapters, you learn how to build your own microphones — a few different types, including contact mics, compressor mics — even electromagnetic mics (microphones that 'play' the sounds of the electromagnetic fields that surround the microphone).

When I rewrote the Hearing Pictures presentation this past weekend I found a neat way to integrate one of these piezo contact microphones into my talk. A contact microphone is one that can pick up vibrations in a surface, but not from the air. So, you can plug the contact mic into an amplifier, then hold the contact mic up to something that is vibrating and you will hear the vibration through the amp. They're fun to play around with (you can even hear the sound of metal heating up with these mics).

The simple, cheap (<$1.50) contact microphone that I've built relies on a Piezo disc, or piezo sensor (~$0.75). These Piezo sensors rely on the Piezoelectric effect (discovered by Pierre and Marie Curie in 1880, but not industrialized as a sensor until the 1950s) to convert pressure, acceleration, strain or force into an electrical signal.

You need a:

• Piezo disc
• An amp
• An audio jack (that fits your amp)
• A little bit of audio cabling

Audio cables are composed of two wires.

Step 1) Take one wire and solder it to the outer plate of the piezo disc, and solder the other end to one hookup in the audio jack.

Step 2) Then take the other wire and solder it to the inner plate of the piezo disc, and then solder the other end to the 2nd hookup in the audio jack.

Step 3) Plug the jack into the amp, and start rubbing your piezo disc against things to see how they sound

That's it! You don't even need a battery to power this mic. As you'll quickly see, you can not pick up any vibrations from the air — so it's totally unusable as a traditional mic (read the chapter on building a condenser mic if you're interested in that). But, if you place it on the end of a styrofoam cup, and then speak into the cup, you have a neat Halloween microphone!

If you're interested to see how I integrated this contact mic into my talk, well then, all I can say is, show up on Wednesday. It's free, and it'll be a really cool and interesting talk. (Oh, and there's free beer — did I mention that?).

Share and enjoy!

-r