Can we get at the Live playhead info?

[gavspav_2]

Is there anyway of getting information about the location of the playhead in a liveclip.

ie send a value to M4L which lets us know where abouts we are in the clip at any given point in time?

Thanks

[Poster]

maybe have a look in the Clip-Operations.als set, in the Max5 folder?

[gavspav_2]

Well we can get start points, loop points and a playing flag so assuming we can get the tempo (sure we can) it'd be possible to work out.

Not sure how accurate this method would be (depends on speed of api requests).

Be nice to be able to get this info directly.

Or is there a better way?

[Machinate]

use a synced phasor? That should work - like a 512 bar phasor would give you a very lovely rising slope.

[Gregory Taylor]

Since Max's sense of "musical" time is derived from the Live
application, take a look at the Max transport object. I think
it'll be of some use to you.

You can use the live.path, live.object, and live.observer
objects to do things like setting tempo from within Max.

Copy this stuff (including the "begin" and "end" lines) to
your clipboard, and paste it into an open Max window in a new
opened audio device:

Code: Select all

----------begin_max5_patcher----------
571.3ocuV1sjaBBEG+ZySACSuL0QfXL16ZeMZ2YGixlvVEbDRaZ2Ye2KbPyZ
2MlOM4FX3.d3O+7v4vKSBvKUa4ZL5KnuiBBdYRP.XxYHncb.tJaadYlFVFNW
UUwkF7T+bF9VCXmFhzbCxvqpU+Ptl2v6VRoPxyUajv5nsFkapDxRtAbJo03S
JoQK9KGrEEF0ZtNyjuVHW8XCO230JYAwNMhF6VEJwOHMLB8va9WswzsAcdRT
.ZUs74OSlg6sqxrJXWwesQjUh9lprna55Ft1dfyLBkruBluvsoLZrqKpsA8f
6idcxDWyzqDojPTdoH+mn9z7JAGiw.VMKw0Q77ir3bHW7w.2Ef.I+2VW+ABX
PKQkizImlP8QIybc113Cdv6BT8lL+ol6cCdYlbEdJBi28g8XCic+fSo3W7P6
Ac8XAn34.flm55hIGIxfMDf.3LHfn2Y.YmvcB2GhnWPLDb6gwRaigNLhHChn
8hFxM.MOUprZ5ziPHgwowjEIGJ0Kjyf5y.6SfPiN+6QVkkYbwIvEp8BjngAx
kvhJtVmsh+g3jc0sPehLxAJTe8IHyCY9HEnPSuAAJCAGWBFj6lziVLMVzoMS
iuHju583QmjyfNfCfWn7tGAAp1Y++QlVsoIua66hQQuI7Bt1HjvaE5sH2Ord
KZsnnfK6WcsRTTqDRit6JVpq5DiD6uoQ2MZf2Wbxp0l8EQNhZc0vNG0dsZhc
CH3Upo2scCvIx8USImhln2++cjSgSjKTS1AuN4e.Ovz5hC
-----------end_max5_patcher-----------

[Gregory Taylor]

