“Integrators in the broadcast and real-time video production market can now benefit from the latest advances in GPU acceleration,” said Sandeep Gupte, general manager of professional graphics at AMD. “Solutions built around AMD FirePro SDI-Link, with the support from broadcast technology leaders, are able to simultaneously solve the two key challenges facing video pipeline solution providers today: the need for flexible SDI input and output capabilities, and the requirement for real-time GPU-SDI communication in an integrated solution.”

By leveraging the combined decades of SDI-related experience from AMD’s technology collaborators, along with the new AMD DirectGMA technology that allows SDI I/O products and select professional graphics cards such as the new AMD FirePro(TM) V7900 SDI to communicate directly over PCI Express(R) (PCIe), customers can build solutions for virtual sets, professional video production/post-production, on-air motion graphics, on-set 3D VFX, and other scenarios. All of this can be accomplished with ease via APIs exposed in the AMD FirePro SDI-Link software developer kit, allowing the delivery of new capabilities and feature sets with never-before-seen flexibility and cost-effectiveness.

“The video broadcast market has been seeking a reliable, quality solution for some time,” said Jon Peddie, president, Jon Peddie Research. “AMD has upped the ante when it comes to the video marketplace by engaging with the top six industry leaders in this space. Kudos to AMD for tackling another market, backed by technology leadership.”

AMD FirePro SDI-Link is supported by the following companies: “One of the most important ways we can support our customers is by providing them with accelerated workflows to boost their productivity,” said Nick Rashby, President, AJA Video Systems. “AMD FirePro SDI-Link does just that, allowing AJA customers to benefit from both GPU-based and SDI solutions using AMD FirePro professional graphics and AJA’s video I/O products.”

“Blackmagic Design is looking forward to adding integration between our products and the AMD FirePro SDI-Link,” said Grant Petty, CEO, Blackmagic Design. “By supporting AMD FirePro SDI-Link, our developers will see a revolution in performance combined with extremely low latency when building intense graphics based video solutions using Blackmagic Design desktop video products and AMD graphic cards. This will be perfect for broadcasters working in areas such as weather, live news and 3D virtual sets, where high performance graphics and extremely low processing latencies are critical.”

“Bluefish444 customers have been demanding this type of collaboration between Bluefish444 and AMD for years,” said Craige Mott, managing director of Bluefish444. “Until the advent of low latency transfer between our devices, Bluefish444 customers had to compromise on the amount and quality of real-time accelerated graphics they could SDI I/O using Epoch video cards. Now, between Bluefish444 and AMD we can offer the highest quality SDI I/O and the highest quality GPU accelerated graphics, all at an ultra-low latency transfer between our respective products.”

“With the support of AMD FirePro(TM) SDI-Link, DELTACAST answers to a typical requirement of our OEM customers,” said Christian Dutilleux, CEO of DELTACAST, “And the most important for them is that we provide a built-in solution, elegantly integrated within the worshipped VideoMasterHD SDK, and certified by both AMD and DELTACAST. Thanks to the ultra-low-latency model of the AMD DirectGMA technology, developers now benefit from the incredible processing power of the professional AMD FirePro GPUs, and from the robustness and accuracy of the DELTACAST SDI multi-channel devices, to create stunning on-air graphics applications.”

“We are very excited to team up with AMD to offer developers even more options for their high-end broadcast and post production solutions,” said Juergen Heger, Senior Product Manager at DVS. “The combination of the new AMD FirePro SDI-Link with DVS’s Atomix family of video boards ensures an easy and low latency integration of DVS’s reliable SDI input and output capabilities with the GPU power of AMD FirePro SDI graphics cards.”

“Matrox DSX Developer Products are renowned among broadcast equipment manufacturers for high performance I/O hardware, a comprehensive SDK, and outstanding applications engineering support,” said Albert Cieri, Senior Director of Sales and Marketing, Matrox. “Our collaboration with AMD on the new AMD FirePro SDI-Link adds tight GPU integration which will further enhance our customer’s broadcast graphics system performance.”

