Issues with hyperdeck: Goto Clip (name) function

[Rodderrick]

I'm currently using companion to control the playback of clips from a Hyperdeck mini recorder. I have assigned individual clips to separate buttons which directly play and loop the clips when activated.

I have re-named each clip on the SD cards so that I can easily select them by using the "hyperdeck: Goto Clip (name)" function. This function works ok until new clips are recorded onto the SD cards. Whenever a new clip is recorded, the buttons no longer activate the correct clips.

It appears that the "hyperdeck: Goto Clip (name)" function is retrieving clips based on their position on the SD cards and not by their actual file names. This creates a problem when new clips are recorded onto the SD cards. When new clips are recorded, they are mixed in with existing clips and this changes the order in which the clips appear on the cards. This results in the wrong clips being triggered.

Is there a way of changing the "hyperdeck: Goto Clip (name)" function to retrieve clips based on their actual file name and not the order that they appear on the SD cards?

Regards, Rod

[LYMPIA]

Indeed, such retrieve function by clip name would be great ! Even though it would be tough code-wise to get instance feedback based on the same variable. But this would be nice indeed.

[sphlabs]

The Hyperdeck protocol does not, in and of itself, support targeting a clip by name. The companion module is trying to get around this by building a dictionary of file names for the user, but underneath it is storing the clipID and using that when the action is triggered.

This obviously causes issues when there are clips on the deck with non-standard names since, as you have discovered, newly recorded clips can result in a change of clip order (Hyperdeck sorts clips by name, so if all clip names are auto-generated and sequential this shouldn't happen).

The code, as written, doesn't account for the possibility of the clip order changing. Fixing this will not be entirely trivial, as the assumptions of the code need to change and expand.

One solution may be to change the name option from a drop-down list to a text field; this require prior knowledge and entering the name manually & accurately, but then the actual name would be stored in the action, rather than an ID that is not directly linked to a name. The matching up with and ID would then be performed at action time, so would always match to the correct ID.

@baltedewit I think this was your code. Thoughts?

[mint-dewit]

Is there a way of changing the "hyperdeck: Goto Clip (name)" function to retrieve clips based on their actual file name and not the order that they appear on the SD cards?

Not possible with the API, unfortunately. We've had to some "smart" stuff to get around this but only so much we can do.

This function works ok until new clips are recorded onto the SD cards.

if you are using companion for this I would suggest prefixing the name with the clip count variable. (I think that's possible?) That way a new clip will not mess up the existing indexes.

One solution may be to change the name option from a drop-down list to a text field;

We should simply change the id of the dropdown to be the clipName instead, possibly filtering out duplicates. Good idea to do this lookup at runtime!

[sphlabs]

I'm thinking about changing the Goto Clip (name) function to take a text field as input, rather than a dropdown. This would have the advantage of allowing actions to be programmed without having a live connection to a deck with the correct media inserted at the time. It would also allow the use of variables in clip names.

Any opinion on this as a change would be useful. I'd rather not have two functions doing the same thing--with different input fields--as that seems more confusing, and there is certainly more flexibility and power from making it a text field, and I think the benefits outweigh having to type in clip names manually.

[mint-dewit]

I don't have a strong opinion on this as I don't normally use this module for clip selection. I think I recall creating this on request of @JeffreyDavidsz, so he may have opinions on the case of changing it to freetext input.

[JeffreyDavidsz]

Changing the dropdown to a textinput field will make it harder for users to use the action in this module, you would need to extract the exact filename and type it in manually instead of just selecting it. I would suggest to use the ClipName as ID as @baltedewit said. then fetch the correct ID from the deck when pressed. (Assuming communication will be fast enough).

[sphlabs]

I agree with your point on ease with a dropdown. However, the counter argument is that, with a drop down it is only possible to programme a button where the clip already exists and is plugged into an active, connected deck, at the time of programming.

There there is the case I mentioned of using variables to dynamically control which clip is selected (a real use case I have been discussing with someone).

One solution would be to use a dropdown with tags--that would allow manually setting a name or choosing a clip from the list. This wouldn't deal with the variables issue though, I don't think? It's not mentioned in the Wiki but I'm guessing that variables are only parsed in textwithvariables options.

An other option is to create a new, separate action for "Goto Clip (name, text)". Or the action could have a dropdown and a text field, both optional, with one taking priority in the case that both are set. However, both of these feel rather inelegant and potentially confusing.

[sphlabs]

This update addresses all discussed issues:

Names are now stored as names, and not clip IDs. The correct clip ID is looked up at execution time. The dropdown now also allows entering a free-text filename, and this also supports variable insertion.

The only issue to which I can't see a solution, is that this will be a breaking change for existing actions. Because there is no way to guarantee that the correct disk, with the original files as when the action was created, is loaded into a deck that is connected and live at the time when Companion is first run, then any upgrade script that tries to convert a clip ID to a name will more likely than not fail.

[mint-dewit]

The only issue to which I can't see a solution, is that this will be a breaking change for existing actions.

Converting it to a Goto clip (n) action makes the most sense

[JeffreyDavidsz]

Moving discussion to slack