Smoothing clock from Ableton Live to Resolume 3

[sburke1]

V2 seems to be workling flawlessy. Nice Job!

My only questions now is....Do I still have to hit the resync button with this set up?


I can now switch bpm's in ableton, do my dj thing, have my R3 follow my tempo. I want to trigger AV loops from r3 in sync with ableton, not just video clips. When I trigger a loop in r3 in conjuction this new maxpat, it doesn't start at the right spot, probably because it is not getting traditional midi clock sync. I am new to OSC and am probably missing something. Is there any way to be in sync at the right tempo, and also be on the right beat so he can just trigger away without having to hit resync.


After I tried that I then also turned on sync via the iac bus, the way I used to do it. I think what is happening now is that I am getting OSC clock from max, and midi clock from the IAC,sounds weird, but this is a lil better than before! The clock is waivering very fast, but what I am hearing and seeing looks ok, just sounds a lil rushed. The plus is, that I dont need to hit the resync button because I am getting traditional clock sync now and my down beats are there. The down side is that it doesn't sound perfect. (sounds pretty good tho!)

I would still love to hear a set up where I don't need to OSC and midi clocking R3. Maybe some way that OSC can also trigger the midi clock? Also, this is with 1 comp and the IAC bus and I have yet to try via ethernet cable and network session.

Anyways, thanks alot for your efforts as I am now syncing better than ever.

[gpvillamil]

What is probably happening is that I am only sending BPM info via OSC, not sync info.

I think the Max sync~ object can receive a start/stop from Ableton, so the idea would be that when sync~ sees a start message, the patch would send start + resync via OSC to Resolume, and when it sees a stop from Ableton, it would send a pause via OSC. That should keep everything in sync.

There is also a global transport object in Max that seems tailor-made for all this. I'll have a look at it in more detail.

I will add to the queue... however, the technique I am using is so basic that I am sure it would be very simple for Bart & Edwin to just add it to Resolume. I could see something in the prefs panel saying "smooth MIDI clock on/off" and "samples to smooth". I believe they already decode start/stop messages correctly?

[zeropoint]

On a slight side note.....I don't use AV clips in Resolume so the internal audio sync is not an issue for me. But there is a gradual tempo drift occurring when clocking from Live over the IAC bus. I have been using a "sync" clip in Live on a 2 bar cycle to regularly trigger Resolume's resync and it works really well to a point. As long as the loop cycle is "play forwards" and the loop duration is not more than 2 bars this keeps Resolume's visual sync lock absolutely tight. Of course if your maximum clip loop length in Resolume is 4 bars then you could set the resync trigger in Live to a 4 bar loop. As long as you don't have clips in Res looping over very long bar durations this works well.

Where the problem arises for me is when using loops in Resolume that loop back and forth. In this instance Resolume will always jump to the opposite end of the loop bracket when Resync is triggered thereby interrupting the smooth loop back and forth. If this were coded slightly differently, so that the Resync sends the playhead to the closest end of the loop bracket rather than the opposite (and if you are on short resync loops this will be unnoticeable as the tempo drift will be virtually nothing), then it would be possible to sync lock perfectly using this method.

Just a thought.........

[gradek]

Zeropoint,

how did you create a sync clip in live? is there a way to program a resync command at the end of the 2 bar clip?

I see your point about bouncing clips. is the problem when a bouncing clip is playing backwards, when re-synced it start to play forward, from the first frame? and if playing forward it restarts playing backwards on the last frame? You would like to have it continue in the same direction it was playing when re-synced?

If you did that however, you would get a strange patter bounc if you were resynching every 2 bars.
"F"=Forward "B"=Backward "|" = Sync
FB|BF|FB instead of FB|FB|FB

[gradek]

Just a though,

If Resolume 3 can receive a good stable midi clock via OSC, for example gpvillamil's sequencer app sends a very steady midi clock to R3. Perhaps it might be best to have ableton live also run on the same OSC midi clock controlled from a single MAX patch. That way both would be in sync and there would be no need to smooth or average the signal coming coming from live.

[zeropoint]

Zeropoint,


If you did that however, you would get a strange patter bounc if you were resynching every 2 bars.
"F"=Forward "B"=Backward "|" = Sync
FB|BF|FB instead of FB|FB|FB

Exactly! Only I checked and my bouncing loop in Res is one bar long and my sync loop is 4 bars so I get

FB|FB|BF

That's why I said it would be cool if the Resync sent the playhead to the closest end of the loop bracket when resync is triggered.

But anyway..... I have just run another test without any Resync and the drift seems to have disappeared. 45 minutes and 1500 bars of playback and everything is locked tight to the beat....

[sburke1]

I like the idea of having Live and R3 controlled by one clock. This is, if MAX can controll clock as easily as live, where you can assign tempo to a knob and have smooth steady changes. This seems a little dangerous though. Sometimes I might want to play an arrangement in the arrangment view from live with precise tempo changes. Sometimes I want to be in clip view and tweak tempo with a know or rename a scene with bpm info. I'm hoping that the OSC clock smoother maxpat can add a resync message to its flawless clock sync to finalize the perfect sync!

[wilow]

Hello! First I want to thank you all for the information posted, the links, it has been very useful to me..

I'm starting an audiovisual Live set like that

Laptop 1 (Win 7 32bits): Ableton Live 7
via ethernetmidi out port 1 track (yes), sync (yes), remote (yes)

to

PC 2 (Win XP 32 bits): Resolume 3.2
via ethernet midi in port 2 (using maple virtual midi ports)

I get the midi communication between the 2 machines, triggering clips

I have Max 5 installed on both computers, I open the "midi osc clock v2" with Max Runtime on PC 2 and I get the error message:

midi_mme: error 4 opening midi input device Maple Midi In: Port 1
midi_mme: error 4 opening output device Maple Midi In: Port 1

I don't know how to solve this, midi communication is working, and I have this issue with the midi osc clock in Max, any idea on how to solve this?

I would preciate a lot any kind of help

[apricotandpearjam]

hi.

i want to use this to smooth the output of abletons clock on one laptop to resolume on another.

im sending out the midi network via ethernet.

should my input on the max patch be the output from ableton to the midi network?

then how do i tell resolume to pick up the new clock from the max patch?

thanks

[gpvillamil]

hi.

i want to use this to smooth the output of abletons clock on one laptop to resolume on another.

im sending out the midi network via ethernet.

should my input on the max patch be the output from ableton to the midi network?

then how do i tell resolume to pick up the new clock from the max patch?

thanks

The Max patch uses OSC to talk to Resolume. You can use two setups:

::: Use MIDI between laptops

Have Ableton on one laptop output via network MIDI
Have the Max patch and Resolume on the other laptop
Max patch is set to receive network MIDI
Max patch is set to output OSC to 127.0.0.1 (localhost)
Turn on OSC input in Resolume

::: Use OSC between laptops

Have Ableton and the Max patch on one laptop
Send MIDI from Ableton to the Mac patch (on Windows use MIDI Yoke driver, LoopBe, Maple, etc.; on Mac OS X use the built-in MIDI routing)
Take note of the IP address of the Resolume laptop
In the Max patch (on the Ableton computer) set the output IP address to that of the Resolume computer

I think the latter option is better. OSC is designed to travel over networks very efficiently. MIDI over Ethernet has always been a bit imprecise for me.