Oh - my colleague Emmanuel reminds me that one can also keep an eye on tempo using the live.observer object, since the Life Object Model stuff lists tempo as something that can be set and also observed (I'm so used to using the transport object that it remains a bit of a habit). here's how you'd do that using a live.path and live.observer pair (again, copy the code stuff including the begin and end lines to your clipboard and then paste into a Max patch)....

Code: Select all

----------begin_max5_patcher----------
560.3ocuVtsbaBCDF9Z3oXGt10CBL9Puqs212fNYxfgMF0BRLH4DmlIu6UZw
L9.XGbvkKPLZkP5e+zuj3MWGu0xcnxC9J7Kvw4MWGGJjMfy95NdEw6RxiUT2
7RjEEnP6MotMMtSSwClB+HKVrAAcl4AKJk.W.+j+LBwhT3kXcRloMtp4SEaK
3hbTSiKaevxJTYF9XMWJdrBSz0Za9r4S8m.L1L6K+8EvCGFJ4VcyX4uOJOkT
lb8u+R3plY8IoPKhKPpouUwiyguKySaZtzJStXyEm6ff5ZKOZ5sioh+WZLYF
cYi9tqqsXROw5S4RSRbUzbZRFzQRd4b7JoWzpY0oWn8UDw1figa8jpesDq+.
qViMF.vasY81qaJD7onvkLWroPRNO4OPFVg2.j5vIvlM.mPDgpEDupI081GH
vWLprE.zvZHeXtCVzmOwiVQliYqnT1mMM5rLukGgrFFKh2H.mbyYLSMpN6F.
TXG.Z.mQDsfLEATYDqkynEeH1Ll7QtVgUOiUcxnf9ZhB7GhIh18rplN998DR
2S.UfJU7FrEgJqjkXk9056stADw5.QgCFQKHDsr9b44WkPiBcLas.qI5QEpG
HbVN38XKNPn6.an9X1gHN+ufHAXieJvTxsUIMyPyNB3fJRQklKnee4nNEdRe
x3oon336mJ3okRtPuWCvCct50aIE1CIclt+eqI6sO.qOZhMdbZYO3j8VgwlS
e3Z235mHD7QqcmI7aSSlJu69O37cp+N
-----------end_max5_patcher-----------

[Machinate]

Gregory, do you have any neat tricks for showing us where we are in the currently playing clip? There's so much new stuff to touch upon in M4L I just haven't gotten to that bit yet.

[Surreal]

maybe something in here can help

Examples > M4L.Examples > LiveAPI > Abstractions > Helpers> look into m4l.api.clipoperationsscrubloop.maxpat

[tassock]

Count me as extremely interested in this feature. It's essential for the visual coordination I hope to do with Max for Live.

[travish]

yes, please provide convenient access to a clip's "current" playing position. it could be used for setting and jumping to cue points in a clip, looping clips without having to focus the containing track (clip.loop_start = clip.current_play_pos), clip pause, etc. also, it'd might nice to have an absolute clip length property, one that provides the clip's "real" length even when the clip is set to loop.

below is a device that attempts to provide a clip's playing position, using a technique used by a video processing plugin I saw here. Automate the 'mu' parameter, setting two point's: 0 at the clip's beginning and 18014398509481984 at the end. Or have a look at a this project: http://drop.io/baconvice/asset/mu-project-zip

Code: Select all

----------begin_max5_patcher----------
1562.3oc6a11aihCD.9yo+JPHse4tt4rAya22t6uwpUQjfaB6B3HrS21a0d+
1O+BjBo.1zPoDoSpJIFC3YdX73Y7P+4cqr2RdBSss9SquXsZ0Oua0J4gDGXU
U6U14wOsKKlJOM6cj7bbAy9dUeL7SL4wiOwH4wLrUNttuGHELZ5+fE8CAqAU
GNMQdAjse6yn5S8XLa2gzh8aJw6XJwwAHtDKGTn3q.n3SH+2Ves5ZJNkmVjg
YR4B1XLKhykio8eUlFmY82jrD6WtFxIV8EADG7W2cm3i6MT+Kv+fK4uR8o3L
tjaAq6PMJrmOhUZi813h812aYaeV90iGX.X..I4BzWRITvv3w4sfGmoCOLqs
VYSKa7Q5XSn7SWm0dStkyaAM4XJMdO9Ur4XI4Htj8r0gX5lcYoG6kSihOdQZ
scfNhuhPJCoI01ANc1NYoOhWS1RwkOhK6mMi09wKPKeb8ktdbVHys5y.ZOgQ
rDTZCEyrXkw69N0BXILk1PyHLdiIxjxWGxP.ksTzMfIEWGNLr4znMoz5RxWN
Wy68XwL22.d5awbZ5SLLuiCTyWKGhBOq8kXJ+piYojhFDHxuABBeEB5fYnpX
.TSA65ZZLRMI2GSrA8gys3X1nHouFR549BIUNozQRWDpAI65ZtMHYb4n.IRC
HgMAIxDP5nhpnFjnENH6wA3uOPjpobtOFudngBRE0JJdcwh8QutveX43MYbw
Mx.t3ftE3xm35HX5.SnAfQ8kaz6PrWSHXJImJRllfqbCzSEXf+s.U9Mg4x5d
wxCYj3wYw3XBa7TdjCV1rYJ8753ZqeE+aCOuexBMcXww.rba33cRsVf15Cq4
VYc5oyZAFZ.VtMrV39cmRutPO8yifNfEEYjY1mvuu02xGiKOOf4mFLe+KHTq
4NZxiPBAvKYD3DzfDzCjev0rs3RYT7MOZkjAFvBD5+p7MZc26Luhiwk7aMCW
tAWDuMCeQhHM2HpZwI9QbxlXFqLc6IF9keQqncEtEDM6Dl7P8gqOdyAMKs36
Bci1P4ZcB4jD9eRwB0Q2oEOPjv2tiNIkIsHYqNOUjxnseX2pe5QLNIKMuuqm
xvG6UpwOcjTHRKUPy08N7rmaA71JN2ZU1WH.hbiB8.QnPXTHpyaWN+QqTX5r
2T9fIrzqs.qMIZcR013CbCZXizIRNPJYudNzE2oGSooCbSDOvGilGWTPplkc
dn6ZfyHE60Hahg9LFUcKcpT+0RsBGtCsaqvH2EXIN5a6VIwIJBLDdFAZPFTW
L4NF58NrQqSa5iLrUFtXutshdLvw.6lpxF5G9NvmIszFXlV7LFzDX.ZfM2r4
O9RXbEU8wZxplHJTO3pp8SXzMQ4D+lP7mDzDYfMkZC28V36ay6SYw7.5AzBq
tX8vmiYm1yuy+au3glxCFIS.npeMBLMzlV3WE1uz9QU7mk665gfRoEuOPBpE
RvnEFjTI9MztUb+3C.B1XR0PEaMDL9hsphozCLiU1p9oAOkSNHpxhX4.aGyp
GqB1iqdr+OreEr0YYCQMfsyXpY6BD1RQfuvawkuElR0Pb71OAnjSk6pQbcVh
VvyZRBlxRKNqHe4kXTZbRGRSRvEM23o7zjiD9SLZqMcBBTbqZc41sTn2Aox8
Tzx5qcZEYplHbooUSjpKXLZRnP9BCTEUzotwUJqRfBzQ8QJqWqLEXhLEMuxT
nAxj7A+7ISWXB0CmBlUYBZfH4L6RDz.IBNeRjndDZojrdNigSt7Eu4NEbfpn
ehBN25pkWSL9kkkaNet5.MRp.yrT4ZjTMudTMzhyw4MYwAUuz9Mac0TzwH40
cQRwfqghHPzzQQSVHU995LmTz0LoJblkJi7w4FMyRkIgmIewEmyXg7MZ4KuQ
FpNnp3OpxD66sNnil.nJ0T0KGkn00h3KfWOZi2buLhAQsbo+H8HFADH1E3px
hTUI9Vs39Ta5KWz5ZUEOiLWD+KGLm.VNdZIr+HkJWI1BUafWP8uuVY8BonOB
Ny9l7Mhfh+6jFia.2lonCAAczRkvd.XpxW+RxMjlLidYMyuzLGHYfIREZjqc
qlo.q7.EVUq6lsT6EY0RDt9SvibiBBI3Z75ya7q69O3nZIrK
-----------end_max5_patcher-----------

[gavspav_2]

I have previously been using a rough approximation of the above technique (documented here: http://www.digitalfunfair.co.uk/avsync.htm) using Pluggo and/or Plogue Bidule.

Whilst you can sync video to Live and retain the freedom of the Live interface I found it limited because:

1)the passing of parameters to a plugin happened in a low priority thread and was therefore not very constant.
2)It eventually mashed my head up trying to manage all the clip envelopes, plugins and midi or osc data flying around!

