First Resolume gig recap, from a programmer standpoint

[GLspace]

Hi all,

Here are some observations, comments, wishes, and kudos from our first Resolume gig at Music Loves Fashion 2009. I hope this will help make Avenue a better software.

Setup:

-We had superwide resolution of 1920X480 (clips encoded like that). The initial idea was to have a panoramic image through which people would travel.

-To do that, we had one central projector (Panasonic PT7700, 7.7k lumens), focusing on the centermost 720 X 480 region.

-Laterally, 2 Panasonics PT5700 on each side, blended in the middle, for a MEGA screen of 2048 X 768. Each lateral screen showed the whole content.

Observations :

-The show was the BOMB. People litterally danced in front of the projections. I will post a video shortly, once it's done.

-Resolume has some pressing memory management issues to be resolved. I would suggest allocating and deallocating safe ressources (safe pointers), and perhaps putting dangerous operations blocks within try{...}/catch{...} statements, to at least elegantly warn the user that something's wrong. Right now, Resolume bombs without notice and exits without a word. Poor memory management seems to be the reason; but I understand that managing large asynchronous buffers quickly can be tricky.

-This forces me to recommend: if anyone's interested in a critical live gig where crashing is not permitted, HAVE A VIDEO SWITCH at hand and two machines. It'll save your life, because Resolume will assuredly crash.

-The GUI thread should really be decoupled from everything else. For instance, the save operation is blocking, and no feedback is given (what about a save progress bar?). Numerous operations will need to be put in their separate threads.

-Batch modification of clip properties (width/height, for example) should be implemented. I would so loathe writing a parser to do just that...

-It would be nice to be able to automate parameters on bezier/TCB/handle curves. A nice little curve editor could pop up and allow you to parametrize any... parameter.

-A super, super feature would be to have a built-in fragment shader editor. A bit like in Winamp, where you can type pixel shader code in real time, and apply it immediately to a layer, clip or frame. Uniform binding could be done similarly to how it's done with FFGL.

-A far out feature which could be interesting: support for warping, deformation, blending, etc. E.g, everything necessary to correctly display images on curved screens, or at extreme keystone angles, or blend output from multiple projectors. It can already be done using FFGL, but you need medium-advanced C++ skills for that.


That's about it. Overall, Avenue rocks and has a bright future ahead of it!

G

[edwin]

-The GUI thread should really be decoupled from everything else. For instance, the save operation is blocking, and no feedback is given (what about a save progress bar?). Numerous operations will need to be put in their separate threads.

The GUI is of course decoupled as much as possible. But the save operation is indeed blocking, we haven't threaded the progress of saving. Some feedback on the progress of saving would indeed be nice.

-Batch modification of clip properties (width/height, for example) should be implemented. I would so loathe writing a parser to do just that...

This is on our todo-list although it has not a high priority.

-It would be nice to be able to automate parameters on bezier/TCB/handle curves. A nice little curve editor could pop up and allow you to parametrize any... parameter.

Yes curves instead of simple linear behaviour like it is know is something we like to build.

-A super, super feature would be to have a built-in fragment shader editor. A bit like in Winamp, where you can type pixel shader code in real time, and apply it immediately to a layer, clip or frame. Uniform binding could be done similarly to how it's done with FFGL.

Yes this idea crossed our mind several times already, we could expose some default parameters which can be directly accessible in the shader.

-A far out feature which could be interesting: support for warping, deformation, blending, etc. E.g, everything necessary to correctly display images on curved screens, or at extreme keystone angles, or blend output from multiple projectors. It can already be done using FFGL, but you need medium-advanced C++ skills for that.

We are working on our keystone plugin to get a better quality. But more tools to warp the image would indeed be nice. We also hope that more FFGL plugins will be made by third parties.

Thanx a lot for your feedback.
Edwin

[massta]

This is great and sad news.

Hoping to mix at 1920x480 myself. I'm not really interested in going crazy with effects as much as just being able to mix two 3 minute layers and change the second while the first is playing smoothly. This way I can mix through a bunch of long clips. Sure adding effects along the way would be nice, but just getting it to mix a layer after layers in 1920x480 with no crashes would be huge since it's difficult to had a back-up at this resolution.

Set-up would be PC to TripleHead Matrox device to three projectors. The back-up would be an SD feed to each projector and wouldn't look nearly as nice as the wider feed.