The AMD FirePro V7900 SDI professional graphics card represents a number of firsts for AMD: — First AMD FirePro(TM) professional graphics card to support AMD FirePro SDI-Link and planned certified compatibility (currently in development) with all five leading manufacturers providing PCIe cards offering advanced SDI video signal I/O capabilities — First AMD FirePro professional graphics card designed specifically to address real-time professional video and broadcast graphics pipelines while delivering the same industry-leading GPU performance as the other offerings in AMD’s FirePro professional graphics line up — First to leverage AMD’s exclusive AMD DirectGMA technology to help ensure system-level, low-latency synchronized data transfer between the AMD FirePro professional graphics and 3rd-party devices over the PCIe bus The AMD FirePro(TM) V7900 SDI professional graphics card is slated for availability in October 2011 for US $2,499 MSRP.

AMD FirePro SDI-Link and AMD FirePro professional graphics are on display with industry leaders at IBC 2011 in stand 7.H35 in hall 7. Software vendors and solution providers demonstrating their use of AMD FirePro SDI-Link include: Drastic Technologies, eyeon Software, Tweak Software and Virtual Spectator. Other technology providers demonstrating at AMD’s stand include Ventuz and VizRT.

Supporting Resources — AMD FirePro(TM) SDI-Link product page — Twitter: Follow AMD professional graphics news on Twitter at @AMDFirePro — Facebook: Become a fan of AMD technology on Facebook About AMD AMD (NYSE: AMD) is a semiconductor design innovator leading the next era of vivid digital experiences with its groundbreaking AMD Fusion Accelerated Processing Units (APUs) that power a wide range of computing devices. AMD’s server computing products are focused on driving industry-leading cloud computing and virtualization environments. AMD’s superior graphics technologies are found in a variety of solutions ranging from game consoles, PCs to supercomputers. For more information, visit http://www.amd.com.

Advanced Micro Devices, Inc. AMD, the AMD Arrow logo, FirePro, and combinations thereof, are trademarks of Advanced Micro Devices, Inc. Other names are for informational purposes only and may be trademarks of their respective owners.

Contact: John Swinimer AMD Global Communications 905-882-2600 Ext. 2704 johnm.swinimer@amd.com

Copyright 2011 The Associated Press. All rights reserved. This material may not be published, broadcast, rewritten or redistributed.

We are proud to announce that Ventuz 3 has been officially released and can now be purchased. If you haven’t been able to try the beta version yet, here are some key features that will make your work better, faster, and even more impressive!

The Interaction Nodes
Yes, Ventuz has always been a superb choice for wonderful touch applications, but we have made it even easier. The range of new Interaction Nodes can turn any object in your scene into a button or slider through simple drag and drop. But that is not all. We have also implemented your common multitouch functionalities, such as touch translation and touch transformation. Even markers for optical systems can be added just as easily.

New Edition Ventuz Touch
With these amazing touch functionalities we introduce a new version of Ventuz: Ventuz Touch. We know that there are still many among you who do not own a Professional license, but we do not want to keep these great features from you. That is why we bring to you this cost effective Version of Ventuz. It has the same features as Ventuz Express but also includes the Interaction Nodes. This is the perfect version for creating stand-alone, high-end interactive applications.

The Web Browser Node
This is a fully functional Chromium Browser that supports any given web page, including Flash and Silverlight. The web inside of Ventuz!

And there is much more! You can buy Ventuz Touch and all Ventuz 3 Upgrades online now. To find out more, click here!

You want to see Ventuz 3 in action? Come see us at the IBC in Amsterdam, September 9th through 13th 2011. Like last year we will be cooperating with our friends from AMD, so you can find us at their booth #7.H35.

If you want to set up a meeting beforehand, please write an email to info@ventuz.com or give us a quick call.

This beauty will most likely be available with the next release of Ventuz 3.

What is new?

The major novelty are the amazing little interaction nodes. Never before has the creation of interactive content been this easy.

Another very nice new feature is picking and manipulation. It allows you to directly influence objects in the render window.

Find the detailed description on our website and download Ventuz 3 there as well.

