API -Can't set Start Offset in take if Stretch Markers

[planetnine]

It seems that you can't use the API command "SetMediaItemTakeInfo_Value(take, "D_STARTOFFS", offset)" to set the "Start in source" parameter if there are Stretch Markers in the take.

With a simple example (thanks mpl):

offset = 0.40
item =  reaper.GetMediaItem(0, 0)
take = reaper.GetActiveTake(item)
reaper.SetMediaItemTakeInfo_Value(take, "D_STARTOFFS", offset) 
--reaper.UpdateArrange()
reaper.UpdateItemInProject( item )

This will set the "Start in source:" box in Media item properties, Take properties to 0.4 seconds, but not the take itself, and leave this 0.4s as an offset between the box and the actual take.

This issue occurs even with one unstretched SM in a take, and removing it enables the API function again and also re-synchronises the "Start in source:" box and the actual take display.


REAPER 5.23x64, Win7-64Pro.




>

[planetnine]

I've duplicated this on two machines, on XP32 and on Win7-64Pro.



>

[mpl]

offset = -0.10
item =  reaper.GetMediaItem(0, 0)
take = reaper.GetActiveTake(item)
reaper.SetMediaItemTakeInfo_Value(take, "D_STARTOFFS", offset) 

for i = 1,  reaper.GetTakeNumStretchMarkers( take ) do
  retval, pos, srcpos = reaper.GetTakeStretchMarker( take, i-1   )
  reaper.SetTakeStretchMarker( take, i-1, pos-offset, srcpos )
end

reaper.UpdateItemInProject( item )

[planetnine]

So, looping through the SM indexes, reading the SM positions and writing-back, setting them to their exact same positions jogs the start-offset write to take effect?

ie, effectively refreshing all the SMs in a take?



Was this something you stumbled on or a known workaround? I'm presuming here that this is not an intentional functionality?

Well this will unstick my workflow jam, thank you, but it does seem a bit of a bodge fix for what must be a bug..?


Has this been know about before now? I did a Google search on the forums and didn't spot the same issue.

Thanks for finding this/pointing it out, mpl. Could we have a proper fix please, Devs, -while you're tinkering with the SMs?




>

[mpl]

I discovered these things while coding quantize tool. Well, maybe you are right. Current behavior is enough for my needs.

[planetnine]

Thanks for your help mpl, I've got there in the end.

Please devs can you fix this API SetMediaItemTakeInfo_Value function for "D_STARTOFFS", as the workaround can get really unweildy -if you move the start offset in a take with stretching, the start-offset is in source time, but the P-move to refresh the SMs (and make the offset follow the F2 start offset) is in item time.

Surely this non-updating of the Stretch Markers' parameters by this API function is a bug?

Many thanks, in anticipation...




>

[Justin]

Yeah, I suppose this API should report/adjust the effective start offset when stretch markers are active. Some day... for now use mpl's lovely workaround code (FWIW that's what the API function would have to do internally as well...

[amagalma]

Originally Posted by Justin

Yeah, I suppose this API should report/adjust the effective start offset when stretch markers are active. Some day... for now use mpl's lovely workaround code (FWIW that's what the API function would have to do internally as well...

Maybe 5 years later, aka now/soonish, is "some day"? :P

[amagalma]

Perhaps a new API, that would work like when one types the offset in the Item Properties window, would be the best choice, in order for existing scripts, that use the mpl work-around, to not break.