SYNC w/SM ION and VVTR

[georgia]

Anybody have any experience with the Soundmaster ION working ( or not ) with the VVTR software? I'm having a bit of sync "studder" with out ION atom and Bob ( from Soundmaster) is pointing a finger at VVTR. Any help on configs would be welcome.

cheers
geo

[minister]

Know what the Soundmaster is, no direct experience with it.

Sometimes VVTR sers (hunh? why can't i say ser? i have to say studder [sic]? to move or act in a halting or spasmodic manner... is spelled with an 's' a 't' a 'u' then 2 't's and an 'e' and an 'r'...) when you are not going out the correct Video Output assignment.... Make sure your pixel dimension and rate match the QT. or, it is set to default.

[kk@jamsync.com]

Originally Posted by minister

Know what the Soundmaster is, no direct experience with it.

Sometimes VVTR sers (hunh? why can't i say ser? i have to say studder [sic]? to move or act in a halting or spasmodic manner... is spelled with an 's' a 't' a 'u' then 2 't's and an 'e' and an 'r'...) when you are not going out the correct Video Output assignment.... Make sure your pixel dimension and rate match the QT. or, it is set to default.

Wow, another wacky no-no parser. Let's see, can I type "serer"?

NO!

So it's "", huh?

Oh my word, how freaking British this thing is. To wit: Urban Dictionary: Tutt

And of course, since it's w/in a tinyurl, it allows it. Oh, Matsushita...

[georgia]

LOL... thats why i said Studder... :) ok no prob, i'll check that. But i'm getting a lock tally drop out regually from the VVTR on the Soundmaster monitor page. ( like every couple sec or less ) the pix keeps running and stays in visual sync, but I know the lock is not solid. soundmaster IOn and VVTR doen't seem to like each other. I'm still working out the kinks.

cheers
geo

[kk@jamsync.com]

Originally Posted by georgia

LOL... thats why i said Studder... :) ok no prob, i'll check that. But i'm getting a lock tally drop out regually from the VVTR on the Soundmaster monitor page. ( like every couple sec or less ) the pix keeps running and stays in visual sync, but I know the lock is not solid. soundmaster IOn and VVTR doen't seem to like each other. I'm still working out the kinks.

cheers
geo

You don't have a couple of different sync outputs (like MTC) slamming the input, do you? I've definitely heard of some accidents with PT.

Also, could one of the apps not be happy with the QT player version?

Just musing.

[minister]

Georgia,

How is the Soundmaster feeding VVTR? The "Lock Tally Drop Out" is a Soundmaster warning. When this happens, do you see the "resync" box light up on VVTR? (it is in the same area as the Frame Rate etc. boxes at the top)

[georgia]

First off Hi KK, love to meet sometime! Are you in LA or NY? Anyway, yea, i've checked that most definitly only one SMPTE TC stream.. And Minister, those are the exact symptons that are occuring.. Things lock up.. run for a second or so and then start do do the lock/drop/lock dance.... They run close to sync. You can sort-of-work but I need to get this fixed. That's why I'm asking anyone about config data. With zero support from The VVTR folk i'm trying to ork it out on my own and with the help of the SoundMaster Ion guy Bob who is trying his best, but keeps pointing to VVTR.

cheers
geo

[minister]

are you getting the "resynch" light?

i assume TC's match?

i would look at your computer and make sure it is running smoothly. Run Disk warrior on all drives.

Have enough RAM?

another thing to do is toss the VVTR prefs. then reset them.

OH : do you have a Sync I/O? try running the MTC out of the HW port from there into VVTR to see how that runs....if it is good, then i would suspect the SoundMaster. if it isn't, then.......

[kk@jamsync.com]

Originally Posted by georgia

First off Hi KK, love to meet sometime! Are you in LA or NY?
cheers
geo

Hi Georgia,

I'm in Nashville! It's all indies, commercials, and music videos for us (TN has the worst film package for producers: horrible sales tax, etc.). I used to live in Boston and I would go to NY often. I have to get my NY "fix" a couple of times a year if I can.

I spend time in Santa Fe and would like to open up a small offshoot studio there. New Mexico is beautiful and it seems to like film people.

But, I get up to NY and out to LA and SF now and again, so when I'm coming to NY, I'll shoot you an email. I'd love to see your studio!

Sorry you're having trouble with your stuff. I'm sure you'll get it figured out. I'm appalled that Gallery isn't more supportive. Shame on 'em.

[georgia]

H kk.. cool drop by anytime!.. Minister.. The systems fine.. Been though all that 2 months ago. Evertything is perfect in the mac side. Soundmaster Ion Bob, says all is well with the ION/Atom config.. so its' either on the VVTR side or they simply are not communicationing well. I have some work arounds, but i'm looking for a new video playback option if I can't get this resolved in the next week or 2. It seems to me it should and probably is a really dumb Oper error thing. Some config is set wrong. I can't believe the VVTR system would be this flaky internally. I'm just sending clean timecode ( other system lock perfectly like the System5, System6000units, decks, etc) just the VVTR won't sync cleanly. any thoghts are greatly appreciated.

