BrainModular

Hi ,
I'm experiencing a strange problem : i've recorded some racks with the direct-to-disk option in hollyhock, and then imported these files in cubase. The tempo is exactly the same for the both, but files bounced from hollyhock are a bit shorter ( or faster..). I feel it could be a problem with the résolution, but i don't understand clearly the rules, and i'm in a hurry for i have a l.p. to finish these weeks.
My session on cubase is in 24bit. I don't know for usine (32 floating ?..). What should i do ?

Yep. I had the same issues. The tempo is clearly drifting, which is very strange. When I have something in Usine running 125 BPM and record it out I end up with a *real* tempo of 124.8643 or something arkward like this. Very odd. Also even this number seems to be non-consistent.
(Which means even when I put Logic to exat that tempo I still have to re-edit parts, which is cleary a sign of tempo-drift...)

You have to run a good BPM counter to find the approx. right tempo and then cut your regions to ft to your DAW-Grid.
Also record *everything* in one go. When you record in more than one go (like in stems or several takes) theese will often
not even fit with each other...

It seems that not a lot of people here use Usine for actual real life production purposes,
because this issue would have come up earlier for sure.


Best,
tL.

Thanks for your answer,lytz,
Well, with my 7 tracks of 5' each, cutting in little slices throughout all the songs will be a big loose of time. If there aren't any other way, i'll do it.
But indeed, it's curious that this problem (which is pretty embarrassing) hasn!t been already mentioned.
Maybe should i submit it in the bug section, if it get no explanation or solution.
And what i was wondering,again, was about the resolution of the recording in hollyh.
Which it is ,and can it be changed ?
Regards.

Resolution on recording is *always* 32bit, and AFAIK can't be changed... unfortunately.

And no, there is no other way than to re-edit... unfortunately..

But good for you that you only have a couple of tracks... My case was, well, lets say way way more difficult to tackle because of very high track count (+40) and
completely finished arrangement on two full projects.
And I lost *quite* some time getting all that sh** right in PT and Logic, I can tell you that.. (Including a lot of swearing from my end.. )

tL.

bitdepth has nothing do do with time, it's only affecting wav amplitude resolution, 32bits float vs 24 fixed point has no impact on tempis/timings and is clearly fine enough for quality reproduction no worries about that. be sure problem doesn't come from this wav record 'resolution'.

what can create such problems, (and is somehow 'normal' math problematic) is related to blocs rounding 'resolution', wich is linked to asio buffers and usine bloc defined sizes.
For exemple if a sequenced swich loops a bar at a given tempo, it would need let's say (random chosen, wrong numbers) 1045,67 blocs of 128 samples buffers to fit a mathematically 'perfect' 120 bpm tempo bar lenght duration, but a bloc cannot be split, so roundind to the nearest integer multiplier of 128 samples give for exemple as nearest value 1024, not 1045,67, (8 blocs of 128 samples = 1024, 9 blocs would make 1152) so it makes the loop restarting tiny earlier or later than it would 'ideally be' , so a bpm tiny higher or lower results at the end.

So the smaller the buffer are, the higher 'clock resolution' will be, less important roundings may occur, the tighter and more precise 'tempo precision' in a patch will be. Also when clicking on tempo field man can activate "perfect syncro" option, that will, related to this problem, shift actual tempo to the nearest tempo that fit a perfect integer number of blocs.
hard to explain/visualise, but hope that makes sense..

edit: made the computation with real values just as concrete exemple, no need to bother with such stuff of course, but just thought could help to get the idea of the underlying math inherent problem occuring and the way it can be dealed:

we choose tempo is: 120 BPM
what is the duration of a bar at 120 bpm?

1 beat duration = 60s/120 = 0,5 second
1 bar duration = 4 beats = 0,5 x 4 = 2 seconds
-> bar is 2 seconds long.

samplerate is 44100 samples per second

so this 2s duration bar = 2 x 44100 = 88200 samples.
-> bar is 88200 samples long.

how many blocs that makes using 128 samples blocs:
88200 / 128 = 689,0625 blocs

everything going thru wires is refreshed and computated at bloc resolution rate, so ie a loop restart can only happen at bloc 689 or 690, not bloc 689,0625.

whats the nearest integer: 689 blocs
wich makes:
689 x 128 = 88192 samples
wich makes:
88192 / 44100 = 1,99982. seconds
witch makes:
1,99982 * 60 = 119,9892 bpm...instead of 120 BPM, here is why drifts occurs.

if we activate perfect tempo,
usine will use 119,9892 as tempo, bar will last an integer and constant remaining number of blocs (689) instead of alternating between 689 and 690 to match 120 bpm,so no rounding should occur, no drift if re-applying same tempo.

2 separate questions, OP and myself know that bit depht has nothing to do do with time, just sayin.

But the main point here is:

So you need to explain in 100 lines why the tempo behaves how it does,
when in *every other* music application in the world you set the tempo to 120BPM, and
120BPM simply is 120BPM granted, period?!
Wow. :rolleyes:

(But thanks for your explanation, very helpful indeed. No offense here against you in particular...
And stuff like this *needs* to be known...by everybody that buys this thing, otherwise you will go NUTZ when
you export stuff to a *real* (!!) DAW...)

tL.

@23fx: good answer !

@lytz1: "every other" application are not modular!
In Usine the precision of the tempo depends on the patch you use or what you are doing. for example the grid can resync automatically.