Depending on your audio buffer size you can get 25 values per second on 4 individual tracks but there is no guarantee that these values will be spaced evenly in time so the synced video may jitter about a bit. This could probably be sorted out with a bit of interpolation/code.

It would be good not to have to draw these clip envelopes (which incidentally I havent even sussed out how to do in M4L yet so thanks Travish for showing me its possible!)

Also wondering if the thread priority/timing is any different in M4L?

Idea - Perhaps it would be possible to write a M4L plugin on a midi track. In Live ramp up some PitchBend info in a similar way to the above.Then have the midi info relayed to an external app for video and also to the Max Instrument driving the playhead of an audio clip. Can you play audio in a M4L patch in a midi track? Not sure.

Anyway +1 for getting the Live Playhead info in Live. This would be a far better solution

And after that +1 for getting info about time position in the original pre warped clip! I want to be able to warp the audio part of a video and play the corresponding visual element without having to warp the video!

[travish]

I have previously been using a rough approximation of the above technique (documented here: http://www.digitalfunfair.co.uk/avsync.htm) using Pluggo and/or Plogue Bidule.

aha! that's the one, that's where i saw the technique...

It would be good not to have to draw these clip envelopes (which incidentally I havent even sussed out how to do in M4L yet so thanks Travish for showing me its possible!)

nono.. you still have to draw the envelopes manually..

[Gregory Taylor]

If you've got any questions about this stuff, you can and should always look at the current documentation for the Live Object Model. While it's a work in progress, the easiest way to navigate to it (at the moment) is from the live.path or live.object or live.observer refpages - click on the link that reads "The Live Object Model."

While bits of it are currently incomplete, it is the list of everything that's known at the moment, period. The clever reader will notice that the there are several ways to get the "current time" - they're listed under the "Song" stuff. There's a gettable/settable/observable property called current_song_time which will report the current time in milliseconds (you'd need to add some logic if you want to convert that into bars/beats/units data). Looking further down, it appears that the Live folks had pity on you and provided another way to get the current time - the function get_current_beats_song_time. It's not observable, but it does report the current times in a more "Live like" Bars/Beats/Sixteenth/Ticks format - you'd need some Max logic to send the "call get_current_beats_song_time" message and some stuff to unpack it, etc.