cheers
geo

[minister]

Georgia,

Did you read the part where i suggested sending MTC from another source?

Can you answer my question about the resync light?

Increase Sync tolerance to 2 or 3 or 4.

Did you try trashing the VVTR prefs?

I asked you about a wrong setting in video output assignment, this causes the sytem to "get jiggy". Once set right, the video passes properly. Did you double check that?

I know that some people have had problems with VVTR. I have not. I have set it up on 3 different setups here and several new systems in town. Whenever I have crashes or studd-er-ing, I do maintenance on my system and it fixes the problem. Not everything works for everybody.

You can also try the Second DVI port out of your PT Mac. It certainly is cheap. And can work fine.

[bernhard]

Hi Gerogia,


try to vary the following VVTR seeting :

- increase "Sync Tolerance"

- "Use Incoming Timecode for 9-pin time"

- "MTC Overrides P2 transport"

I found 9-pin behaviour only reliable with genlocked Video Hardware


My setup at the moment is:

VVTR plays video (mostly DVCProHD) to Videoprojector via DVI.

ColinBroad SR-4 controlling Nuendo Timebase via 9-Pin

Nuendo conneted to Timebase via USB and System link

VVTR reads MTC and MMC from Timebase MIDI out.
(VVTR Preference "lotcate to full frame MTC")

so VVTR follows Timebase instantly, while Timebase is a reliable 9-pin slave (genlocked)


Here is a short explanation of the VVTR 9-pin Parameters (just in case...):
----------------------------------------------------------------
9-Pin Preferences

This page is a comprehensive description of what each specific preference in VirtualVTR and VirtualVTR Pro will do. It does not offer overall guidance on particular setups.

In most 9-pin control scenarios, you should use a house-sync genlock to ensure VirtualVTR's frames are clocked out in sync with your controller, and that it maintains perfectly drift-free playback at all times.

Emulate 9-Pin via Serial port
VirtualVTR has many unique capabilities, and perhaps one of the most powerful, is its ability to emulate a 9-pin video deck. Although this may seem a simple task, in fact it's not. The 9-pin protocol is a loosely defined spec, which is interpreted differently by various vendors. This can result in a variety of compatibility levels between various devices. As the application becomes more complex, so the compatibility becomes tested. Basic transport commands are generally compatible between all devices, but synchronisation and status protocols tend to vary. Gallery have spent two years optimising the 9-pin behaviour of VirtualVTR and result is a protocol which provides very good overall compatibility, with the ability to tweak various parameters to improve compatibility in challenging scenarios. This preference turns on the basic 9-pin slave engine.

General Information about 9-pin Compatibility challenges
As discussed above certain setups require more parameter tweaking than others. Most common setups require no changing of the default parameters apart from selecting the appropriate serial port. However, since VirtualVTR is often pressed into heavy service in some hazardous locations such as Film sound mix stages, it includes extensive 9-pin flexibility to make some of the hairyer setups operational. Most of this work is NOT to make VirtualVTR play pictures in sync (this always happens), but in fact most of the challenge is convincing the 9-pin controller that they ARE in sync, via the difficult 9-pin protocols. Since the QuickTime timeline is abstracted from the physical video frame outputs, it tends to work in a more 'buffered' and 'lumpy' manner, reading lots of frames from disk in one go, and allowing the video card to trickle them out smoothly. This can lead to a 'lumpy' interpretation of what the currently displayed frame is. Normally this is not a problem, but in extreme cases, it can be a challenge. Most of the parameterrs are not affecting video playback at all, they simple tweak how the video playback is represented to the controller via 9-pin. Do not feel afraid of the array of preferences available for 9-pin since you will probably never need them. However, when you do, Gallery tech support will be able to advise the best combination of values. Meanwhile, here is the detail of what they do.

Serial Port
VirtualVTR supports any OS-supported serial ports, including USB Serial adaptors like Keyspan, and built-in serial ports, like those found on DeckLink video cards. Select the port to use with this pop up menu. Note that in OSX, we have found the motherboard serial port substitues like stealth and gPort to be less reliable than other solutions such as Keyspan. In OS9, the opposite situation prevails.

Serial Latency
This is an extremely important pref for OSX serial port users. The 9-pin specification imposes a limit on the time window available for a slave device to respond to a query or command from a master. This time window is actually shorter than the default serial delivery window in OSX. Hence, with this preference turned OFF, some controllers may not recognise VirtualVTR as a valid device because its replies are not arriving within the time window it expects. In most cases, you should turn ON 'serial latency' (reduction) and set the value to somewhere between 2 and 5 milliseconds. This tells the OS to deliver incoming serial messages promptly so VirtualVTR gets plenty of time to reply to them before the controller gets upset.