Since Ventuz 3 is currently still a beta version, we do not support it. Therefore we do recommend that you test very carefully before you go into critical production with it.

We hope that you run Ventuz 3 through its paces and please let us know what you think. There is a new instant-feedback-button that should make this very easy for you!

Have fun!

The quality of the 3M is quiet nice. On very bright backgrounds we noticed  cross patterns. Maybe this grid will disappear within the next LCD releases. But so far a pretty cool solution for a up to 20 finger system….

“Interfacing Technology”

What’s that? At the end is a simple feature, but it’s very very powerful to increase the modularity of Ventuz drastically. Collaborative work becomes much more effective than ever before. Interfaces are some kind of Exposings whose remain existent if you delete the actual content of a container. This enables you to divide the actual logical work from the design part because you could define a ‘communication’ interface with a container upfront and ‘implement’ the actual content later. Of course you can exchange such content easily or drag&drop the content from one container to another – without losing the bindings!

Another big feature: Scene Ports act now ‘like’ containers and of course, they can have interfaces! Because of that Cross-Scene-Bindings are now possible!

You will love it – because we already do! 

Feel free to download Ventuz 2008 R5.24 RC1 now and don’t hesitate to use it. The official release is planned shortly (may be next week). The 2 weeks of testing with hundreds of scenarios were successful that we think it’s time to reveal this technology to you!

We prepared a Whitepaper for R5.24 (PDF) to help existing Ventuz users to get faster into the new features.

Download Ventuz 2008 R5.24 RC1 x86 or Ventuz 2008 R5.24 RC1 x64

Expect also many other nice features (like node navigation) and bug fixes in R5.24

Have fun!

Your Ventuz Development Team

—

Ventuz Release NotesVentuz 2008 R5.24

Stay tuned!

The answer is simple:     yes

If you use such fonts, you have to be aware of some points, because 3D-real-time rendering is not comparable to normal rasterization technologies used in 2D software. A ‘normal’ rasterizer (like Word, Flash or Photoshop) renders the actual character glyphs directly on the basis of the font file. The glyph gets pixelized during that process while some rasterizers use caching algorithms to speed up the actual rendering. Newest technologies like Direct2D™ or ClearView™ enhance the actual 2D rasterization drastically, but they are still not usable for our environment: 3D space in real-time.

For that reason Ventuz (and any other 3D-rendering system) have to convert the font data into formats usable by the graphics board directly (Direct3D™ or OpenGL). That means, the glyph outline information have to be converted into vertices (meshes) or textures (pixel glyphs) while applying certain visual effects like extrusion, bevel or blur – the Style. The final result of this conversion is stored on harddisk for easy and fast reload of this internal font format. In Ventuz, we call it the Font-Cache. You can find the cache folder in the common application data folder of your system:

Windows Vista and Windows7

 C:\ProgramData\Ventuz\Fonts

Windows XP

 C:\Document and Settings\All Users\Application Data\Ventuz\Fonts

If you need to re-convert (or re-generate) the font cache you can simply delete this folder. Ventuz will create it again as soon as a font is requested by the renderer.

Ventuz also requires the original font file to render fonts – even if the cache already has been generated for the required font and style. The font file contains further information such as character width, spacing, kerning. Ventuz uses two Windows APIs to access the actual Font file: Windows Presentation Foundation (WPF) and Graphics Device Interface (GDI+). Unfortunately there are a few differences between these two API’s: font styles (bold, italics, etc) are handled differently and are not compatible. Additionally, font files (like TTF or OTF) have multiple ways of describing a font: ISO, Windows, Mac, etc. Unfortunately, some fonts do not line-up all settings for all systems: a font marked as Bold for Mac could be marked as Regular for Windows. This issue brings up many problems in our Font-Engine. The easiest way to solve such font problems is to validate the font itself. A check, if the font works in MS Word or Photoshop doesn’t imply that the font is valid! Please use Microsoft Font Validator or the great FontCreator from High-Logic to validate your fonts. We’ve already seen many commercial fonts with such invalid settings – the usage of a validation tools always solved them.

