I'm actually having an issues with the 0-1 values resolume uses to change BPM. It is working as designed, but not as flexible as I need it. I'm doing this for a video installation where a user can change the speed of the video through a TouchOSC slider that controls BPM.
I'm trying to make a slider/fader in TouchOSC that when in the centered in the middle the value will be at the normal base BPM I want for my composition. In my case that number is 108 bpm.
Since Resolume has a value of 2-500bpm controlled by OSC values 0-1 the numbers don't translate well.
In order to determine what floating point number I need to land on 108bpm I did the following.
The resolution of BPM in R4 is 499 since 2-500 has 499 steps. If you divide 108/499 you will get a long number: 0.216432865731463 or roughly 0.216
The issues is that ToucOSC only allows for 3 deciles places of resolution for controlling custom values. So I can enter 0.216 but I wont' get 108bpm instead something like 109.26 (about) I suppose I could live with that value since no one will notice the difference between that and 108. But it seems silly I can't just send Resolume a value between 98-118 to get the perfect BPM range needed, with 108 being in the middle.
Perhaps in a future release there can be changes made to the OSC mapping to allow for custom ranges or perhaps allow a change from 0-1 ranges to 2-500 as a OSC range. Another way to solve the issues would be to change the BPM range from 1-500, that would reduce the long floating point numbers. 108/500 is 0.216 as apposed to divided by 499.
Also I'm confused since in the R4 Beta 2 release notes. It mentions that "[FIXED] BPM only supports whole numbers" however I continue to get bpm values like 108.52
I suppose I could translate the 0-1 values to 98-118 with a program like OSCulator however I'd rather not have too.
Using OSC to change BPM - suggestions
Using OSC to change BPM - suggestions
Want to map LED rings with Resolume? Then look no further: https://goo.gl/f2dPGu
Re: Using OSC to change BPM - suggestions
We did do some work on this during the beta stage, and at point we were sending the actual BPM number via OSC. We rolled back to the normalized numbers, and I'll have to talk to Edwin to see what the options are for changing this.
The bug that was fixed was that in cases like 108.52, it would display 109.00Also I'm confused since in the R4 Beta 2 release notes. It mentions that "[FIXED] BPM only supports whole numbers" however I continue to get bpm values like 108.52