Use Interrupt Timer / Use Serial Thread
As previously discussed, it can be difficult to acheive 100% compatibility with all 9-pin controller, and as such, VirtualVTR offers several modes in which to operate it's serial communications. The first mode uses a polling interrupt timer, which is a brute force mechanism to constantly check if serial data is incoming, with the timer frequency set to ensure that data is handled promptly, but not so high that it swamps the CPU by spending all the time checking the serial port. A better way to handle serial communications is by setting up a dedicated 'thread' which runs alongside the VirtualVTR video subsystem and which handshakes the serial port, waiting patiently for new data before processing it. This serial thread can be given a priority, which determines how important OSX should consider it relative to the video playback tasks in VirtualVTR. In extremely taxing 9-pin control systems, you may need to balance the serial thread priority with video playback performance. The very best way to do this is by using a Dual processor mac, since the OSX multi threading will work much more smoothly on these systems. You can also mark the serial thread 'timeshare enabled' to allow the video subsystem to interrupt the serial thread when it needs the CPU urgently. Fortunately, most 9-pin setups work perfectly well with the default settings of VirtualVTR Preferences, with a serial thread and 2msecs serial latency. However, its nice to know that all this is tweakable should you encounter a particularly demanding setup. Call Gallery for advice on specific settings for your scenario if you encounter problems.

Improve 9-pin timecode linearity.
if your 9-pin controller is reporting repeated status timecodes from VirtualVTR, you can enable this preference which will attempt to 'even-out' timecode report linearity. Note that even if the timecode reporting is 'lumpy', it is likely that video playback is completely smooth. Unbalanced CPU loading can lead to different priorities in the subsystems which play video and which report the current frame via 9-pin. This is only really an issue in very tight sync scenarios such as 2-pass DVD encoding and linear Video edit rolls. A faster Dual CPU machine will generally help here, also, and for extremely taxing setups (such as Sonic DVD Creator 2-pass encoding), you should use Gallery's P2Plus hardware 9-pin interface which uses a dedicated processor to manage the 9-pin comms.

Use Callback for Timecode calculation.
This pref is related to the situation described above. It uses a Quicktime callback mechanism to report passing frames for more defined serial frame edges. It can help satisfy some machine synchronisers, such as the SoundMaster Atom. However, the way it works is not very compatible with compressed video sources, particularly hardware MotionJPEG (MJPEG). If you are using MJPEG, you should not use this pref. if you must use this pref, use a fast CPU, and also enable 'Echo On' in the Video Output Assignments for the 'mjpa' media type.

MTC Overrides P2 transport.
Most 9-pin protocol problems with multi-machine synchronisers occur because the controller does not recognize that VirtualVTR is playing back in sync. Typically, the video really is in sync on the monitor, but because of CPU loading situations, sometimes this fact is not clearly indicated to the controller, mostly because the reported timecode passed back from VirtualVTR is not totally linear (ie. it is reported with some lumpy variation in response time, or with repeated or skipped frame values). Often in these situations, the machine controller is actually generating LTC as well as controlling connected machines. VirtualVTR contains an extremely good chase lock synchroniser, and in practice it is much faster to have VirtualVTR lock to timecode, than it is to allow a machine controller to slew VVTR into lock via 9-pin. To allow a hybrid setup where playback lock is handled by VirtualVTR by chasing the controller generated time, but where jog / shuttle control is required in non playback modes, you can use this preference. Essentially, it tells VirtualVTR to behave as a normal 9-pin deck when receiving basic locate, jog, shuttle transport commands, but to switch modes as soon as it received MTC, instead locking up to the MTC, and ignoring subsequent slewing commands from the controller. Shortly after VVTR locks to MTC, the controller will realise that VVTR is now in sync, and thinks its own slew commands were responsible. During synchronised playback, VirtualVTR continues to return status to the 9-pin controller. When the timecode stops, VirtualVTR reverts back to a well-behaved 9-pin deck for jog etc.

Use Incoming Timecode for 9-pin time.
As an extension to the situation described above this preference adds excellent timecode reporting linearity. Whilst the VirtualVTR timecode synchroniser is ensuring that the picture is played back in sync, this pref allows the 9-pin subsystem to ignore the (potentially lumpy) internal representation and instead simply 'echo-back' the timecode values sent by the controller, as the current reported position. This typically means the controller is hearing back exactly what it wants to hear to recognize accurate sync, whilst the VirtualVTR chase synchroniser is ensuring that accurate sync is what you get. This can be useful for setups with JSK synchronisers, and SoundMaster Atom systems, and any other synchroniser which can generate LTC during synchronisation.

9-pin ID
VirtualVTR can identify itself as a variety of different VTRs. Although this does not affect the way VirtualVTR behaves, it may affect the way the 9-pin controller treats VirtualVTR. This preference allows you to choose the status returned by VirtualVTR when requested via 9-pin.

NOTE.
In all cases, if your 9-pin setup is not performing, you should consider adding the VirtualVTR P2Plus hardware 9-pin interface which shifts the 9-pin protocol load to a dedicated CPU in the interface, and should keep almost any controller happy whilst VirtualVTR concentrates on playing the pictures.
----------------------------------------------------------------

cheers,

Bernhard

[georgia]

sweet! thanks for the info! helped alot, the system is now running well enough to work, and i'm still experimenting based on your response..
I apperciate the help!

cheers
geo