A font file consists of outline description coming along with so called ‘mappings’. The mapping is the actual translation from the code page (ASCII, ISO, Unicode) to the glyph indices as well as the rules for combining multiple glyphs to one mapped character (special extensions or phonetic tones, like the German öüä). As long Ventuz is using Unicode mappings, some fonts do not provide the proper mapping tables. In such a case, Windows is doing a dynamic mapping for us, but this does not work properly for non-US (non-Latin) characters, because Unicode is the only complete mapping for all glyphs in the world (Cherokee and Samaritan included). Other mappings may not know about Chinese and Hangul glyphs and make it impossible to map the characters properly to Unicode. Therefore be sure that your font supports Unicode mapping if you want to use non-Latin languages.

A normal Latin font like Arial holds about 300 glyphs and a conversion to our font cache is fast and easy. Other fonts can hold more than 50,000 glyphs (Chinese, Japanese and Korean = CJK) and a font conversion can take up to 15 minutes!

Ok, time is not an issue if we only need to convert once. But memory becomes an issue! The font Arial Unicode MS holds the almost complete set of visual Unicode glyphs (about 50,000). Converting all glyphs to textures or meshes doesn’t make much sense if you only need a subset of it like Latin. Therefore we’ve implemented a CharacterSet filter (see Project Settings) to tell Ventuz which Unicode ranges you want Ventuz to convert into the cache. Unfortunately the breakdown of these ranges is not very handy, but is helps to separate Latin from Far-East and from historical or rarely used scripts. We’re planning to give more detailed options here in future versions.

The Character Set can reduce the number of glyphs converted into the cache, but what happens if you really need all glyphs? Chinese or Korean? In that case you have to handle to Font-Engine very carefully. We’ll try to give you some assistance:

1)      First of all, you should be very clear about the fonts you want to use in your project.  Use as less as possible (1-3)

2)      Try to select Fonts containing only the glyphs you really need. If you want Korean (Hangul) for example avoid fonts holding all Chinese glyphs as well.

3)      Make sure that all font files are valid by using a font validation tool as mentioned before.

4)      Create a new empty project

5)      Select only the Character Sets in the Project Setting you really need. Usually Latin, Symbols (and Special Language1 for Far-East)

6)      Import them into your projects font folder and make sure that the actual file name has no special characters (only Latin or ASCII)

7)      Create exactly the same amount of Font presets, including $Default for the fonts you want to use. In further Design step avoid any direct font references – only use the presets! This makes it also easier to change a typeface later by simply changing the preset.

8)      ‘Develop’ the styles for your fonts. The recommendation for large fonts (CJK) is to use only MeshFonts, because

1. Texture fonts (normal quality) require about 10 times more memory than the same font/typeface as Mesh. The complete Hangul-set for example needs about 200MB texture memory.
2. Mesh fonts are always hard-edged and seamlessly scalable
3. Try to avoid extrusion or bevel styles for mesh fonts because every bevel/extrusion tessellation will multiply the amount of vertices needed for the mesh font. A simple extruded font requires about 4 times memory if generated with all sides (front/sides/back)
4. Texture fonts are faster to render and have additional effects like blur, but 12,000 glyphs placed on textures (Hangul) will make this advantage void. If you like to achieve effects like shadow, try to combine multiple layers of mesh text elements.
5. Try to use only ‘normal’ quality. If you need high resolution mesh fonts, try to select just one font to be used with that style.

9)      If your styles have been developed, assign all final styles to style presets. Write down, which typeface-style combinations have to be used in your project, because every single combination will create its own cached and loaded font.

10)   Create a ‘Font-Style-Sheet-Scene’ where all allowed combinations are displayed on screen with dummy texts. You also could assist your team with such a scene with creating Repository Elements for each combination: call them Headline, Normal, Bold, etc

11)   Close Ventuz and delete the Font Cache.  (see above)

12)   Launch Ventuz and open your project again. Load you font-style-sheet and let Ventuz re-generate all typeface/style combinations.

13)   Check the resource values in the Scene Statistics dialog where you can see the actual memory occupied by your fonts. There shouldn’t be any other fonts as you have configured in you presets and style-sheet scene.

