No internet connection
  1. Home
  2. Ideas
  3. PT SDK Ideas

Request: Assign 'Samples' as default input to Timescale parameter of sf.app.proTools.getTimelineSelection()

By Dustin Harris @Dustin_Harris
    2024-02-02 15:26:22.679Z

    Absolutely zero priority request because I'm being needlessly pedantic here, but it seems that the sf.app.proTools.SetTimelineSelection method can only accept Samples as the time format, but sf.app.proTools.GetTimelineSelection method returns BarsBeats if no input is passed to the Timescale parameter... for consistency's sake I'd love to see the default input be 'Samples' so the timescale doesn't need to be explicitly specified when using the SDK to get and set selections :)
    (proceeds to hide under desk)

    Reply1 Like
    • 11 replies
    1. Christian Scheuer @chrscheuer2024-02-02 17:43:58.263Z

      it seems that the sf.app.proTools.SetTimelineSelection method can only accept Samples as the time format

      I had the understanding it would support all time/counter types?

      Noted on the default for GetTimelineSelection though.

      Reply1 Like
      1. Chris Shaw @Chris_Shaw2024-02-02 17:53:05.307Z

        It does - see below…

        Reply2 Likes
        1. In reply tochrscheuer⬆:
          Christian Scheuer @chrscheuer2024-02-02 19:44:20.046Z

          I'm changing the default for "get" to be samples in 5.6 - thanks for flagging that. It was definitely never intended to default to bars|beats, and I think the regression in existing code should be minimal.

          Reply
        2. In reply toDustin_Harris⬆:
          Chris Shaw @Chris_Shaw2024-02-02 17:47:56.698Z

          Hmm, on my system sf.app.proTools.setTimelineSelection takes whatever format I throw at it.
          Change the timeScale in line 3 below to check it out:

          sf.ui.proTools.appActivate()

let getCurrentSelection = () => sf.app.proTools.getTimelineSelection({ timeScale: "TimeCode" })
let originalSelection = getCurrentSelection();

log(originalSelection.inTime)

//Return to zero
sf.ui.proTools.mainWindow.transportViewCluster.groups.whoseTitle.is("Normal Transport Buttons").first
    .buttons.whoseTitle.is("Return to Zero").first.elementClick();

sf.wait({ intervalMs: 500 })

//restore selection
sf.app.proTools.setTimelineSelection({
    inTime: originalSelection.inTime,
    outTime: originalSelection.outTime
})

          Changing the main counter doesn't seem to have any detrimental effect either

          Reply1 Like
          1. Chris Shaw @Chris_Shaw2024-02-02 17:49:22.053Z

            It also works if you don't specify a timescale in line 3

            Reply1 Like
            1. In reply toChris_Shaw⬆:
              Dustin Harris @Dustin_Harris
                2024-02-02 17:53:27.410Z

                Oh interesting! I had a fail with a bars|Beats type. let me find the code and try again...

                If @Chris_Shaw is right, delete my whole post 🤣

                Reply
                1. In reply toChris_Shaw⬆:
                  Dustin Harris @Dustin_Harris
                    2024-02-02 17:58:31.739Z

                    OK I think I figured out why. MY session return bars and beats with no parameter input, and this is what my current in and out times are:

                    -9999| 1| 547, -9999| 1| 547

                    and setting those in and outs in the selection yields this error:

                    Exception of type 'SoundFlow.Shortcuts.ProToolsAggregateErrorsException' was thrown. (scratchpad: Line 6)
    Multiple errors:
*  PT_InvalidParameter: Parameter InTime is invalid. Unsupported time format '-9999| 1| 547'

                    Report as bug?

                    script below:

                    const {inTime, outTime} = sf.app.proTools.getTimelineSelection();

alert(`${inTime}, ${outTime}`)


sf.app.proTools.setTimelineSelection({inTime, outTime})
                    Reply
                    1. Dustin Harris @Dustin_Harris
                        2024-02-02 18:00:25.729Z

                        and for reference I imagine this is the result of my usual reconform process of having a 0 hour session start, setting the session start to 10hrs while keeping relative position, then setting the session start back to 0 hours while keeping timecode placement, which I think is resulting in 'bar 1' moving to 10:00:00:00

                        Reply
                        1. In reply toDustin_Harris⬆:
                          Christian Scheuer @chrscheuer2024-02-02 19:42:32.255Z

                          Hm, that's very interesting. If you manually provide the bars|beats string and you format it so that there are no spaces, does it also fail? Is there a chance that the bug may be that PT doesn't accept negative values for bars|beats? It would be great to isolate it to that case, so we can forward that bug report to Avid.
                          It would be good to know if it's only a problem with -9999 or if it also would fail with bar -1, for example.

                          Reply
                          1. Dustin Harris @Dustin_Harris
                              2024-02-02 19:44:11.841Z

                              Great points, and sorry for not narrowing it down before posting; I'll mess around with it and see if I can get it more specific :)

                              Reply
                              1. In reply tochrscheuer⬆:
                                Dustin Harris @Dustin_Harris
                                  2024-02-02 19:49:13.882Z

                                  Update: the spaces work, it's the minus sign that kills it.

                                  This works

                                  let inTime = "1| 1| 001"
let outTime = "1| 1| 001"

sf.app.proTools.setTimelineSelection({inTime, outTime})

                                  This does not:

                                  let inTime = "-1| 1| 001"
let outTime = "-1| 1| 001"

sf.app.proTools.setTimelineSelection({inTime, outTime})
                                  Reply
                            ReplyAdd progress note