SDK for Connectivity?

Eric’s quite right: the connectivity driver isn’t going to provide much more than real-time DMX stream buffers, so reading in from a Widget really is the best approach to capturing 3PC output on a per-project basis.

However, I’ve found that working with a DMX capture is just a horrible idea:

3PC DMX refresh rate is way too low for NTSC by default, though it can be adjusted.
8-bit integers is all you get. Anything with more than 256 discrete values will cause a need for developing an entire, maintainable “patching system”.
Unless you’re interlacing post, you’ll need to invade the render pipe to get each DMX “frame” to persist/drop mid-field-frame.
Identifying “Frame One” from a DMX capture can be really tricky. You can watch for a dummy cue to bump and have it then fire your first real cue, but then you have to identify the time between the two, etc. There’s always going to be manual work involved in getting things lined up just right.
And most importantly, if you want to make a change, you have to start the entire capture/sync/apply/persist process completely over, making sure everything gets cleaned up and possibly losing any changes made since the last application.
I’ve completely abandoned a project that was meant to light faster in Maya by using 3PC, less like a motion capturing device, and more like a custom modeling environment tool.

As such, the few successes it did have did not incorporate the 3PC playback engine or DMX at all, only the raw cue data saved by 3PC, in all of its type-safe glory.

Using cue data fits very well with the whole concept of keying (as opposed to keying every parameter once per DMX refresh), and it affords you the opportunity to produce a plug-in that’s actually designed to fully participate in the dependency graph [sic]. Linear crossfades should be dead simple to hook up during your XML (hint) import process; all other fades are just a quick lookup in the right CrossfadeTable. You can pull off effects (or better, an entire “keyless” “show”) by employing some simple influencers in your driven keys.

This of course raises the point that a lot of the playback power that 3PC provides will be lost if you choose to forego a finished DMX stream. On the other hand, 3PC’s playback is based upon a human-tuned and rather fixed conception of Time, which doesn’t translate as easliy as one might hope.


A few hints, in general, either way:

Never use pan/tilt. Focusing through a render window blows. always map 3 parameters to “Center of Interest” XYZ
Remember to add parameters to animate “hang position”, too.
Make sure ranges in Fixture Builder match your object limits.
Congratulations, all your fixtures are color calibrated. ish.
A file system watcher is gonna be your best friend for staying seamless.Have fun with this; I wish you well.

Eric’s quite right: the connectivity driver isn’t going to provide much more than real-time DMX stream buffers, so reading in from a Widget really is the best approach to capturing 3PC output on a per-project basis.

However, I’ve found that working with a DMX capture is just a horrible idea:

3PC DMX refresh rate is way too low for NTSC by default, though it can be adjusted.
8-bit integers is all you get. Anything with more than 256 discrete values will cause a need for developing an entire, maintainable “patching system”.
Unless you’re interlacing post, you’ll need to invade the render pipe to get each DMX “frame” to persist/drop mid-field-frame.
Identifying “Frame One” from a DMX capture can be really tricky. You can watch for a dummy cue to bump and have it then fire your first real cue, but then you have to identify the time between the two, etc. There’s always going to be manual work involved in getting things lined up just right.
And most importantly, if you want to make a change, you have to start the entire capture/sync/apply/persist process completely over, making sure everything gets cleaned up and possibly losing any changes made since the last application.
I’ve completely abandoned a project that was meant to light faster in Maya by using 3PC, less like a motion capturing device, and more like a custom modeling environment tool.

As such, the few successes it did have did not incorporate the 3PC playback engine or DMX at all, only the raw cue data saved by 3PC, in all of its type-safe glory.

Using cue data fits very well with the whole concept of keying (as opposed to keying every parameter once per DMX refresh), and it affords you the opportunity to produce a plug-in that’s actually designed to fully participate in the dependency graph [sic]. Linear crossfades should be dead simple to hook up during your XML (hint) import process; all other fades are just a quick lookup in the right CrossfadeTable. You can pull off effects (or better, an entire “keyless” “show”) by employing some simple influencers in your driven keys.

This of course raises the point that a lot of the playback power that 3PC provides will be lost if you choose to forego a finished DMX stream. On the other hand, 3PC’s playback is based upon a human-tuned and rather fixed conception of Time, which doesn’t translate as easliy as one might hope.


A few hints, in general, either way:

Never use pan/tilt. Focusing through a render window blows. always map 3 parameters to “Center of Interest” XYZ
Remember to add parameters to animate “hang position”, too.
Make sure ranges in Fixture Builder match your object limits.
Congratulations, all your fixtures are color calibrated. ish.
A file system watcher is gonna be your best friend for staying seamless.Have fun with this; I wish you well.