14)   Start creating the actual scenes by only accessing the allowed combination (Repository items)

In general we can say that a 12,000 glyph high-quality mesh font (no extrusion) needs about 40MB of memory. The same high quality texture font would need about 400MB!

If you follow these guides and always handle such large fonts carefully, you can be sure to create a complete function Chinese, Japanese or Korean Ventuz show!

Have fun!

Ralf

we assembled three small Ventuz Projects to demonstrate the new features of Scene Management/Layout Scenes and ScenePorts.
Hopefully this makes some things clearer and gives you new opportunities to build greater projects in less time.
We appreciate your feedback in our forum.

And here is the download link.

ScenePort Examples Project

This Ventuz Project demonstrates some of the use cases for the new ScenePort node. Read the annotations in the Ventuz scenes (01 .. 03) to get some details about the functionality of the scenes.

Screen Setup 3×2

This Ventuz Project demonstrates the Scene Management setup for a video wall of 3×2 screens.  The total resolution is 5760 x 2400.
The video wall if fed by three Ventuz machines. Each machine renders one third of the complete scene. Use the Stage Editor (Ctrl-F12) to switch between the Preview (Design) and Production Layout scenes. Read the annotations inside the Layout scenes for further information.

Screen Setup 4×1

This Ventuz Project demonstrates the Scene Management setup for a video wall of 4×1 screens.  The total resolution is 4320 x 1920.
The video wall is fed by one single Ventuz machine. Use the Stage Editor (Ctrl-F12) to switch between the Preview (Design) and Production Layout scenes. Read the annotations inside the Layout scenes for further information.
The Preview and Production Layouts differ in principal because the Design is 4 times 1080 x 1920 but the production machine has to render 4 times 1920 x 1080 in a horizontal span mode. This is necessary because 2 DualHeads2Go have to be used to split the graphics card output in two further fragments.

Best Regards

Our internal working title of this version was “The SM-Version” where SM doesn’t mean what you might think… it simply means: Scene Management

Why did we change the ‘old’ scene management?

In the previous versions of Ventuz the scene management had several problems and insufficient features. Also, the ability to split several parts of a show into smaller pieces, what scenes were initially meant for, did not fulfill the requirements. The previous approach of the “Scene Reference” didn’t help that much. The main issues were:

• Asynchronous load of scenes was not possible. The renderer stopped while loading sub-scenes.
• Multiple instances of the same scene in memory couldn’t be handled properly (remoting)
• Nested scenes were not exported correctly.
• Reference scenes couldn’t be edited on-the-fly. You only were able to open another instance in the Ventuz Designer, edit it and “Save & Reload” the scene into its referencing node.
• Blocking a scene reference didn’t really save performance, because the entire logic inside still kept working (like animation, movers, etc)

What’s new?

• The Scene and Slide Reference nodes have been replaced by the Scene Port and Slide Port node.
  A Port node can hold a scene and is able to render the scene as it was “inside” the hosting scene. Hierarchy nodes like Axis, Color, etc can affect the sub-scene.

  

• The main features of ports are:
  • If a Port is blocked by its Blocked property or by another parent node (alpha, switcher, etc) the scene gets inactivated and the internal scene logic is turned off. The performance saved on CPU is fantastic!
  • A Port can reference a scene by its name (URL), but also can reference a scene from memory. The remoting is able to load a scene and assign it later to Ports. This technique will allow us to switch or cycle scenes between ports in later versions of Ventuz.
  • A Port can be “locked”; that means the remoting or the new Stage Editor (see below) is not able to change the scene-to-port assignment. You can either lock a port by checking its “Lock” property or simply bind the File property to a data source (e.g. URL node or Excel)
  • Ports can load scenes asynchronously (in background). A “Progress” value from 0% to 100% informs the hosting scene about the load progress. The Port also provides a “Loaded” and a “Failed” event  to trigger certain stuff inside the hosting scene (like a fade in/out animation)

