Set BPM/tempo to a tenth of a number (or at least a half)

unix-guy said:
That still doesn't make sense... There's no 1, there's only tempo.

And unless you're doing something unusual it won't be relevant to when you start.

The tempo (and subdivision) is pretty much always applied to what you play and produces an effect for some amount of time after it is triggered. Most things you can trigger are not still audible after more than a few seconds.

Maybe I'm missing something so I'm happy to have a better understanding if you care to detail the scenario... Or not, either way I'm ok. :)
Click to expand...
Ok rethought this and see your point. It’s really not that big of a deal if a delay at 154 is happening over a tune at 154.25. It’ll still sound like its in time as the decay like you said doesnt typically go on very long to notice the difference.
It’s not like the fractal has to follow the DAWs timeline. I guess CC changes will happen when the DAW gets to them and transmits the info at that time, tempo notwithstanding. I personally have my DAW sending tempo to the fractal to set my FX BPM times. I still think it should be accurate. If for no other reason, for the sake of accuracy. This box can damn near split atoms, it probably should also be able to figure a tempo down to the length of PI.
 
Not ideal, but I do have a work-around for you guys running a preset per song and tailoring your delay and reverb blocks. This app will convert tempo to milliseconds for you:

https://macdownload.informer.com/delay-time-calculator/download/#downloading

There are online calculators, but I don't like to depend on an internet connection for such things.

The zip file has both windows and mac versions.

For you guys sending tempo over from a setlist maker to a generic or kitchen sink preset, you are still out of luck.

With the introduction of scene ignore, I was hopeful that I would finally get away from a preset per song workflow, but the tempo thing still keeps me locked in for now.
 
unix-guy said:
You just have to be aware that changing channels for the controllers affects ALL the controllers.
Click to expand...
You mean In any given scene, correct? In this sense the controller is a single block (always on a particular channel but not always used in a scene).

There's probably already a wish for 2 (or more) controllers in a preset... that would be killer.

unix-guy said:
Most things you can trigger are not still audible after more than a few seconds.
Click to expand...
True but things like sequenced synth can run longer.
 
yyz67 said:
You mean In any given scene, correct? In this sense the controller is a single block (always on a particular channel but not always used in a scene).

There's probably already a wish for 2 (or more) controllers in a preset... that would be killer.


True but things like sequenced synth can run longer.
Click to expand...
Yes, that's what I meant...
 
I wonder if this could be implemented similarly to floating point numbers. Essentially, you could have faster tempos not allow any decimals, but as the tempo gets slower, allow decimals. I think most song that require this feature have a tempo of 70.5 or something like that. You never see a song with a tempo of 150.5.

I am a software engineer, and granted I have no idea what Fractals code base looks like. One of my concerns as a software engineer, is that using the fastest subdivision on the fastest tempo may be approaching the limit of the _update() functions. If that were the case, the software would have to call _update() more often to accommodate some of the faster subdivisions of the fastest tempo to process any subdivision/tempo combination. The more times you have to update, the more CPU the effect may require.

TLDR from the above paragraph, it is possible that allowing decimals in the tempo could cause the delay algorithms to require more CPU, but that is just a speculation. I think allowing decimals in slower tempos only could avoid that potential pitfall. Only Fractal knows how easy/difficult this could be to implement though.
 
Casimir said:
I wonder if this could be implemented similarly to floating point numbers. Essentially, you could have faster tempos not allow any decimals, but as the tempo gets slower, allow decimals. I think most song that require this feature have a tempo of 70.5 or something like that. You never see a song with a tempo of 150.5.

I am a software engineer, and granted I have no idea what Fractals code base looks like. One of my concerns as a software engineer, is that using the fastest subdivision on the fastest tempo may be approaching the limit of the _update() functions. If that were the case, the software would have to call _update() more often to accommodate some of the faster subdivisions of the fastest tempo to process any subdivision/tempo combination. The more times you have to update, the more CPU the effect may require.

TLDR from the above paragraph, it is possible that allowing decimals in the tempo could cause the delay algorithms to require more CPU, but that is just a speculation. I think allowing decimals in slower tempos only could avoid that potential pitfall. Only Fractal knows how easy/difficult this could be to implement though.
Click to expand...

I am fairly certain that all delay, reverb, LFO, etc computations are being handled in milliseconds, not tempo. Since these are already in decimal, I see can't where any computational overhead would be increased.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom