Is it possible to reparent a node (by changing it's ID or otherwise)? I notice that when clips get added/removed on the reels their respective ID ranges change, so I am not sure this might be the way (the handle to a reel that I got might get stale if I move soemhting onto the reel for instance).
I am reconstructing a node graph, which involves rather lengthy uploads of frame data, and it would make something a tad easier. Also I was wondering if it's possible to make a "hopless" clip move from one library to another or between reels - no go. And what options do I have if I want to make this work - relinking the frames by path onto a new clip node?
Actually, the "uploads" of frame data are arguably best handled by created backgorund data transfer jobs. The latest SDK (now in Beta3) has the new functionality. We would be interested to get your feedback on it.
As for moving clips between reels, it's not yet possible via EDL ... the only way to currently re-assemble Stone media. Soft-importedmedia, on the other hand, will let you do this at will.
I'm still not sure why you would want to reparent though...
> Actually, the "uploads" of frame data are arguably best handled by created > backgorund data transfer jobs. The latest SDK (now in Beta3) has the new > functionality.
I don't think our wiretapd supports that, we are not on 2007 yet. Besides, I do not quite understand the difference between data transfer jobs and direct wiretap transfers (except that it does not tie up my wiretap client process). I can have progress reports and run it via backburner which seems a good and advanced job scheduler, but what other gains are there?
> I'm still not sure why you would want to reparent though...
Well, the simplest case being uploading to the library which is not locked and moving the uploaded clip to another one afterwards. As well as collecting all clips with the letters "xyz" in their name on a reel etc.
Getting around the clip library locking is not simple. No matter what, a call to the WT server will have to be made to create the new clip when the user is not using the library. I suggest a workflow with in and out boxes to allow the artist to have read-only access to clip libs you push to it, and vice versa, to allow the artist to write to clip libs from which you will pull media.
As for the difference between using WT to push job, and using the new BG IO tool, the big difference is that jobs are managed by a job manager (BackBurner), and can be queued and controlled better than a command-line tool or embedded operation. There are also image processing options. Finally, BG IO is arguably faster than what the average WT developer could achieve because disk IO, network IO, and CPU operations are all executed in parallel.