ArKaos MediaMaster may be the latest baby in the ArKaos video software family but it carries in its DNA all the best features of its ancestors’ different evolutions. These evolutions have always been triggered by users requests, by the different experimentations we made and by the goals we wanted to reach in terms of performance..

A few years ago when we decided to rewrite our core Engine, our goal was to get the best out of current and future computer architecture. So we designed the Engine to allow very creative layer blending with HD video loops by balancing the load between multi-core CPU’s and GPU’s. This was MediaMaster 1.0, then version 1.2 added very cool frame blending and audio support.

So we’ve been mainly focusing our resources on the Engine fluidity to achieve an optimal pixel flow and did not spent too much time working on the interface functionalities. This does not mean we did not care about that aspect but we’ve been really too busy with our hands dirty with pixel processing in order to build a perfectly stable and fast Engine that would become a solid base for further features and developments.

But we’ve also been listening to users feedback from everywhere, whether it be online  - on the support portal, in the forums and on our social networks – whether it be in real life - at trade shows worldwide or through a round of meetings and design sessions with lighting designers and resellers that we organized in January.

In other words, we were virtually behind you – yes, you! :) – looking above your shoulder at how you’re working with MediaMaster and how you’ve been using ArKaos VJ DMX in the past so we can understand how to make future versions working exactly the way you like, the way you need.

That’s how we came to realize that a typical lighting designer needs something like a Swiss Army Knife for video. No gig is twice the same; some days you just need to do a little bit of MIDI triggering, other days you may want to use a few DMX sliders to automate a small theater play, and once in a while you have that big tour with some heavy automation through a huge lighting console. Sometimes you may even have to work on a small corporate event where you will just trigger video loops from your computer keyboard..

Well you can do this all with MediaMaster 2.0. and even better, for those of you who never do the “big tour with some heavy automation through a huge lighting console” stuff, it will come in two versions; the Express that will be something like a 8 tools Swiss Army Knife with just the essential and the Pro that will be more like the full-featured 12 tools Swiss Army Knife.

In MediaMaster 2.0 we’ve implemented a very efficient Simple Mode as default for the Express version (which, by the way, will also be available in the Pro version). This mode is based on presets, for example if you are doing LED Mapping over your video output you will be able to create a preset defining your LED wall and easily recall it for many cells. Later on, if you edit this preset you will see the modification applied instantly to all cells using it without the need to re-edit all your show.

The main advantages of this new Simple Mode over what you had in VJ DMX are:

