BPM info does not save on restart or clip moving

[Joris]

Ah yes. When the outgoing clip ends, it checks whether it needs to be ejected. So when it's set to play once, it asks the layer to send an eject command. This is the normal expected behaviour. The problem seems to be that during an active transition. both the outgoing clip, but also the incoming clip then get ejected. That's definitely not what you want.

Good find, thanks very much for the good detective work. We'll put it on the bug list, hopefully we can still get this fixed for 4.2.

[zebbler]

Awesome. Glad to help.
I have a few more updates:

1. I sorted out which OSC command was resetting all of the BPM on the slave computer to the "default" ones. It was (duh!) "bpm". Changing that command to a more specific "playbackcontroller/bpm" eliminated the reset problem for me. Now, everything behaves as expected on the slave computer, as far as the bpm is concerned.

2. I still have no good solution about how to avoid sending the "jumptopointofinterest" command every time I simply select a clip in master computer, no matter how specific I make that OSC code line. This creates a huge problem for me. I need for both LED video and video video to be nudged into place by a MIDI cue point trigger. They currently do that exact thing, but if I touch anything on my master computer that selects any clip whatsoever, it re-sends the cue point trigger to the active clip on the slave computer and effectively restarts the LED clip. Is there any OSC command available that will only send the cue point trigger when the cue point is actually triggered on the master computer? Vs. any time any clip is selected? It's an odd default behavior otherwise, if not. Would be great to devise a way to only send the cue trigger command over when the cue is actually triggered on master, vs. any time any clip is selected.

3. The bpm info not saving on the sample with the blank audio clip seems like a definite bug to me as well. I know I have a fix for it (x the audio out of that clip and just type in the number of beats), but I'd encourage the developers to look into this issue as well. As I've mentioned, I could try to upload this file for you to review.

4. Occasionally, all of the letters disappear from my cue points, and I can't really sort out if it's me pressing some hidden shortcut to clear them, or what? Check out my attached image. I am just not quite sure why most of the time that cue point row is filled with letters (qwert), but occasionally they all blank out. All of the MIDI triggers work with them all blanked out or not, this was simply a curiosity of mine to figure out what's happening here

I am pretty much set to have a great / stable tour run at this point.
But would really love to sort out a way to send a stable re-sync cue point from master to slave, without having it be triggered by any clip selection as well.
If that's not possible via OSC, I may need to put both of the computers on the MIDI network, and just mirror the MIDI commands going into each of them, which is quite a bit of work.

[Joris]

2. Triggering a cue point is just setting the playhead at a certain position. Instead of sending /activeclip/audio/position/jumptopointsofinterest, why not send a single message of /activeclip/audio/position/values when the clips need to be synced?

3. Sure, you can send it to mail@resolume.com

4. Those letters indicate key mappings you've made. Could it be you're using Comp Key Mapping, and just don't have any shortcuts assigned for that particular clip?

In general, keep in mind that a master/slave setup via OSC is not something we officially support at the moment. It's very impressive how far you've gotten. But saving a midi map on one computer and copying it to the other might be a lot more reliable solution. You can save and load different midi maps via the midi tab of the preferences.

[Zoltán]

... but if I touch anything on my master computer that selects any clip whatsoever, it re-sends the cue point trigger to the active clip on the slave computer and effectively restarts the LED clip.

I just looked at the osc dump, you can leave out
video/position/jumptopointsofinterest
audio/position/jumptopointsofinterest
from the whitelist.
when you have allready launched a clip on the master, the slave lauches too, you still get the playhead synced via /layerN/video/position

when you say

..every time I simply select a clip in master computer..

do you mean preview, or launch the clip?

[zebbler]

Yes, I mean preview unfortunately.
This renders me not able to touch any clips, or layer any clips in the master, since simply touching the clips "preview" handle, no matter which clip it is, active or not, restarts the active clip on the slave laptop from its cue point.

[zebbler]

@Joris - I will try your suggestion, and replace my current OSC message with the one you recommend:
/activeclip/audio/position/values

Or try Raven's suggestion for just using this line:
/layerN/video/position

Also - thanks a lot for reminding me that MIDI maps can be saved and copied from one machine to another.
Arena vs. Avenue won't matter here I hope? If the OSC change doesn't work, I'll potentially try that, it's way easier than re-inputting those values into every clip by hand.

