Absolutely love the Tracker; new to it and having a blast.
I searched this question but maybe i’m bad at searching, Anyway, I have been rendering full bars of my tracks in order to be able to slice them up and manipulate the rendered sample further. The issue I have run up against is that although I set up the render start and end point properly the Tracker always records a sample with a much longer tail than the existing phrase. For example, if I am attempting to render a 16 step phrase (which is the full length of a pattern) I will always end up with a sample which is much loner than those16 steps. At first I thought this was due to reverb and delay tails, but further investigation proved that no matter what I did the Tracker adds additional time to the end of the rendered selection.
I have figured out a workaround for this which is to use a BPM calculator to determine the desired length of my sample and to crop the sample to this length using the sample editor. this works very well and my rendered selection can be sliced properly and play back in time with the original step length of the phrase- not the end of the world by any means but it is more time consuming.
Hi @ianlary, you are not missing anything , it’s a known bug at the moment:
As a workaround for now - after rendering a sample don’t Render & Load.
Instead just render and save it, then go to the Sample Loader and Import it, this allows you to cut off the excessive empty space right during the import.
Figure out when your sample fades out by auditioning, note where it ends, then temporarily shorten the pattern to this length, press record to edit on the desired track, press shift > insert, then shift UP (D-pad) then render. Increase the pattern length to where it was previously, then go fetch the samples from exports. It might help to top and tail the sample with normalize and check the trim if necessary.
I’m slightly confused by the tip you offer. I think I understand that you are suggesting that before rendering the selection I would:
Audition the sound and use the SHIFT+ ARROW keys to define the start and end point of the sample?
In my case, I have been rendering selections at the full step length of a pattern- by this I mean, for example, my pattern length is set at 16 steps and 16 steps is the desired length for my final rendered selection.
It seems that you are suggesting that I start with a pattern with more steps than I intend to have and to manually define the rendered selection to 16 steps ?
I’m sorry to be obtuse- I’m having trouble grasping the trick you suggest holistically.
Because I plan to slice my rendered sample in equal parts and have it play back seamlessly, the slices will need to add up to 16 steps ( in my example). What I’m saying is that I already know the length I desire the rendered selection to be and I’m not sure what you are advising as far as auditioning the sample to locate the fade out point?
OK! l’ll try this with a percussion loop and see if there’s a workaround. It seems that sometime in the past, I encountered a similar problem and solved it using my convoluted method. I’ll reply with my findings.
Disregarding my previous tip, today I built a little percussion pattern 32 steps long and rendered it ignoring the apparent tail at the end of the rendered wav. I normalized the file as it was, then using sample edit, amplified it, by a few dB, as it was still bit too quiet after normalize. I then triggered the render, side by side, on the next track to compare to the original loop. The timing was correct and the sound quality very close to the original loop.Most of the information about rendering is found between page 228-224 in the 2.0 version manual (including the fine print).
n.b. If your using Slices on a rendered file for rearranging your slices, the overall length of the rendered file wouldn’t make any difference, since your Fx1 or Fx2 slot will use the desired slice you want to sound on each step. In my test at 130 bpm I didn’t have to trim the rendered sample length at all to obtain timing accuracy.
Yes, it will play in time if you trigger them both rom step 1- the issue is that when you slice them into EVEN SLICES in the sample playback engine - the extra tail makes it impossible for your slices to be the correct length and be synced properly, no matter the step length you desire; it also makes it 99% impossible to have seamless timing if you manually slice or slice them via transients- again as a result of the elongated tail. This is why the BPM clock workaround I mention in my first post is necessary.
If you dont need the slices to be tempo synced perfectly this is not an issue- nor if you want to render something like a chord. It’s only when you need precise time syncing that the issue is noticeable.
Thanks for taking the time to do a test- very kind of you.
Can you send me a straightforward, simple example to look at? I’ll check it out tomorrow EST. Any comments here from the more experienced tracker users would be great. thanks!
Hi Eric,
Thanks again for engaging. I’m not sure if you read the first reply to my question from Sandroid in which they state that we are dealing with a known bug. I don’t think there is another another workaround better than the trick I figured out using a BPM calculator. I’m sure other users have landed on the same solution as I discovered, so that might be what we got going atm.
I think the easiest way to understand the bug, if its making you itchy, is to set up a 16 step pattern and render the selection. Load the render into a new track and try to evenly beat slice the pattern you rendered; you will understand the issue right away.
I think its safe to say that the Slice routines need some work. Best results so far are either your method or simply Render ,Normalize, Crop, amplify if needed and use “slice evenly” then zoom in to fix the chops(slices) manually. It would be nice if there would be an option to slice per step and that it be accurate. When you use auto slice it seems to only slice by detected transients. I’d like to add that the quirkiness of the slice routines as of present, are sometimes very useful and interesting when applied artistically.
Yeah, for sure. I don’t really have a problem using the workaround but it would be nice to not have to break out a calculator.
As far as the method of Render, Normalize, Crop that you mention- that works great for everything except when you want the chops to fit within a specific bar length, without them running short or running over each other- so it’s a very specific bug. You can still use the beat calculator to determine the correct length and then, alternatively, use Auto Slice, or set the chops manually- not limited to only the Even Slice function. However, if the length of the rendered selection doesn’t match the BPM and number of beats you will have uneven results- which can be cool, but if you want to be able to chop up and reimagine your own song, as the Tracker operates atm, you will need to determine the exact length in milliseconds of your sample.
This is off topic, but, Apart from using a DAW, I’m still wondering how to incorporate, for example, a long vocal, synth, or ambient field recording into a songs structure.
On-device option that is an ol’trick from the ol’ days:
Sample/render a long sample at twice (or higher) speed and then just pitch it down on the Tracker. This can save you a lot of space, will have some quality loss but depending on the complexity of the sound it might be minor.
Off-device options:
a dedicated little sample box like a 1010 Nanobox Tangerine
Use Line-In and hook up a Field recorder directly for playback
I guess what I mean is rather, because the steps per pattern are limited to 128, I would have to chop up a longer sample into multiple sections. If a long sample is used that goes throughout a song’s structure, i.e vocal, lead line, solo of some type or ambient texture, it would be a nice feature to allow it to play throughout a song until the sample’s end without a lot of extra editing.
Of course you can simply use another sampler with more memory in tandem in a live situation or a DAW.
Here’s the BPM calculator I was using. Any one of them will do, of course. The thing to remember is that the calculator spits out the SEC amount per measure- so if your pattern is 32 beats, you would multiply your Measure Duration x2. if you have a 64 beat pattern, you’d multiple x4, etc. etc.
Once you do your math, jump into the Sample Editor and crop your sample. Now no matter how you chose to slice it, the timing will work.
I don’t mean to be condescending by explaining if you already understood the process. I only spelled it out after rereading my posts and realizing I was being very vague.
, it’s a known bug at the moment:
