NATO.0+55+3d modular, 10/14

NATO.0+55+3d modular, page 10/14
Extended Distribution

Extended Distribution

If the built-in NATO objects aren't enough for you, you may purchase several `extended` objects for NATO. At the time of this writing, they include:

- 242.wto: video streaming objects
- 242.parazit: a plug-in host for Image/ine plug-ins
- 242.fireuire: several FireWire objects, which permit NATO to send various data (image & effects data, DV data, MSP audio data) through your FireWire port
- 242.o204: an internet data transfer (download/upload) object
- 242.axial: a directory/search engine utility
- 242.of02: a realtime, recursive multi-layer photoshop file to qt movie converter
- 242.obl!ke: a media preview object
- 242.gl: an OpenGL renderer
- 242.qtfx: a QuickTime effects host
- 242.nr+: some non-realtime objects
- 242.rna: NATO to MSP sound manager driver and associated software.

There are a few others, and I expect the list will continue to grow. I'd have to describe these extras (the ones I've used) as a mixed bag. Please read on for specifics.

242.wto package

I had the good fortune to use `242.wto` at a NATO `summit` in Rotterdam. These objects use freely available Max network objects (the Open Sound Control/UDP objects) to communicate over a network (local or remote) via UDP. The `242.wto` objects encode the NATO image data into a packet format compatible with the UDP objects and then decode them back (upon receipt) into the format that NATO works with. They integrate right into your existing patches without any hassle.

The first time we got `242.wto` to work, I was amazed. Admittedly, the person transmitting was sitting right next to me, so it wasn't as dramatic as it could have been, but nevertheless, video data was travelling over the network from his machine to mine. We were using a 10baseT hub, and framerates were still pretty good. Before too long, we'd built a 3-way sending/receiving/compositing program. As we increased the complexity of our programming, though, some of the limitations of `242.wto` became very clear.

The amount of data being generated by NATO is enormous. When that much data is packeted and sent into the ethernet port of a computer, it seems to completely overwhelm the machine. It's probably similar to a `denial of service` attack -- a massive flood of information. If all you are doing with `242.wto` is receiving data from a remote location and playing it, it seems to work fine. If you try to apply even modest image processing, compositing, complex signal routing or whatever, your machine will slow down to a crawl, hang for 30 seconds at a time or crash (at least this is how it happened for us). After adding the `242.wto` objects into a performance patch I was using, the patch became too slow to use. As soon as I pulled the ethernet cable from the back of my machine, speed and responsiveness returned.

The `242.wto` objects do allow you to set packet size and buffer size, and adjusting these will improve performance to some degree. We were never able to find reliable settings, though. My guess is that as faster networking becomes more common, the technique used by `242.wto` will work better, but I'm not a networking expert, and I don't know where the bottleneck is occurring.

Another downside of the `242.wto` objects is that they only work for point-to-point communication. You have to specify an IP address and port to send the data to. You may set up multiple sender objects (and transmit to multiple known receivers), or open multiple ports on a single machine (and receive multiple streams). And, of course, both the sender and the receiver need to have `242.wto` (a $74.47 value, at last glance). While `242.wto` does, as is claimed, perform `video streaming`, it does so in a highly limited fashion. In order to get NATO image data into a conventional multi-streamed web broadcast, you'd need to send the image data using conventional means, like an S-Video cable, to a machine capable of broadcasting the images over the internet (running a RealServer or Sorenson Broadcaster, for instance). `242.wto` wouldn't be necessary at all.

242.fireuire package