• Every Scene can have an unlimited number of Scene Ports to “host” sub-scenes. We call the level of nested scenes the Scene Level. The scene level you usually work with is “Level  1”, the next lower level is “Level 2” and so forth.
• Every Scene Port has a name (the normal node name) and an ordinal number starting at zero. This number is used to address ports within a scene via remoting. It is also important for “Layout Scenes” (see below)
• If you open a scene currently assigned to a port, you can edit it on-the-fly! This makes modular work really easy!
• Within the Ventuz Designer you can edit the exposed properties of a scene. A real “inter-scene-communication” does not exist yet. This will be the next step of development (see below)

The new Stage Editor

When working with nested scenes and remoting, you easily could lose the overview of which scene is rendered where. That’s why we developed the new Stage Editor (Ctrl-F12):

This Editor allows you to see all scenes in memory along with their available ports. Scenes can be loaded by the Ventuz Designer, by a Scene Port or by Remoting. The editor is again a tree view like you already know from the scene hierarchy editor. Drag&Drop makes it easy to assign scene to ports and track assignment changes via remoting. The scenes currently opened in the Designer as well the current scene are visually marked in the Stage Editor.

Inside the Stage Editor you also can switch and select the Layout of your current project (see below). It also allows you to temporarily change the MachineID for your local machine for testing cluster setups. Both features (layout and ID switches) are also accessible via keyboard shortcuts.

The editor is quite simple and has no “hidden” key shortcuts for special operations. Only Drag&Drop and the toolbar on top! Click and Double-Click on Scenes and Ports start some logical actions… try it out!

Advanced Layout Scenes

The new Scene Management allowed us to implement a very powerful new feature called Project-Layouts or Master-Scenes. A Layout is a scene loaded with your project before your first “user-scene” on Level 1. Layouts are placed in “Level 0” and can be used to create complex scene setups like multiscreen, stereoscopic, cube-projections, layering, etc. The big advantage of using layouts is that you don’t need to mess around with this setups anymore! Let Ventuz create Layouts for you (future versions) or let your Ventuz-Guru create the stereo-setup. You simply place a single sphere in your Level 1 scene – that’s it.

In the past, the “guru’s” created the “scene head” and provided a blank scene to the actual content designers. The new Layout concept separates the idea of layout, content and sub-content!

Layouts are simple scenes holding at least one unlocked scene port, preferable port ordinal 0 (the default port) is not locked. A layout scene is a normal scene:  you can use all nodes, externalize properties and insert layout related content.

The possibilities of layout are massive:

• A split layout with two ports (left and right) by using two relative viewport nodes splitting the screen in two parts.
• A layered scene layout: imagine three ports, background, content and overlay!
• An effect-layout making a standard glow and mirror rendering!
• …

Configure the layouts in the project settings dialog by accessing the new “Layout” config page:

Create a layout setup by selecting “new”. Enter a layout name and select the actual layout scene file. The fields “description” and “icon” can be used to help a user of your layout to work with it.

A very important feature of a layout is to override the actual rendering and screen settings of your project. In the D3D Overrides tab, you will find a small checkbox on every configuration group. If you check that box you can setup new values for each particular layout:

Imaging you setup a multi-head projection with two Ventuz machines with two outputs each. In such a case you could create a “preview” layout showing you the entire 4-screen-stripe, a “production” layout showing the actual content of one Ventuz machine depending on the machine ID (left or right).

Export Scenes and Projects

Inside the Ventuz Designer all layouts of a project are loaded in memory to allow the user to switch between them whenever (s)he wants. The Ventuz Presenter/Runtime only loads one layout and doesn’t provide the ability to switch layouts during production!

If you export scene / projects to archives, please notice the following

• Export a scene to VZA (Ventuz Design Archive)
  VZA exports stores the current open scene of the Designer into an archive including all nested scenes and their resources. Resources can be deselected in the resource dialog during export.
• Export a scene to VRA (Ventuz Runtime Archive)
  VRA exports does the same as an VZA export, but all exported scenes are written in runtime format (.vrs – Ventuz Runtime Scene). All required resources are included as well.
