Group Admins

  • Profile picture of warusfel
  • Profile picture of T.

Spat

Public Group active 1 day, 6 hours ago

User group for Spat, panoramix, ToscA , and ADMix

spat.smpte~

Author 2 Subscribed Users |
Profile photo of DaveHunt
DaveHunt

Hi,

Any users of this ???

I’ve been trying it in Max 6.1, Mac OS 10.8.5. I haven’t yet tried Mac OS 10.10.

It seems to work well initially, but stops working after receiving LTC for about 5 minutes. I’ve been using LTC at 24 fps, various versions starting from 1 hour and 10 hours, via two proven audio interfaces and via sfplay~.

Max doesn’t crash or show any errors in the Max window. Re-opening any patch containing spat.smpte~ works again but stops after about 5 – 6 minutes.

Any ideas ??

Ciao,

Dave Hunt

August 17, 2017 at 12:34 #23399
Profile photo of T.
T.

Hi Dave,

Could you please save the LTC signal in a file (e.g. WAV) and send it to me ?
(also let me know where, approximately, smpte~ stopped working)

Thanks,
T.

August 18, 2017 at 09:09 #23400
Profile photo of DaveHunt
DaveHunt

Hi T,

To what address should I send the file ?? It is too big to attach to an email.

I was originally using a file which started at 09:59:55:00 at 24 fps. It was generated with a MOTU Micro Express, and has been used a number of times with differing hardware. I thought that maybe 10 hours was the problem, though it is in common use.

So I generated a new file starting at 00:59:55:00 24 fps. spat.smpte stopped working at about 5’20”. The 10 hour file stopped around the same time, though this is not consistent.

The main reason for looking at spat.smpte was that I needed to lock a patch to incoming LTC that would loop, probably without stopping. When using the MOTU Micro Express to turn it into MTC it would either freewheel over the discontinuity in value and continue past the loop point, or stop irretrievably. spat.smpte seems to be able to cope with this and pass on the correct time, but only for a short period.

Ciao,

Dave

August 18, 2017 at 14:42 #23401
Profile photo of DaveHunt
DaveHunt

Hi T,

I’ve tried the smpte objects under development that you sent.

So far they seem to work well, though I haven’t yet tried them with the video and audio files I’ve been using to check sync. This is partly because I have to go to Max 7 on Mac OS 10.11 and rebuild the patch I was working with along the lines of a Max 6.1 patch. This is bound to involve a bit of head scratching and a period to be able to concentrate on it.

I should be able to do that within a few days.

Initial comments:
It would be good if the smpte decoder could inform of the incoming frame rate via an output as a float, and put out the frame number (as a float or integer) like the previous version did. The latter is a fairly simple calculation, provided that you know the frame rate (currently buried in the object info).

Funny how LTC, having seemed to be disappearing a few years back, is now coming back into use particularly in “live” shows, rather than studio operations.

However, some are now wanting higher frame rates at odd float numbers to cope with what the video people are doing. None of this is in the specification, which may not be updated for some time.

Ciao,

Dave

August 19, 2017 at 17:51 #23402
Profile photo of DaveHunt
DaveHunt

Hi Thibaut,

That was quick, though I suspected that what I suggested might be fairly straightforward.

I’ll try it as soon as I can, but suddenly I’m busy and my ageing but useful MacBook Pro has just died. These things always happen at a bad time.

HD video seems to be going for faster frame rates, and some high end video artists are now making 50 fps content. Then they want to sync with multi-track audio.

If the movie has 25/24 fps LTC properly handled that’s probably good enough, and has to be at present. For movies less than 10-15 minutes, trigger and play is probably still good enough in most cases. But there will be those who notice when they think it doesn’t

Thanks,

Dave

August 21, 2017 at 19:04 #23413
Profile photo of DaveHunt
DaveHunt

Hi Thibaut,

I’ve had time to look at the latest version in a basic fashion.

spat5.ltc.decode~ does work, but it takes around 2-3 seconds to settle on the timecode rate. It seems to start at 20, then works its way up to 24.0001, when fed code at 24 fps.

With the previous version I had calculated the time in frames from the h, m , s, f outputs. This doesn’t agree with the value put out by the new version by a considerable number of frames, though sometimes it is close when ltc is stopped after a while.

Perhaps it is due to the first frames being at the lower rate ??

I have not had the chance to synchronise audio and video on two machines yet.

Ciao,

Dave

August 24, 2017 at 17:54 #23435

You must be logged in to reply to this topic.

Log in now