I need tight bpms! syncing to other apps doesn’t seem to be an option for me because I like to work at very high speeds. like if I am doing something at say 200 bpm I set it to bpm 400 spd 3. but it comes out to 399.8932 or some shit. none of the hardware I have can do more than 2 decimals on the bpm. most does 1. I don’t want to use cubase anymore!!! I want to use a tracker, this tracker! alternatively, anyone know a small app I can run in the background to send clock to renoise? this’d be a decent workaround for now, but I really do think these needs to be taken care of.
I wanted to know if there was a small cpu sympathetic app I could run in the background to send bpm to renoise. so I can slave renoise to this. as far as 150 bpm not being 150 bpm, I have tested this by exporting a loop from acid at say 192 and throwing it into cubase and renoise, in cubase it is fine, but in renoise it is not. so maybe what I want is for renoise to be closer to what other apps think is the real bpm. I know that about the song properties btw, that’s how I realized shit was so off. nice it says what it actually is anyhow… I remember from speaking to people years ago that used ft2 that the bpms were off. hopefully if it’s not based on this tick timing shit’ll be tighter.
no, the problem is much easier than that … it’s basically an old optimization trick used in dos-trackers on pc… when mixing tracked music, you need a number called samples per tick (spt), and the tempo of the tune relies on that. in most pc-trackers (including renoise!) this number is stored as an integer, meaning there are no decimals. as the spt number usually includes alot of decimals, the tempo gets a slight ‘bug’ and the bpm you enter in the tracker is not exactly right. this also explains why some bpm numbers are correct … (those numbers include an spt that has no decimals)
so the fix is simple, make the spt a float that allowes decimals instead of an integer. or at least, make a switch so that you can use ‘real’ bpm or ‘tracker’ bpm… this would make things alot easier for guys like snares. and i mean, with todays fast pcs, this optimization tweak really isnt needed.
and oh, if you search for older articles (those that the search tool here usually excludes) you’ll find a more to-the-point technical explanation of this.
I have no idea if such fix would be easy… maybe in general for the pattern handling… but there is a lot more connected to this tick/speed rate than just a few patterns being scrolled up.
I filed a suggestion to use a millisecond per tick so each row would have 100 ticks.
In that case you can have real bpm used in the play controls area anyway (with or without decimals).
But this would impact upon all of the current pattern effect commands and would also make automation suffer from inside precision. (there are a 100 positions per row you can’t automate that way).
So to say so:each simple idea that would fix one area would make another very complicated or not really usable.
Paron me to interupt:
If I switch to another soundcard on another sample rate,
I also have the feeling sometimes that the track is going faster or slower than original, or is this just me…
Even the CPU and other components may have influence upon timing if we discuss realtime rendering (meaning:playing the song).
This should be tight when rendering to disc, but i admit i’ve heard from developers of other audio/video applications that they use the hardware-drivers of the audio/video devices to render output because rendering goes quicker that way…
So much for the native assumption this always was performed on software level (which is imho the most predictive and stabile method).
I too feel the pain of bpm problems, particularly when syncing to hardware clock signals.
In my experience, in the osx version the clock signal received from my mmt-8 takes a while to adjust to the proper level, i.e. renoise starts playing too fast, then slows down to the right speed. However, I haven’t tested this further so can’t yet tell if it’s my mmt-8’s fault, or renoise. Thankfully over Christmas I’ll have a bit of time to look into this stuff.
Snares, if you use OS X there’s a little app called MidiClockwhich spits out a clock signal, but for what it does it’s not very cpu nice (uses approx 8% of my ibook cpu). Again I haven’t tested how it behaves with renoise.
Hint:You can try to scoop the forum archives for topics based upon “real bpm” and see if you can find any devs replies to it.
Make sure you tag the search date option for “any” or 30 days and older"