Also tempo precision is not necessary higher in others DAW, it is simply different.

Moreover, you can try run the same project on 2 different computers, you'll notice a drift because CPU frequency drift over the time differently (few seconds per hour)...

So definitively 120 is not 120...

ps: In the next major release of Usine the tempo precision will be highly improved but always dependent of the patch you use.

senso++++

ringmodulator wrote:Hi ,
... The tempo is exactly the same for the both, but files bounced from hollyhock are a bit shorter ( or faster..). I feel it could be a problem with the résolution, but i don't understand clearly the rules, and i'm in a hurry for i have a l.p. to finish these weeks. My session on cubase is in 24bit. I don't know for usine (32 floating ?..). What should i do ?

sorry i maybe misunderstood, but that didn't seem that clear in op thread that they were two separate unrelated questions...

i can't count the times where i imported bought commercial tracks at said 160 bpm and had to enter a floating point number like 160,04 or 159,XX in ableton live for a perfect match from start to end transients perfectly match the grid. now i agree that most remain more consistent when exporting but as said they are not modular neither allowing per patch different locals syncs
if wanted, I would have pointed to the manual instead of long exemple but the 'bloc processing' page that was explaining this gloabl usine concepts and strategies is currently being rewriten for new versions.

if you are aware of the problem and working with low buffers bloc size and perfect synchro option the warp is quite fast and not that problematic, i really often export stuff from usine back to ableton live.

Ok..i get it. Things are more clear for me now, and the detailled explanation of 23fx23 are welcome.
So, it's too late for my present session which contain audio tracks on the daw.
But next time i want to incorporate files from usine in it , i'll do like this :
1-estimate my needed tempo.
2-first write it in usine, then choose perfect time.
3-enter the new tempo in my daw.
4-then start the project...
...and there should be no problem.

I wonder if adding ableton link to using would be possible?

I was also wondering about ableton link as well.

senso wrote:@lytz1: "every other" application are not modular!

I beg to differ... Max/msp, Bidule MuLab/MuTools and to some degree numerology and also Audio Mulch are modular... But still the tempo is persistent...
Worked with all of them on a regular basis. Buzztracker is/was modular as well, didnt have that problem neither..

senso wrote:Moreover, you can try run the same project on 2 different computers, you'll notice a drift because CPU frequency drift over the time differently (few seconds per hour)...

So definitively 120 is not 120...

Would like to hear more about that. As I am a full time professional electronic music producer and touring DJ since way over a decade with a couple of hundret
full release productions under my belt and had tons of projects swapped between several different studios and even every major DAW-Host
outthere and in my memory 120 was always 120...

Also I would like to know more about that as I am also still a touring DJ every weekend all over the place and regulary edit sets in the studio for promo, radio or other stuff which is then usually at fixed 123, 125 or 127 BPM. And they are way over one hour and still... the tempo is steady.. can read that off my CDJs all the time. Not a .x tempo rise/drop in neither direction, so do you maybe have a link or something to read, because I find this statement *highly* interesting.

And by the way, not everybody uses Auto-Synced Software like Ableton Live..

Best,
tL.

afaik max MSP got also a buffer size you set in "vector size" wich sets bloc rate update , not everything is computated at samplerate,most objects bangs are at blocrate.
if you make a simple metronome patch trigering a sample at 120 bpm man can see using a 256 buffer sized vector
output tempo is not exactly 120 bpm. i just made the test: reced a 16 bar loop, getting wav imported back in ableton live:
it need to be interpreted at 120,01 for perfect grid match, this just over 16 bars. if using 120 loop is tiny shorter and man can see the overlap when zooming

and this second/double check is even more interesting
this time a 32 bar loop was rec, and letting 120 bpm would make last transient beat of loop being correctly in sync this time.
...but.. if we look more closely what hapen in between, at bar 7 the sound is too early on grid, whereas at bar 17 it's late.
this is clearly a sign of drift and not consistent output resulting tempo, wich imo is occuring for exact same buffer rounding system raisons..

I see. Strange. Never ever ran into any problem like this except like the two projects I did in Usine.
Thanks for input.

Best,
tL.

lytz1 wrote:I see. Strange. Never ever ran into any problem like this except like the two projects I did in Usine.

it's a good new, Usine makes us more advised !

I have just spent a good amount of time trying to record a loop from my external hardware into a sampler and have it play back in sync, but it would always drift. What I discovered is that, similar to what was noted above, is that if I put a local sync module with a slightly lower bpm in the patch containing the innerclock Sync Gen VST that sends (rock solid) MIDI clock to my external hardware, I could have the loop play back perfectly in sync with the hardware that it was recorded from.

What seems odd about this to me, is that Usine is responsible for both the master sync that drives the Sync Gen, and the sync that is recording and playing the samples.. Seems these should be identical, no? Instead, if I record an audio loop into the sampler with Usine at 120 bpm, in order to have the recording and playback synchronized I need to set a local sync for my Sync Gen at 119.85 bpm. This just makes no sense to me, unless of course Elektron is consistantly out by 0.15 bpm on all their machines, or the Sync Gen is putting out a different tempo than what the host is telling it to.. I think not. I think Usine's synchro when recording audio may be out of calibration. This would explain why even when using a sample player as a source, I am unable to synchronize a continuous buffer recording to another sampler.. Will investigate, I guess..Or maybe best just put this project aside until HH3.. ??