Building Some Red5 Apps (Open Source Flash Development) Part 3

Sending MIDI messages

I created a demo last year that involved Wii remotes, drums rendered in Papervision3D, and a Roland drum module. I used Red5 to send MIDI notes to the Roland sound module to trigger the realistic drum sounds. This was a much faster solution than trying to have Flash Player play MP3s of the sounds of the drums. I was able to play the drums like an electronic drum kit with this setup.

Sending MIDI messages is as simple as this bit of code:


In this code, you create a method called sendMidiMessage, and you pass it note and velocity. To send the message to Red5 to pass along to the Roland drum module, you use The first argument is a String value of the name of the method to call on the server side, and the second argument is the response handler. You have to define a response handler, or you’ll receive runtime errors. The next three arguments are “note on” (144), the note itself, and then velocity. That’s all you need! So for the drum demo, all I did was calculate some velocity value based on how hard I swung the Wii remote and pass that to Red5. This ended up being very fast and responsive, which was ideal for a drum demo. That’s it! The code for getting MIDI messages in and out of Flash using Red5 is pretty basic, and it’s fast.

As promised, here’s the entire code for, which includes all of the previous code samples. Again, this is a singleton with two bindable properties: deviceListIn and deviceListOut.








Flexing your Red5 muscles

A big thanks to Dominick Accattato for putting this Flex sample together; it has been a great learning tool for so many people.

This sample is really a refresher of the simple samples in that it covers live video broadcasting and subscription as well as chat via SharedObjects. The main difference here is that it’s using ActionScript 3 with AMF 3 and is a very nice look at how easy it is to develop for Red5 using Flex Builder.

Let’s look at the main application .mxml file, which is called FITC2007_Streaming.mxml. For simplicity, it’s not using a code-behind, and the ActionScript is right in there in the script tags. Again, this is meant to be a quick sample and easy to understand rather than showing you proper Flex class and component creation and organization. The three components you’ll be looking at all have their code within Script tags in the MXML itself as well.

In the following code, you just need to focus on the two main methods for this demo: onCreationComplete and onNetStatus.

onCreationComplete is called when the application has finished creating its visual assets and is now ready to start doing work. The first thing that happens is that you connect to Red5 through a singleton called ConnectionManager. It has one method you’ll use called connect() in which you pass the URI address to which you want to connect the client. ConnectionManager also has one other method called getConnection(), and its job is to simply return the NetConnection object for use with any and all components that might need to use the NetConnection reference.

The next method is onNetStatus, and here you’re interested in the NetConnection.Connect.Success message. Once you receive that notice, you can go ahead and connect the three components for use with this application. Each of these components has a conn property, and you set it directly on the instances.





The previous code block is the main application MXML, and its main job is to simply create the connection to Red5 as soon as it loads. If it loads successfully, it then sets the conn property for the videoPlayer, videoBroadcaster, and chat modules. At this point, all three modules will be able to communicate with Red5 via this one NetConnection object. I think it’s worth mentioning that you can use one NetConnection for multiple uses.


VideoBroadcaster.mxml is identical to the SimpleBroadcaster.mxml sample. When the broadcast button is clicked, the component attaches the camera to the NetStream object and then calls NetStream.publish() with a string ID and a second argument that tells Red5 what to do with the streaming video it’s receiving, which in this case is live, which means other clients can watch the stream.



VideoPlayer.mxml is identical to SimpleSubscriber.mxml as well. All it does is simply attach the NetStream object to the video container, call, and pass the name of the live broadcast along to Red5. That’s it!



Chat.mxml is the final of the three components for this Flex sample application, and it’s a little more complicated, but not by much. I really wanted to show you the onSync events that are possible when you use a remote shared object with Red5 and you update properties of the data object. The onSync event has a changeList array, and each object in the array has a code property. You check that code property for success and change codes so that you know it’s safe to add the chat to the output window. If either of those codes comes through, you simply access the actual data via the[list[i].name] object reference. You pass that to the output window, and now you’ve just added a chat to the output.





The SyncEvent object will return five possible codes in a changeList array:

■    clear: This means either that you have successfully connected to a remote shared object that is not persistent on the server or the client or that all the properties of the object have been deleted—for example, when the client and server copies of the object are so far out of sync that Flash Player resynchronizes the client object with the server object. In the latter case, SyncEvent. SYNC is dispatched, and the code value is set to change.

■    success: Ifyou have changed a property on SharedObject, this means the client changed the shared object successfully.

■    reject: This means the client tried unsuccessfully to change the object; instead, another client changed the object.

■    change: If another user changes SharedObject or the server resynchronizes, you will receive this event.

■    delete: This means an attribute was deleted.

As a side note, if you want to delete the SharedObject reference from the client in hopes of reconnecting, the help files will tell you to use SharedObject.clear(). I recommend you use this call and then set the SharedObject reference to null:


This completely destroys the SharedObject reference and avoids any problems with re-creating the reference to a new SharedObject. Without it, you may encounter issues with reconnecting to the remote SharedObject.

Links and more

At this point, you’ve been exposed to the sexiest parts of Red5, but that’s just the beginning! I covered video broadcasting and subscriptions, you learned about shared objects and simple chat modules, and you took a decent look at how to communicate with MIDI devices via Red5. You can take these examples and use them right out of the box to get started on your masterpiece application! What was important here was that you got a taste of what you can possibly do with Red5 and start thinking outside of the normal bounds of Flash as a client.

If you’re a Java developer reading this, you probably can’t wait to try a few hundred ideas and sink your teeth right into the server-side API! If you’re a Flash/Flex developer, you’re probably amazed at how easy and fast it is to get up and running with some very powerful functionality. Either way, Red5 is an essential addition to anyone’s arsenal of tools and technologies.

Getting involved in the community is what has made Red5 such a successful project and application. People who are passionate about this type of technology have really kept the project on track and made it one of the best around for providing these types of server solutions for the Flash Platform. In the following links, you will find the e-mail list for the general Red5 users as well as the Red5 developers list. The developers list exists for more technical questions about the code base, while the general list is more for discussion on how Red5 is used.

Next post:

Previous post: