Resolume Forum

Posted: **Sat Mar 19, 2011 07:56**

**Update:
I was able to (sort of) remedy this with some clever programming and the BPM sync function in the clips in resolume. I'm able to detect the amount of milliseconds for one quarter note at the current BPM with about a +/- 10ms differential. However this works about 99% of the time (not enough in my book), and unfortunately only updates every 4 bars, which causes issues when drastic bpm switches occur (ie, moving from 10bpm to 120bpm)...

It's also inefficient to waste computing power recalculating a variable that most certainly already exists in resolume... I've got a couple other ideas for the flash API, but I'm going to make them in a new post rather than bumping this one. Anyhow, read on:
**

So I've been bending my PHP knowledge into actionscript and I'm starting to get the hang of it, I've found the Resolume-Flash API very handy and easy to use, but one thing is grinding me...

I want the ability to sync to midi clock in actionscript, I know i can make an animation of a set duration and then use resolume's sync to bpm feature, but that is not the same and not nearly as dynamic...

I've made a swf that is straight actionscript (completely dynamic) and the only way i can sort of sync it to bpm is to input the bpm manually as dynamic text into a variable. I cannot begin to express how many degrees of lame this method touches upon when compared to my request.

If the current BPM was available to me as a variable i could do things like find how many milliseconds occur in a quarter note of the current bpm:

Code: Select all


var bpm = 128; //this is where you come in!!!
var scan_interval = 4;	//1 = whole note, 2 = half note, etc...

/*-----------------------------------------------------------------------
milliseconds = (240,000 * (delay / time)) / bpm
so to calculate 3/16ths of a bar for a 120bpm song, the calculation is
(240,000 * (3 / 16)) / 120)
-----------------------------------------------------------------------*/

var scan_time = (240000 * (1/scan_interval) / bpm);

and have events in the swf occur in sync with a quarter or sixteenth note etc... If you guys were really intuitive, you would make the milliseconds of a whole note available as a separate variable...

I can't imagine this being too difficult given the current setup, please make this happen, I have so many ideas that could benefit from this (if not, I kindly demand a reason why).

I could beg some more, or further explain to you why this needs to occur, but you get the idea.

Puh-lease.

Posted: **Thu Mar 24, 2011 12:28**

Hey Traxus

We really see how something like this could improve your workflow, not only for Flash but also for QC based generative stuff. We've actually already done some tests with it.

Unfortunately, the way the communication with Flash is implemented (via XML) is way too slow for this to work properly and reliably. In fact your workaround is more reliable in that regard. Another way to approach it, that I've quite often found useful, would be to make your animation run on a normalized timebase (0-1), and then have the clip set to BPM sync. That way everything that happens in the animation would happen on beat.

I hope that explains the current situation a bit.

Joris

Posted: **Mon Apr 04, 2011 16:51**

I've been thinking about this, and after working the kinks out of my method I can see why midi clock would be totally unreliable... the 10ms differential is a result of compensation for this lag you infer to. I basically time how long it takes for the fader to cycle through half of its total distance and multiply that by two... difficulty is, because of the lag I can't just time how long it takes the fader to move from 0.2500 to 0.7500 as more often than not those exact values get skipped, so I need to add about a 2-3% buffer, which would obviously render any kind of start/stop/pause midi clock signals useless...

Code: Select all

function parameterChanged(event:ChangeEvent): void {
	//check to see what paramater was changed
	if (event.object ==  param_bpm_calc) {
		var fader_location = Math.round(param_bpm_calc.getValue() * 100);
		var flag_modifier = 2;
		var flag_start = 25;
		var flag_stop = 75;
		if ((fader_location >= flag_start) && (fader_location <= (flag_start + flag_modifier))){
			startTimer();
		}
		if ((fader_location >= flag_stop) && (fader_location <= (flag_stop + flag_modifier))) {
			bpm_calc_time = stopTimer();	
			//Readout.text = String(bpm_calc_time);
		}
		//Readout.text = String(param_bpm_calc.getValue());
	}
}

Anyway, are you also saying that there is too much latency(assuming latency is the issue you're referring to) to send just the bpm as a numerical value? The reason I ask is that, when I trace the value of a resolume parameter onto the stage while synced to the BPM clock, it seems to update with a decent consistency.

http://shyid.com/misc_upload/FaderReadout.swf
(On the BPM counter paramater, sync it to BPM at 4 beats)...

Would it maybe be feasible to broadcast the current BPM every 300ms (300ms sould allow instant accuracy up to 200bpm) as a paramater in actionscript? I obviously don't know what Resolume's back end looks like or any of those complications, but I was just wondering whether you guys had just given up on midi clock or BPM as a whole...

Thanks!

Posted: **Wed Apr 06, 2011 11:36**

Well, to be honest, we're sort of pushing Flash beyond what it's meant for as it is. In as3, you have to communicate with Flash files via XML, and this is already so slow, that adding the pushing of the bpm to it is not something we're very much in favour of.

It's one of those tough decisions. We really see the advantage of this, and we'd really like to do it. At the momet though, it would cause more harm to the overall workflow than it would benefit it.

Resolume Forum

Make current BPM a flash accesible variable...

Make current BPM a flash accesible variable...

Re: Make current BPM a flash accesible variable...

Re: Make current BPM a flash accesible variable...

Re: Make current BPM a flash accesible variable...