Smoothing clock from Ableton Live to Resolume 3

[gpvillamil]

[Edit] Added version 2 to this post, it uses floating point internally and better manages smoothing. Should now track Ableton clock pretty exactly.

Many have commented that clock sync between Ableton Live and Resolume 3 is a bit dodgy - the BPM seems to bounce up and down uncontrollably. Unfortunately, this seems to be an issue with Live, not necessarily with Resolume. Max/MSP also receives a jumpy clock from Live. It seems like Resolume is actually following this inaccurate clock very precisely! (It is also very possible that the issue is due to the MIDI Yoke drivers - any experience on Mac OS X?)

Here is a simple Max patch that takes the MIDI clock from Ableton Live, smooths it, and sends it to Resolume 3 via OpenSoundControl.

You'll be able to see how the incoming clock from Live bounces around. The patch works by averaging the last few values (default = 5) and sending them out. Of course, this means that response to tempo changes is laggy.

Just download the file and unzip, and open the Max patch in Max/MSP or the Max runtime.

From top to bottom, controls are:

Checkbox for on/off - oddly, once turned on, this doesn't seem to do anything
Menu for selecting MIDI source - select whatever source the Ableton Live clock is coming in on
Button for tap tempo - you can tap in the tempo if you want (but be aware that you have to tap a lot, to affect the moving average)
Number of samples to average - default is 5, smaller number means jumpier clock

Then there are two number fields, one displays the incoming clock from Live, and the other displays the smoothed clock being sent to Resolume

Finally, two fields that let you define the host IP address (127.0.0.1 for the same machine) and port (7000 is Resolume default).

[gradek]

Cool, thanks gpvillamil for sharing this. I will give it a test soon. Your MAX/MSP programs for resolume are awesome! keep up the good work. I have been meaning to give you feedback about your step sequencer app.

I have also experienced a jumpy midi clock using OSX ableton live 7 and Resolume 3. I did a test and talked about it here:
http://www.resolume.com/forum/viewtopic ... =10#p20937

However I'm not so sure midi issues has to do with ableton or midi yoke. Since on OSX there is no need for Midiyoke. I did my test with both live and R3 running on the same machine. I also had the same issue when sending a midi clock signal via USB from an Akai MPK25 to R3. So the issues exists with hardware too. Also live does not seem to have midi issues when rewired with Reason. But that may be a different form of communication, not sure how rewire works.

The strange thing is that the jumpy midi clock didn't seem to matter to much. I didn't experience a jump in my video clips. Or at leased I didn't notice. It might be hard to tell with the clips I was using. The sync is much tighter then me tapping the tempo, so everything seemed to be hitting on the beat.

I'll try some more tests soon, see if I can isolate the issue

[GeeEs]

The same shaky clock is also visible when using FruityLoops as MIDI clock .... (did not try it with the latest beta of FL) <- [edit] also in the latest beta after trying today.
As gradek says, I also didn't notice this as a bad thing.. Video seems to be just in sync... (I always thought this was a Resolume thing and that it took the average recieved BPM)

As for general audio BPM's...With a steady beat you won't hear the difference between i.e. 127 and 127,5 or even 128 bpm if the values change very fast up and down. It will just sound like it's 127.5 bpm. With a sustained chord/sine/pad you will hear it probably!

[gradek]

Is it possible that Resolume 3, just displays a very accurate signal and that other programs also jump up and down but display a rounded number or average? In general midi clocks are not perfect, and sufferers from latency. Perhaps R3 is just showing the laggggggg.

GeeEs, why do you think it would be problematic with chords and pads as apposed to beats? Would the sound over time slowly become more out of sync?

[GeeEs]

Is it possible that Resolume 3, just displays a very accurate signal and that other programs also jump up and down but display a rounded number or average? In general midi clocks are not perfect, and sufferers from latency. Perhaps R3 is just showing the laggggggg.

I was thinking the same ... It looks like if Resolume is measuring/showing the BPM far more often that actually needed (don't know the exact process of how to get BPM's in Resolume, but that's what I see)

GeeEs, why do you think it would be problematic with chords and pads as apposed to beats? Would the sound over time slowly become more out of sync?

No, melodies will be exactly the same in sync as beats, but you'll hear it as (vibrations)/key change in the sustained/released tones... With beats you probably won't hear it, because they have shorter sustain/release. (I was pointing towards listening to the actual music)
Like when you change the pitch on the turntable. With beats it's harder to detect the change in pitch then with a melody.

Actually I did not test Avenue with sound, controlled by external MIDI clock... I will do that asap.

[sburke1]

Hello, thanks alot for your patch. I just tried it out my computer (MBP-leopard) from Live7-R3 all on the same computer. I will test it with my friends computer soon.

The clock is now steady in R3, but one bpm too low! Also, should i see the yellow midi clock light flashing in r3 because I don't.

I wish I knew Max and could modify the patch.......Is there any way to either bump up the output midi clock by an integer, or some other way to fix the problem?

I will test this on 2 computers still. Thanks alot for the help.

[gpvillamil]

...The clock is now steady in R3, but one bpm too low! Also, should i see the yellow midi clock light flashing in r3 because I don't...

Probably because I'm truncating the number down to an integer, instead of rounding. Easy to fix.

MIDI light should not be flashing, I am using MIDI into Max, and then OSC from Max to Resolume.

[GeeEs]

Tried it also yesterday, works great! But indeed 1 BPM to low.

Also when the BPM is changing now it's a bit worse than with the shaky clock because the changes are a lot slower and bigger now. I see you can play with the follow after x beats thing, but that makes it sometimes worse. When a small drop in BPM takes place then it will stay on that BPM there x beats and then it chages to actual BPM.

i.e. whith shaky clock it changes beteween 120.000 and 119,900 the result is close to nothing, but now in Avenu after the MIDI to OSC program, the change goes from 120 to 119, that is a lot more.

With the shaky clock (tested on 40 BPM) you see the shakyness is really not that bad. It jumps between 40.100 and 39.900. I get the idea that the higher the BPM the higher is this difference.

[gpvillamil]

I've attached a newer version (v2) of the patch to the initial post in this thread. It uses floating point internally to keep track of the clock, and rounds off the answer properly. It now tracks the Ableton clock much more precisely.

This should partially address GeeEs' point about the jumps (though I agree, in practice they are so small as to be unnoticeable).

[GeeEs]

Thanks so much! The version 2 is working like a charm!
Setting the "clock pulses to average" to 2 is just perfect for me (reaction vs. accuracy)

Your applications make me more and more interested in the whole MAX/MSP tools... Really good job, and I really like the intuitive interface/style of the 3 tools you did!