• Export to VPR (Ventuz Presentation)
  A Presentation export does not export the currently opened scene anymore! It actually exports the current layout setup, which means the current active layout with its complete current port assignment! So don’t forget to select the correct “production” layout before exporting a VPR!
  If you need to add more scenes to your VPR, you can use the Resource Linker node to embed more scenes in your presentation. The main-scene, could decide which scene to load during runtime!
• Export to VZD (Ventuz Director)
  A Director is a special form of the Ventuz Project file allowing the Presenter/Runtime to startup. If you export a Director the current active layout is “marked” to be the “production” layout of that Director. You also will be asked to export the current layout as a Runtime Archive VRA with the difference to the normal VRA export that no nested scenes are included in that export.
  A change to the Ventuz Presenter/Runtime allows to “auto-import” Ventuz Runtime Archives even if they are “beside” the director file instead of being stored in the AutoImport folder, because this folder might not exist on the first startup.
  The new auto-import also imports all found VRA files before (!) actually initializing the renderer and layouts.

What’s also new in R5.20

• There is a new “Rectangle Rounded” geometry node. Check it out! It’s powerful for borders and frames, but also for rectangular soft shadow. Have a closer look to its texture mapping options.

  

• The Render Target Node has been extended to select “Project” for its Multisampling Quality. In that case the Project settings are used, probably overwritten by the layout setting.
  The RT can also perform a “Render-Once” mode. This mode can be used to render textures of content which doesn’t change (pre-compose) or generate thumbnails of your sub-scenes!

Roadmap for Ventuz 2008

1. Interface Containers
   This feature will allow you to define a bind for properties, methods and events at a container without (!) having any content inside that container. The actual container-content defines the actual functionality by exposing properties, methods and events. As long name and type of those “interface members” matched the containers definition (hull) this members get bound.
   This technique will allow you to change container content (by drag&drop) without the need to re-bind the outer communication!
   The same technique is used to “talk” to nested scenes as well. Your master scene could call the “Start” method on a port. As long the nested scene exposes a “Start” method, the trigger will do what you expect. Ventuz becomes really modular!
2. Symbols
   The mechanism of “externalizing” properties will be enhanced that way, that other properties in your stage (bulk of nested scenes) can access these externals. You can create real “variables” or “parameters” or exchange information across all scenes without the need to bind them!
3. Remoting SDK
   The new Scene Management required a revision of the entire remoting as well; otherwise the new features weren’t accessible at all. The new Remoting server is already running and exposed to .net-Remoting, but not officially “released” to be used.
   The old remote interfaces (CLI, Vertigo, OSC, .net remoting 1.0) have been adapted to the new remoting layer and should work as they did before, without accessing the new layout feature!
   The upcoming SDK will provide the ability to implement your own remoting interfaces. The CLI, OSC and Vertigo remoting will get a new version each to make to new features (ports) usable for them.
   Another important reason why we changed the remoting is that the importance of cluster remoting came in focus faster than we thought. Therefore the new remoting allows asynchronous execution of each command. All commands can be scheduled and queued by assigning a timestamp (cluster-clock). The Cluster-HUB will be part of the remoting SDK for synchronizing the external control of multiple Ventuz Machines in a Ventuz-Cluster.

Don’t worry to test the R5.20!

Due to the massive changes in the Ventuz core, content saved with R5.20 can’t not be loaded in any lower version anymore: Scenes, Projects and all Archives

R5.20 has been tested for weeks and some customers are already producing with it. Our latest exhibition shows (Best Of Events, Dortmund and Integrated Systems Europe, Amsterdam) were build with that version without any problems.

Anyway, big changes popup new issues. Areas where issues could appear:

• Export of VPR Presentations and other archives
• Remoting, especially VertigoXMedia and OSC, async callbacks
• Launch of very, very complex nested scenes with nested async loads

Our current development focus is on releasing the R5.20!

The reason why we have a “Release Candidate” is to give our customers the chance of influence on issue as soon as possible!

If we do not get feedback from your side we consider this version as “accepted” and will release and support it as usual. So, please don’t hesitate to download and install R5.20 RC1

We appreciate your comments and bug-reports!

Your Ventuz Development Team!

DOWNLOAD R5.20 RC1 HERE!