21 Sep
2009
21 Sep
'09
10:51 a.m.
Paul Davis wrote:
2009/9/20 Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net>et>:
You're right that it's better if someone only will use applications like
Blender and Ardour. On my machine I don't have any sync trouble for
internal applications, but seemingly because of my hardware I've got
trouble to sync with external equipment, that's why I like the idea to
sync internal by JACK transport, especially because I don't have
external video equipment.
For video studios I guess SMPTE is the better choice. When I was working
with SMPTE I never had any trouble because of sync, it was accurate enough.
It would be clever to use JACK transport internal Linux machines, but to
have the option to sync any equipment by SMPTE.
Btw. Blender is less interesting for me, I would like to have sync
options for 2D animation software and video editing software and to be
honest, I never needed to use e.g. Cinelerra or Synfig in sync with
another video or audio application, but having this feature would be good.
Jörn Nettingsmeier wrote:
Half asleep I had a quick flip through the howto. It seems to add JACK
transport support to Blender?! If so, Blender could be synced to other
applications too, e.g. MIDI sequencers?! Anyway, I guess sync also
should be possible by using an audio track of Blender for SMPTE, but I
never tested Linux audio applications synced by SMPTE. Reading LTC,
SMPTE seems to be possible with Linux and IMO this should be the normal
way to sync an application like Blender or any other kind of video and
animation software to any audio and other video equipment, imagine you
want to mix 3D animations with "real" video recordings, by a Sony
Betacam, Fastmachine etc. and other common equipment. A SMPTE track
could sync to every equipment, hardware, software, video and audio,
anyway an interesting information. Thank you.
SMPTE is a low resolution time code. There is no reason to be limited
by frame rates of 30 fps when defining a synchronization protocol
between applications running on the same (or even two networked)
computer(s). JACK transport is sample-accurate, and as such is
thousands of times more accurate than SMPTE. even if the final
destination of the work done in blender (et al) is going to present it
at approximately 30fps (+/- 6), i can't see any reason to use such a
limited timecode for this purpose.
obviously, supporting SMPTE timecode is still a good idea, but it just
doesn't seem ideal for this purpose at all.