BPM info does not save on restart or clip moving

[zebbler]

Hah well that was interesting!
I opened the master file, the video track with no audio without any surprises came up with the wrong bpm (105.6030283 instead of 135). I erased the audio on it, and then had to do some math to figure out how many beats there are in it (3 min 47 sec 600 millisecond at 135 bpm = 512.1 beats as far as my math told me). And surprise! Resolume already had 512 beats auto-assumed for this clip, as if somewhere deep inside it remembered that I labelled it 135bpm, even though it was being misread. Dragging it from one place to another preserved that number ok - 512 beats. So I am assuming it will save ok now, without audio. My only weird thing about it is that "beats" don't take decimal numbers. But I don't think .1 will make any serious difference for a track over 3m47s.
So this temp solution of erasing blank audio and setting the number of beats into the video instead seems to work.
Now I just have to figure out:
1. Why cue point triggers occasionally shut off a clip
2. Why all of my bpm info got reset on restart on my slave computer
3. Is there any way to not send cue point data over OSC when simply selecting a clip on the master computer (since I am not actually trying to trigger that cue point when I do that - and it makes it very impossible for me to apply any live effects, or correct any settings on the fly)

Also, may be a question for another thread - but my cue points are all labeled qwerty - which makes sense - but occasionally that row of cue points shows up blank with any letters in it... Am I doing something to disable the letter input in those particular clips without noticing it, or could this be another weird bug? I don't seem to be doing anything very different... The letters simply disappear from half of my clips sometimes...

Oh gosh... so much here.

Thanks again for any help,

Zebbler

[Zoltán]

if you can, make a simple osc message dump program, then see what messages are sent on that particular cue point trigger and what gets thru your whitelist of that.

do you have keyboard mapping on the cues?
are these keys assigned to anything else by default?
is your slave machine running the exact same composition with the same files?

I think most of the weird behavior is due to the incomplete/not accurate whitelist.

[Joris]

In addition to the excellent help from Ravensc and Oaktown:

To be honest, you have such a crazy interconnected setup going on, it sounds like there is a 'ghost in the machine' somewhere. Resolume doesn't just reset all bpm data in a saved composition, blank out shortcuts or shuts off a clip when it needs to send a cue point. I'm not saying those things aren't happening! But I'm saying it's not what Resolume does out of the box, so something must be causing it to act like that.

If I was to start troubleshooting this, I'd run a lot of tests, each time with a single element not active ( cut out Live, turn on Live again and cut out all the OSC traffic, then send all the OSC except just send cue points via keyboard, then just send clip triggers manually, etc etc ). The moment the undesired behaviour doesn't occur after disabling a certain element, you know what the problem might be.

Either something is adding noise to the signal flow, causing unwanted commands to get activated in Resolume. Or something is really causing Resolume to act weirdly all on its own.

If it's the second case, we need to solve it. During the troubleshooting, you probably narrowed things down to a repeatable set of steps that will make Resolume do the thing it's not supposed to. The moment we know those steps, we can get right on fixing it.

But, again, to be honest, it sounds like it's just a knot of virtual cables that needs to be straightened.

[zebbler]

I think for now I will just keep observing and eliminating options.

Just to be clear though - there shouldn't be any feedback happening from one machine to another - master computer (Arena) is only controlled by the Ableton computer sending it MIDI triggers - so it's not getting any OSC messages, just sending them to slave computer (LED video clips) after those keys are triggered by MIDI from Ableton computer.

Here's a graph of our signal flow by the way, for easy reference:

My current whitelist of OSC commands is as follows:
opacity
connect
preview
bypassed
direction
bpm
opacityandvolume
speed
fadeout
clear
disconnectall
audio/position/jumptopointsofinterest

Could any of these be responsible for resetting all of the bpm on the slave computer clips?

The sets on both computers are identical in layer and column numbers, but have clips with different resolutions and titles. My biggest problem is genuinely the inconsistency of it all. As I've mentioned, this crazy gordian knot of a configuration works perfectly well (we preview audio coming out of all 3 computers all at once, and it's perfectly synced up, down to about 10ms or better) 90% of the time. Then, out of the blue, some of those issues I've mentioned might happen; where just the night before - they wouldn't.

I will try to create an OSC dump program on the slave computer, to see if there's anything unwanted sneaking through, but in my understanding - there shouldn't be any OSC message out there that resets all of the BPM counters, is that correct? Just want to figure out where to put a priority marker in my observations.

As far as current observations go of what worked, so far, in my last 100% successful performance we did two things different:
1. I set a, a/v, and v sliders all the way up (before, the a/v and a sliders were slightly lower on the top clip - my master computer runs two clips at once generally for our mapped stage - one for front layer and one for back) - to make them match each other.
2. The musician allowed the track right before the track that occasionally shuts off on re-sync command to play out all the way, and started the troublesome clip after the clip before it fully ran out.
These may not be related to anything. But that's the only different thing we did when it all worked out ok.