[zebbler]

Switched to OSC command - /activeclip/audio/position/values
It's not quite synced this way however. For one reason or another, it seems to drag or get ahead a bit. While it stays relatively tightly synced, all things considered, the occasional half a second delay makes all of the LED beats appear way off.
It also till immediately jumps to the beginning of the clip if I select any other (non playing) clip on the same master layer. It behaves normal if I select things on another layer, but so long as I am previewing clips on the same layer as the playback clip, it immediately jumps to the position of the clip I am simply previewing, not outputting. Which makes me wonder what "activeclip" exactly means.. it seems to mean "any selected clip in the active clip's row".
If this was tighter, sync wise, it would still be a good solution, because it lets me select clips in non active layers without re-triggering the slave clips, and lets me select the active layer without re-triggering the clips.
Going back to my old setting for now, which unfortunately will make the clips jump to the cue point even if I am simply selecting an active layer - it still somehow fires the "jumptopointofinterest" command over to the active LED clip.
Oh well. Worth trying. I'll keep messing around with it.

The main trouble seems to be the definition of "activeclip" - since it seems to include not only playing clips, but also clips I am simply previewing, within the active layer.
Is there a command (similar to "activeclip" but more specific) to specify / and to lock down my interactions with "jumptopointsofinterest" to just the actually playing / outputting clip?

[Zoltán]

it seems to mean "any selected clip in the active clip's row".

it means the selected clip which is previewed.
if the preview is not updated on the slave it will affect the currently previewed clip on the slave.
- that's why I asked if you need preview on the slave.

how does your white/blacklist look now?

how is your workflow, do you launch clips or columns?

edit: when a clip is playing in the layer the preview will follow the current position of the clip,
when it is not playing the preview will start from the clip start.

[zebbler]

Thinking about trying to switch everything to MIDI controls, starting with tonight's show.
OSC master-slave control with a Processing white-list patch was amazing while it lasted But I just can't figure out a way to send a cue-point command from one computer to another without getting stuck in this web of interdependencies where that command also gets sent every time I preview a clip on Master.

I don't necessarily need previews on slave (is there really a way to disable all previews?), but I don't think that will solve my problem, since the re-trigger cue command will likely get sent to the actively playing clip any time I select any clip on the Master computer. And I definitely need to select clips on Master live, if I am to add any novelty and human touch to our pre-programmed show.

I did some tests last night with slave clips simply following the timeline of the master clips. They were following each other really well, but there was considerable drag, so the LEDs and visuals were out of sync. Our current, successful, sync point between the two machines is around 10ms / not more than one or two frames at most.

But yeah, even with all of your explanations, I just don't see a way to keep clips synced with OSC beyond the initial "trigger clip" point. Any re-syncing or following the timeline seems to cause a myriad of other problems, even with my careful white-list. So I will probably try to switch it to MIDI today and see how that goes (3 machines on one MIDI network).

Thanks for all of your help,

Z.

[zebbler]

Potentially happy ending to all of this.
With helping encouragement from Drazkers I went to explore this line of OSC again:
/layer3/audio/position
I've also (per his recommendation) upped my audio buffer to the max available.
I totally deleted this line:
audio/position/jumptopointsofinterest

It was all working really well, this time around, albeit with some slight sound crackling; until I got to one particular clip, which veered off really quick. Upon further inspection, I realized that the duration of that clip was off by about 5 seconds from the master (master has a longer trail-off). So it seems that command relies not on precise timecode location, but instead on "how far the clip is from completion", since with previous start-only sync - they were perfectly synced up. I re-edited that clip to match the duration perfectly - and it is all working perfect now.

Furthermore, clicking anything on master computer doesn't restart my LED (slave computer) clips anymore!
So my biggest problem here has been resolved it seems, with this new line of code.

If I preview the actually playing clip on the master, it jumps to frame one for about 1 frame, then instantly re-syncs.

So all is working well as of this moment.

I will post a proper bug report with the "non-saving bpm" from the blank audio clip; and disappearing cue letters sometime soon (to the email provided), and maybe post a brief video of our sync experiments as well, to conclude this crazy chapter.

Thank you very much everyone for your help and support.

Zebbler