*Or* you can use the Max transport object to return the playback position information. That information would have to be massaged very slightly (since the transport object outputs bars/beats/ticks instead of bars/beats/sixteenths/ticks). And you can also simultaneously grab data about time signatures, etc. It's a one stop shopping object.

One of the things that we'll need to get used to is the idea that the current API deals with the idea of "time" in a couple of different ways - sometimes as milliseconds, sometimes as "beats" (which depend on the time signature), and sometimes as bars/beats/sixteenths/ticks (as the above example suggests). This is almost certainly because those measurements are used for different things. But there is a way to get at some of that data, even if one might have to massage it a bit to get it into the form one desires. Happily, there are nice Max objects that can be pressed into service for that purpose.

I'm not completely certain about this, but I would *think* that using the transport object might be smarter, since Max might be refreshed more regularly than the priority queue that updates stuff from the Live API. I could be wrong, but I don't think so.

[travish]

While bits of it are currently incomplete, it is the list of everything that's known at the moment, period. The clever reader will notice that the there are several ways to get the "current time" - they're listed under the "Song" stuff. There's a gettable/settable/observable property called current_song_time which will report the current time in milliseconds (you'd need to add some logic if you want to convert that into bars/beats/units data). Looking further down, it appears that the Live folks had pity on you and provided another way to get the current time - the function get_current_beats_song_time. It's not observable, but it does report the current times in a more "Live like" Bars/Beats/Sixteenth/Ticks format - you'd need some Max logic to send the "call get_current_beats_song_time" message and some stuff to unpack it, etc.

unfortunately, the song time properties are just that... the time in the song (i.e. the arrangement) and not a particular clip. the playhead in the clip could be scrubbed back a bar (call move_playing_pos -4.0) but the song time will continue to move forward.

*Or* you can use the Max transport object to return the playback position information. That information would have to be massaged very slightly (since the transport object outputs bars/beats/ticks instead of bars/beats/sixteenths/ticks). And you can also simultaneously grab data about time signatures, etc. It's a one stop shopping object.

i haven't look at the transport object yet but i suspect it still operates on the overall song/arrangement timeline and not a clips (relative) time. i'd like a transport object for a clip, i guess.

[Gregory Taylor]

Ah. Then it's not there at the moment, and it probably won't be there in the first release
unless there's a particularly byzantine way to do it that involves things that are not
documented as of this time.