I'll keep watching our patterns, to try to sort out if there's a predictable little thing that I can find that breaks it.
Let me know if you'd like to take a look at that clip that was consistently not saving its BPM data, I don't mind uploading it.

Thanks for being patient with my crazy networked setup.
Wish there was an easier / more stable method of syncing without resorting to MIDI networks and OSC whitelists, but all of the experiments we did with SMPTE would not allow us to mix between clips.

Z.

[Zoltán]

Could any of these be responsible for resetting all of the bpm on the slave computer clips?

yes. or at least it could apper to you as a reset or not saving BPM data on the slave:

if the bpm setting for the clips in the same position should be different like master:/layer1/clip1 bpm is 123 and slave layer1/clip1 bpm is 135
then if you load the master comosition after the slave has been loaded, the master sends out all the info regarding clips and layer settings including the bpm for layer1/clip 1 so in the slave layer1/clip1 bpm will be set to 123.

So you have to be more specific in the whitelist what you would like to allow thru
a simple "bpm" will allow the compositions bpm setting, then each clips bpm setting, then the activeClip bpm - which is the currently selected clip.

the activeClip playhead(playback position) info is sent via osc twice if your clip is actively playing. so a Select /deselect via activeClip osc message will stop the clip playback eventually. (besides causing jerky playback because of the double position information)

I would start with a blank filter, then be very specific about what you want to let thru.
After you have no issues, then you could add more to the whitelist if you are missing functions.

-----start of whitelist --
compostition/
playbackcontroller/ # for bpm, tap, resync etc.

layer1/video/ # this will let thru effect settings too.
layer1/audio/
layer1/opacityandvolume
layer1/transitiontime
- these repeating for every layer you have.

bypassed
solo
clear
connect # this can have int 0 or 1 where 1 is connect and 0 is disconnect.

video/position/jumptopointsofinterest
audio/position/jumptopointsofinterest

----- End of whitelist --

do you really need clip preview in the slaves?
if you are programming in processing then make a blacklist for:

----- start of blacklist --
activeclip
activelayer
preview
video/addsubtractr
video/addsubtractg
video/addsubtractb

----- End of blacklist --

both your vj and led laptop is a mac right?

edit: so basically on composition load and deck switch, all the clips layers and effects information is sent out to the slave to get in sync. All you see in OSC mapping and more!
This is very good if you run a mirror of the master in the slave, but not good for syncing different content and settings.

there is a lot of cleaning up to do in the osc implementaton for master-slave operation

[zebbler]

Quick update - as I am setting up for soundcheck - I was able to verify that it was indeed my OSC control that reset all of the BPM data on my slave computer to the "estimated" ones.

I'll check your reply in a minute - but that's definite progress in narrowing this down.
It happened in front of my eyes as I was watching the master Resolume Arena boot up.

One step at a time

[zebbler]

Thank you very much for your thorough reply Raven.
Just a quick note - the odd thing is - the BPM doesn't get reset to what the clips say on the master computer, but to seemingly arbitrary numbers, which look like the ones that Resolume tries to guess on first load. My bpm info should mirror one computer to another perfectly - as the LED clips and video clips are mirror durations / bpms of each other. I think that's why it was so confusing to me, just seemed like a total BPM reset - instead of sending the BPM copy data over. It only happens on Master restart, once I type the correct BPM data into the slave - they stay put throughout the set.

Thank you for the OSC white-list help. I'll have to poke around at it to see which one of these commands needs tweaking to prevent this behavior.

[zebbler]

I can now consistently reproduce the clips auto-shutting off!
Holy crap does it scare me.
Basically - when the previous clip is about to be finished, and the new clip is triggered and is cross fading, - as soon as the clip that's about to be finished ends while fading out, it shuts off the clip it's supposed to fade into.
Here's a video of this happening:
https://www.dropbox.com/s/xuloglac70r8y ... M.mov?dl=0

I would LOVE to get this behavior to stop.
It's extremely scary in a live concert setting.

It's very consistent behavior now that I have sorted this out.
Every time a clip comes to an end before being done cross fading, it shuts off everything else in its layer, even the clip it's cross fading into.

[zebbler]

I might have found a temporary fix to this bug - instead of letting clips end, I just set the transport window for all of them to "pause on the last frame". That seems to prevent them from shutting off everything in their layer.
I really hope that will be a good temporary fix... I've been on pins and needles last few shows.

[Zoltán]

I might have found a temporary fix to this bug - instead of letting clips end, I just set the transport window for all of them to "pause on the last frame". That seems to prevent them from shutting off everything in their layer.
I really hope that will be a good temporary fix... I've been on pins and needles last few shows.

that is exactly what I use too.
it works with autopilot.

that behavior should get into the bug list.
a possible fix would be when a clip ends while transition out, its texture should be replaced by a fully transparent one for the remaining transition.