• the preset system makes it very quick and easy to use
• it allows triggering visuals with DMX, MIDI and any computer keyboard
• it makes use of MediaMaster‘s advanced media management system
• it benefits from the performance of the new video Engine (frame blending, audio support, etc…
• 64 patches of 64 cells are available to store visuals and effects
• everything is saved into the Media folder (content, patch information, show setup, ..) making it easy to move your files between computers

We are now close to the final release and we expect to start some public beta testing in the days to come, so stay tuned!

Meanwhile, the Marketing is working on the official communication, writing the press release and all the stuff they have to do, which will include announcing prices and offers for VJ DMX users, but we can already announce that we will offer free upgrade to MediaMaster Pro 2.0 to all current MediaMaster 1.x users.

If you don’t want to miss the announcements, sign up for our newsletter!

At ArKaos, it’s now many years we’re developing software that drives LEDs in a way or another: our media server software MediaMaster and our VJ software GrandVJ are used every day to drive LED fixtures or LED walls, and of course we have the LED Mapper extension which, combined with MediaMaster, creates a very easy solution to map visuals on complex setups of DMX driven LED walls.

However there is still something that makes it too complicated and / or too expensive for anyone to display visuals on LED devices: setup…

Simple LED fixtures rely on the DMX or ArtNet protocol to work, which means many magic numbers to type, multiplying chances that something goes wrong and prevents your little pixels to blink.. On the other hand, big LED wall components come with hardware interfaces facilitating the setup but they are most of the time so expensive that they’re not an option for most performers and clubs.

We’re in 2010 and it should not be science fiction to have a LED device with an Ethernet port that automatically ”says hello” when connected to a media server and then sends its description so the server can immediately use it without any setup. The device would contact MediaMaster and configure itself automagically by explaining its capacities like “I am a LED device with 48 x 12 pixels in 5 bits format of red green blue”.. In other words: Plug’n Play.

And of course, this should be operated by an affordable processor because you don’t want to add a PC behind each device..

Well that’s exactly what our Kling-Net protocol does. The prototype you can see on the video above is built with an inexpensive open-source electronics prototyping platform called Arduino, and as you can see, it just works.. We’ll now fine-tune it some more and decide what we’ll do with this baby.

If you want more technical info about Kling-Net, we have started to document it on a dedicated Wiki.

Recently we’ve been in contact with Alioscopy, a French company that develops auto-stereoscopic 3D displays that can produce a sensation of depth without needing cumbersome eyewear and they asked us if we could bring live VJing to their 3D screens.

The problem is, even if you are only mixing footage that is compatible with 3D projection you are still missing live visualizers which are, most of the time, a very important part of the mix and which obviously can’t be pre-encoded for 3D projection..

Alioscopy’s 3D display range currently includes 24″, 42″ and 47″ screens integrating a technology that is based on standard Full HD LCD displays but equipped with an array of lenticular lenses. Each lens overlaps 8 different points of view and casts different images onto each eye, allowing for one only to be seen through the lens from any given angle.

Thus to recreate this feeling of depth, a 3D scene needs to be rendered from 8 different points of view and combined to one auto-stereoscopic image. To achieve this, we developed an easy to use auto-stereoscopic Quartz Composition template wherein you can transform your original Quartz Composer composition to a obtain real 3D sensation on an Alioscopy screen.

Integrating support for Alioscopy in GrandVJ through a Quartz Composition template was a logical step since GrandVJ now fully supports Quartz since version 1.2. – and of course, the same integration will also be supported in MediaMaster – But the big advantage of a Quartz template is that it’s fully customizable by the user; you can fine-tune the depth effect exactly the way you want!

When edited in Quartz Composer, the template appears as a layer above the original composition. Descend the patch hierarchy, paste your scene, adapt the auto-stereoscopic parameters depending on your scene and you’re done. The 3D-enabled composition can be used and mixed as any other Quartz Composition in GrandVJ but of course, it must be output to an Alioscopy screen to see the magic happen.

Now we just have to decide how we are going to go to the market with this new development but you should read more about this very soon..

http://www.arkaos.net/forum/viewtopic.php?f=26&t=6828

This version has many new cool things which are detailed in the forum post, here is a recap:

• New ultra smooth engine
• Support for Akai APC40 & Generic midi feedback
  (also for Behringer BCR2000/BCF2000, Livid OHM, ..)
• Quartz composer player (Mac OS X)
• Support for Flash Actionscript 3
• Cell layer assignment
• Mixer state saving
• Added master blackout button
• New enhanced soft-edging algorithm
• Added vertical/horizontal position presets for TripleHead2Go
• Several Bug fixes.
• New fullscreen option (PC)

We plan to ship the final version at the end of this month so we encourage you to check if this new version is working fine and to report any problems or suggestions by creating a topic in the GrandVJ forum.

Happy testing, we hope you will have as much fun using this version as we had to code it!

When you are in the show industry and try to find out the best way to compress your content it’s still a little bit of black magic. While some codec are able to compress video very well they are heavy to handle for the machines, even more, the codec that does the best job at compressing while keeping a good quality such as H264 are very bad when you need to scratch your media.

The best codec for users that need to interact a lot with the content should allow to play forward and backward easily and should allow to jump into the content quickly.

Recently, I’ve heard about experiments with a file format designed by graphic card manufacturers and based on texture compression DXT1 DXT3 or DXT5 and I was wondering how hard it would be to add support for such a format to QuickTime through a new codec. Being programing for the QuickTime API since it’s version 1.0 beta I was considering the challenge fun and interesting.

I started by resuscitating an old sample code from 1999 found on the Apple web site and after a few hours of coding and testing I had an ArKaos codec generating video files that could be played back by QuickTime.

ArKaos codec in the QuickTime player

Then I jumped on the DXT texture compression problem and chose to use the squish library to handle the job. A few more hours later and my experimental codec was working with texture compression.

The codec when used by QuickTime at that point was not efficient because the texture decompression was done on the CPU, so there’s no advantage of using the GPU to handle that texture format.

To measure the speed up I used an experimental player I am working on, and patched ffmpeg to handle my new codec. This allowed me to leave the texture data untouched and pass it to the GPU via the OpenGL extensions that handle texture compression.

When this was done I could start enjoying the show and make some performance tests; in the table below the file size is in MB and CPU load is taken from running top in the console:

If you are curious about frame quality here is a crop from an original frame in Apple intermediate :

Original frame - Apple intermediate (click for full size)

Here is the same cropped frame using Dxt1 with texture compression:

HD frame - Dxt1 compressed (click for full size)

And here is the same cropped frame with Dxt5 compression:

Same frame with Dxt5 compression (click for full size)

So the results of these tests are that pure Dxt1 is the best format when it comes to CPU load, Dxt5 is better if you focus on quality but it generates files that are twice bigger. Actually, using Dxt1 I could have played 7 HD loops at the same time with my laptop … I mean, if hard drive’s data rate would’ve allowed it!

The problem with pure Dxt5 or even Dxt1 files is that they are huge, about 4 times bigger than photo jpeg or H264 encoded files. So my workaround was to use data compression on the CPU, since it’s almost unused!

To conclude, it looks like using Dxt1 with texture compression is the best solution to optimize both CPU and disk usage with a file size that is almost the same as Photo jpeg and a little bit bigger than H264. And the codec is still twice faster than any other codec I tested when using the CPU to decompress the texture data from disk.

On my venerable old MacBook pro I can’t smoothly play a loop in Full HD and even at 1280*720 my machine is still struggling. Thanks to Dxt1 with texture compression I can play two HD layers and three 720p layers.

Now I know you guys would like to play with this new toy so here’s a .dmg file with the test player I have used, along with a set of video loops. Beware that this dmg file is for Mac OS X x86 only (no Power PC): and here’s the link

You can be sure that we will bundle that new experimental codec in the next update of GrandVJ and MediaMaster, so everyone can enjoy it!

Here is the result:

Ok there is a black frame when switching queues but hey, it’s a prototype :)

It’s fully multithreaded so development is moving forward carefully. There are threads for the network synchronization, video decompression, OpenGL rendering and status update to the server