Feature request: query the clip file offset

[Mattijs]

Hi,

There is a feature in the right-click menu of the waveform view of a clip, called 'Set 1.1.1 here'. This offsets the waveform so that the start of the clip is different from the start of the audio. This typically enables a user to compensate bits of silence that precede the start of the actual audio in a recording.

In my current quest to synchronize a video file to an audio clip, a way to query this offset would be very convenient. Or does anyone know of a way to get this information by combining the info of the other parameters?

Please let me know if I am being clear enough or if I should include some screen shots and more explanation.

Best,
Mattijs

[gavspav_2]

I'm wondering if you could do something like:

create a loop or start/end points between the very beginning of the clip and 1.1.1 (think you can do this via M4L?)

Then check the length via the API and you should have the offset - at least in beats.

If you need it in seconds you could try toggling warp on and off.

Alternatively you could draw a sawtooth clip envelope across your whole clip and then have access to clip position.

http://www.digitalfunfair.co.uk/avsync.htm

[Mattijs]

Hi,

Thanks for your reply. I see you have been working on similar issues.

Unfortunately, when Loop is off, it is not possible to find out what the loop points are. When you query loop_start and loop_end in that case, they report the start and the end point of the clip instead.

I ended up doing the following:
- make sure the end point exactly matches the end of the audio file
- query the length parameter (which is always the difference between the start and end point
- recalculate the length from beats to milliseconds (the original bpm of the file needs to be known)
- compare this to the length of the video file (which has to be equal to the length of the audio file)
- the difference is the offset.

It would be much more convenient to just query the offset directly though.

As for the trick to draw a ramp that indicates the video position (thanks for the suggestion by the way), I see two possible drawbacks:
- the resolution isn't high enough (or is it, with the new live.param~? hm, 32 bits right? should be sample-accurate for a file of 29 hours long at 44100Hz? Interesting!)
- when using warp points, there will be sections where the ramp will not match the actual playback position. But then again, in the system I use now, warp points aren't an option either.

As a conclusion, dear Ableton / Cycling, to properly sync video (and light, and fireworks) to an audio clip, it would be awesome to have a live.position~ that outputs the current playback position in the original file of a clip!

Best,
Mattijs

[gavspav_2]

[quote="Mattijs"]

Unfortunately, when Loop is off, it is not possible to find out what the loop points are. When you query loop_start and loop_end in that case, they report the start and the end point of the clip instead.

- can you not just temporarily create a loop between beginning of file and 1.1.1?

It would be much more convenient to just query the offset directly though.

Of course you are right. +1 again for live clip position (position in the original unwarped file would be an added bonus)

- the resolution isn't high enough (or is it, with the new live.param~? hm, 32 bits right? should be sample-accurate for a file of 29 hours long at 44100Hz? Interesting!)

I thought I'd been using 10 bits and that it was enough for a ~10 minute clip at 25 fps. Cant really remember though - I'm guessing.

- when using warp points, there will be sections where the ramp will not match the actual playback position. But then again, in the system I use now, warp points aren't an option either.

This has kept me awake at nights. Currently I warp the video using Live which kills the workflow and means you have to use Quicktime (boo hiss) for export.

Somewhere on these forums someone posted on how to get the warp marker data from the .asd file.
Surely it is possible to write a max external that will extract this and then calculate actual clip position from warped clip position.
Here's a link to the thread that contains it:

http://forum.ableton.com/viewtopic.php? ... s&start=15

When you've got it all up and running please send me the link

[Mattijs]

- can you not just temporarily create a loop between beginning of file and 1.1.1?

I could, but that would involve a risk for the people I work with: if they expect their playback to just stop when the file has reached the end it shouldn't suddenly start at the beginning.

When you've got it all up and running please send me the link

Well, with the workaround I described above I actually do have it running relatively satisfactory. Without warp markers of course.. The only one who can give us access to that is probably cycling 74.

[Gregory Taylor]

The only one who can give us access to that is probably cycling 74.

Sorry, but no. If Ableton exposes this in the Live API, *then* you'll have access to it. The Live API in M4L will only work with what we are given.

[aarontrinder1]

+1 for LiveClipPosition... been trying to hack a way to do this (sync video with audio clips for triggering in the session view, retaining loop info, quantisation etc etc) for years and now it looked like it would be possible via M4L.. but no go still...

[ztutz]

Hi,

As for the trick to draw a ramp that indicates the video position (thanks for the suggestion by the way), I see two possible drawbacks:
- the resolution isn't high enough (or is it, with the new live.param~? hm, 32 bits right? should be sample-accurate for a file of 29 hours long at 44100Hz? Interesting!)
- when using warp points, there will be sections where the ramp will not match the actual playback position. But then again, in the system I use now, warp points aren't an option either.

The sawtooth envelope works well, by the way.

Now if we could only programmatically generate envelopes. <sigh/>

<pre><code>
----------begin_max5_patcher----------
553.3ocoUssbaBCD8Y3qfgmc8.XraZeq82nSGOxVqsUpXEijv0oYb91qt.DH
QfcSevxC6tZOm8HwgmiiR2It.pzjul7ijnnmiihbgrAhZeNJshbYOmnbkkhv
uE6dLcgO0YhDIUfKyAgnKrFtncwpIZsLYPFrohgbP6ZVdaPSU6Owviakvdsm
L4kqWlsH4Karqqysq4OrLK4msa4f.0J1ebHmmYR6CynNXML7SqG.onQ2g4p1
n9P5mpAOfooKZ+MBi9o6aRFgm7cAm10WE4LP2ZfxP5s14jsqQ6EyndwyNbRS
OzfbKfjcbXvfa3Kxzl95oPlc9bItFOBi9lOCLmI7FPbnKbW7g3qzPsaesp0X
xcoVf.5j+7kgpnwvUk9owSvvBpLWTld6UlCdG3Ay9dgHPQcmVyzf.h7HI3jP
pCbi8Ms5LSwZ6RvQQP6F0hOGbbHHJzDMSfa6QKDTbAd7Vzwh1bRGmg+x1C0b
zUPmTSX3AwjDTHofbpF6tQL4VU0.P4rJ2t8ouFG+5etUyM8603ooZGHeo6su
tIpHjwRwbFKkVyjMdikM2qwhhcbzIvPmlxvNMES4zX5EZtpa7ZNvED8sMb9H
p0Ha5d+XN6LrzcD8xjtxYyIdEVAakya9gxOfq7pvZU9Mzp+EIxUqYRw29gM2
.YiOV2ThF49N7Z4XxqyDETZF5dWdPMkip4DiRAbn3Uwn0BFpaof2W+cmg2Ki
JuCFs9+fQlGtF+W.kql9cC
-----------end_max5_patcher-----------
</code></pre>