I have a particular (just one set of) video clips that always reset their bpm to the one Resolume has calculated for them, from my hand-typed one. It is 135, and I type in 135. It stays there, unless I move the clip to another slot - then it resets to 135.93948 or something similar, nearly 136. It also resets on restart. It's really weird that it's a SET of clips that do that. And nothing else does it either. Also, this set doesn't seem to keep their midi trigger points on the cue.
Any idea of what it could be?
I copied the files and changed their name, and the behavior is still the same.
But these are the only clips that give me this much trouble....
What could be going on?
I'm on Resolume Arena 4.1.11 rev5588
Latest MacBook retina
BPM info does not save on restart or clip moving
Re: BPM info does not save on restart or clip moving
Just realized at least the Arena clip had blank audio (silence) for the entire duration.
Maybe that's triggering the "non-savable bpm" glitch?
Maybe that's triggering the "non-savable bpm" glitch?
Re: BPM info does not save on restart or clip moving
Could you send us one of these problematic files?
Re: BPM info does not save on restart or clip moving
It's a bit huge - 6gigs or so - I can upload it if you really want it though - let me know.
I just realized that in my Avenue composition that follows this one on a different machine ALL of my BPM data got reset on restart though.
---> Is there a "master BPM reset" OSC command that I mistakenly send into it?
Inputting correct BPM for one blank audio clip is not hard, but changing about twenty of them to correct ones on the other laptop is a tricky thing to do daily (I'm on tour). Those clips all have proper audio in them, so it feels like a possibly separate issue.
The other machine is Avenue 4.1.11 OSX 10.9
I just realized that in my Avenue composition that follows this one on a different machine ALL of my BPM data got reset on restart though.
---> Is there a "master BPM reset" OSC command that I mistakenly send into it?
Inputting correct BPM for one blank audio clip is not hard, but changing about twenty of them to correct ones on the other laptop is a tricky thing to do daily (I'm on tour). Those clips all have proper audio in them, so it feels like a possibly separate issue.
The other machine is Avenue 4.1.11 OSX 10.9
Re: BPM info does not save on restart or clip moving
This is the white list of osc commands my master Arena composition sends to slave Avenue computer:
Re: BPM info does not save on restart or clip moving
Additionally "junptothepointofinterest" restarts a clip when it's simply selected on the other computer. A bit unexpected behavior as I thought it was a command for "cue point" (I copied it from cue point trigger). I thought that only pressing that trigger would send this command, but somehow simply selecting the clip does as well.
Re: BPM info does not save on restart or clip moving
how is your master-slave connection set up?
are you using any osc filter?
do the clip bpms reset on both machines, even if not running in master-slave?
are you sending osc manually from another program to the resolume instances?
are you using any osc filter?
do the clip bpms reset on both machines, even if not running in master-slave?
are you sending osc manually from another program to the resolume instances?
Software developer, Sound Engineer,
Control Your show with ”Enter” - multiple Resolume servers at once - SMPTE/MTC column launch
try for free: http://programs.palffyzoltan.hu
Control Your show with ”Enter” - multiple Resolume servers at once - SMPTE/MTC column launch
try for free: http://programs.palffyzoltan.hu
Re: BPM info does not save on restart or clip moving
What happens if you hit the X near the audio portion to remove it? Does that change anything?zebbler wrote:Just realized at least the Arena clip had blank audio (silence) for the entire duration.
Maybe that's triggering the "non-savable bpm" glitch?
Re: BPM info does not save on restart or clip moving
that us happening because, when you select a clip that is currently playing, it becomes the activeclip, and all the data regarding that clip will be sent over osc twice, once as layer/clip/ and as activeclip/ too.zebbler wrote:Additionally "junptothepointofinterest" restarts a clip when it's simply selected on the other computer. A bit unexpected behavior as I thought it was a command for "cue point" (I copied it from cue point trigger). I thought that only pressing that trigger would send this command, but somehow simply selecting the clip does as well.
this causes a lot of unexpected things.
that is why i am asking about your master slave config.
and if you send osc from the slave back to the master that will cause eventually a feedback loop.
Software developer, Sound Engineer,
Control Your show with ”Enter” - multiple Resolume servers at once - SMPTE/MTC column launch
try for free: http://programs.palffyzoltan.hu
Control Your show with ”Enter” - multiple Resolume servers at once - SMPTE/MTC column launch
try for free: http://programs.palffyzoltan.hu
Re: BPM info does not save on restart or clip moving
I have a "white-list" OSC filter setup in Processing, so only the commands that I have sent a screen shot of - get passed through. Everything else doesn't.
Communication between computers via OSC is happening only one way - master to slave, so no feedback loops would be possible.
My total communication goes like this:
I join a wired MIDI network, DJ (Shpongle) sends me MIDI clock, MIDI triggers (to start tracks) and MIDI re-sync triggers. Those are necessary because when tracks go from one BPM to another in Ableton - they can do that very quickly, but Resolume kind of slides into it. So we wait four bars and send a re-trigger, by activating a cue point, set to a particular time in both Ableton and Resolume video. Once in a while, especially (alas) in the middle of our set, the cue point triggers simply stop the clip instead of nudging it forward. Last night we had our first 100% successful performance, which felt pretty incredible... but those little bugs make me ever so anxious.
I will try clearing the audio on the clip that consistently doesn't save the BPM data on it and see if it helps. Will post my results here. Any idea of why ALL of my BPM was gone from my slave computer? It's not possible that I sent some "reset all bmp" command to it, is it? THAT one got me tremendously confused. The file just comes back with all of the bpms reset to the default Resolume approximations every once in a while (again, not consistent, sometimes after restart they are saved ok).
Thanks for your responses!
Would love to make this a 100% stable situation for me / anyone else trying this moving forward.
Communication between computers via OSC is happening only one way - master to slave, so no feedback loops would be possible.
My total communication goes like this:
I join a wired MIDI network, DJ (Shpongle) sends me MIDI clock, MIDI triggers (to start tracks) and MIDI re-sync triggers. Those are necessary because when tracks go from one BPM to another in Ableton - they can do that very quickly, but Resolume kind of slides into it. So we wait four bars and send a re-trigger, by activating a cue point, set to a particular time in both Ableton and Resolume video. Once in a while, especially (alas) in the middle of our set, the cue point triggers simply stop the clip instead of nudging it forward. Last night we had our first 100% successful performance, which felt pretty incredible... but those little bugs make me ever so anxious.
I will try clearing the audio on the clip that consistently doesn't save the BPM data on it and see if it helps. Will post my results here. Any idea of why ALL of my BPM was gone from my slave computer? It's not possible that I sent some "reset all bmp" command to it, is it? THAT one got me tremendously confused. The file just comes back with all of the bpms reset to the default Resolume approximations every once in a while (again, not consistent, sometimes after restart they are saved ok).
Thanks for your responses!
Would love to make this a 100% stable situation for me / anyone else trying this moving forward.