At the same time I played with `242.wto`, I had a chance to use the `242.fireuire` package. There are several packages available for purchase -- an `ultralux` version that contains all of the available FireWire objects, and various single-object packages. Two of the objects (`242.filmdv` and `242.fireuire`) are NATO-specific, one object (`242.fireuire~`) is for MSP, and the other two objects are for Image/ine (I won't be discussing those).

The NATO FireWire externals are for image _output. Image input via FireWire is supported in the basic package. All of the FireWire objects use a special shared library supplied with the package. This library permits multi-client / multi-application operation, which means that other applications can use the FireWire port at the same time NATO does (simultaneous operation causes flickering, though). Each instance of a NATO FireWire object counts as a client. Generally, if you're using `242.fireuire` (the object, not the package), it's the last object in the chain, and so there will be no flickering (any compositing you're doing will happen earlier in the signal network). Running multiple `242.filmdv` objects will cause flickering, since they cannot be composited.

- 242.filmdv: This object substitutes for the 242.film object, but is primarily intended to work with DV media. It incorporates the features of 242.film, but adds the functionality necessary to connect to the FireWire port as a client. With DV films, `242.filmdv` works well -- at normal rates, playing forward, it's fast and performs as advertised. If you begin to change playback rates or direction, things seem to fall apart a little -- the video begins to `choke` and stutter. This seems to be a limitation of DV media, rather than NATO, though (QuickTime Player has the same problem with DV media when looped back and forth, and it's not even sending image to the FireWire port).

If you like to misuse your tools, `242.filmdv` also functions with non-DV films, but has unpredictable results -- generally the color space of the film is completely wrong and the image has been multiplied and tiled by the time it hits your camera. Of course, this effect might be desirable... Results depend on the dimensions of the film and the codec used.

- 242.fireuire: This is the most exciting, and also the most disappointing object in the NATO extended family. `242.fireuire` is intended to send NATO image data (any image data played or generated by NATO plus effects, etc.) out to your FireWire device. Like `242.rekord` or `242.ekran`, it is placed at the end of data chain. If you want to record your work digitally via FireWire, `242.fireuire` seems like the perfect solution. The problem is that it doesn't work well.

Here's the issue: to send image data to your FireWire camera, NATO has to encode the data as DV. The encoding is extremely processor-intensive, and, on my 500MHz Powerbook, cuts my framerate down to between 1/2 and 1/3 of normal. You can simulate the effect by running this patch. Here's a side-by-side comparison -- this movie was recorded via the s-video port on my computer (into the analog in port on my camera) and this movie was recorded via `242.fireuire` (using FireWire input to the camera). I expect that as QuickTime's DV encoding becomes more efficient and as computers become faster, this process will be less taxing, and `242.fireuire` may become usable. Today, though, it's not, really. If you absolutely need FireWire image transfer, save your money and put it toward a Sony DVMC-DA2 media converter.

- 242.fireuire~: This external is used to send MSP audio out to your FireWire device. It works great, actually, within the stated limitations (sample rate must be 44.1KHz, I/O and signal vectors must be at 2048). Since the release of `242.fireuire~`, MSP version 2 has been released, permitting signal vectors of size 2, so, hopefully `242.fireuire~` will be updated to accommodate the change.

242.gl package

The 242.gl package is really quite nice. It includes an extensive offering of objects: around 20 externals which cover shape generation (cylinders, disks, cubes, lines, rectangles, spheres and the `242.glmesoderm` object which produces the default OpenGL shapes like, for instance, teapots), fog, lights, texturing (like `242.3d`, you can project any NATO image data onto the `surface` of an OpenGL shape) and positioning (offsets, rotations, POV).

I've used `242.gl` for a number things, including sprite animation (since `242.gl` objects are persistent, you can move them around and manipulate them without needing to redefine the entire scene, as you do with `242.qd`), and virtual space descriptions (creating OpenGL scenes, and projecting films into the `empty` space).

The above patch generates two OpenGL rectangle objects (`242.glrekt`), each being positioned and rotated by a `242.glmatrix` object. Also demonstrated is `242.gllight`, which is specifying the position of lights and reflectiveness of the scene and its objects, `242.glfog`, which is producing a reddish tint as the image recedes, and `242.gltexture`, which is using NATO image data as a texture map.

Overall, the `242.gl` package works well and seems fairly quick. I haven't used it to generate more than 4 or 5 objects at a time and add texturing, but it does that splendidly.

242.parazit package

The `242.parazit` package is fantastic. It's an external which hosts Image/ine plug-ins, some of which can accomplish video tasks which are very computationally expensive to mimic in NATO (I'm thinking of Multi, shown below, specifically). Image/ine comes with 19 plug-ins, some of which are unsuitable for NATO use, since they modify control behaviors within Image/ine. There are a handful of 3rd party plug-ins available, too.

If all you really want is Multi, download my package of NATO externals, which includes a Multi clone, or grab R. Luke DuBois's NATO objects in the PeRColate package, which include some nice variations on the theme.

242.nr+ package

One of NATO's initial shortcomings was its lack of non-realtime capabilities. There are now specialized versions of `242.rekord` and `242.buffer` (called `242.rekord.nrt` and `242.buffer.nrt`) which fill this gap. Essentially, these externals offer an extra mode, placing the object into non-realtime operation. In this mode, the object will record 1 frame at a time, and send out a message after each frame is done. You can then use that message to advance your process to the next frame. It works fine and, in fact, is so simple, it's a wonder that this functionality is not included in the basic objects.

You might also want to check out these gratis patches by xampl@hotmail.com. They provide a less elegant, but working, solution to the problem of frame-by-frame capture in NATO, and are free.

back
forward
top

legal information