Traktor Scratch Pro - Loading problem!

So I've been messing around with Traktor (1.2.5) for the past few weeks. Mostly haven't had any problems at all, but I have had a loading problem....

I'm dragging my tracks from the "explorer" folders (all tracks have been analyzed), and I'll be spinning for about 15min when all of a sudden, each time I load a track and press play on my cdj, the deck will just turn a solid yellow color and there will be no playback. If I reload the track, and press play on the cdj, it will be fine. This will happen with every single track after the 1st 15min of spinning. The weird thing is all tracks load perfectly fine when I 1st start playing.

I also re-calibrated the timecodes by pressing the "rst" button and then pressing play on the cdjs....still the problem keeps happening.

Am I missing something?

 

by the way, i'm using a mac.

help!

 

I had this problem once before. Try a full uninstall/reinstall of Traktor. Back up the entire Documents/Native Instruments/Traktor folder offline somewhere, then uninstall Traktor using something like Appcleaner. Then reinstall and restore the collection.nml, any pertinent TSIs, etc.

 

backup the folder on an external hard drive or something? the entire traktor folder in my applications?

then i'd uninstall, then reinstall from the cd (which is 1.2.1) and then run the 1.2.5 update?

 

Yeah for backup I usually stick it on an external drive or at the very least copy the folder to my DESKTOP folder in OSX

Uninstall and reinstall but instead of 1.2.1 then updating, just download the update from the Support section of this site. Eliminates the extra step of installing then updating via Service Ctr.

 

ok i'll give it a go

 

GL. Holla if you have any further issues.

 

oh, 1 more thing....i have the educational version of traktor....can i simply uninstall and reinstall it? i won't get any problems?

 

You should be OK if you're installing it to the same machine but don't quote me. I use the full version because I profit from its use.

 

Sounds like you're experiencing the "notorious" relative mode problem.

When you stop the playback of track #1, you presumably just press CUE (or PLAY, it actually doesn't make a difference). At this point, Traktor "knows" that the last time it "heard" timecode, it was @6:05 (or whatever the length of the track was). Now, you load a new track, and have skipped to the beginning of the timecode CD without telling it to Traktor... so, when you press PLAY, it notices that "ah-ha! you just skipped 6 minutes from the last known position backwards" ... and jumps into the lead-in -area of the song. Now, if you just wait 6 minutes, and let the timecode play, your song will start.

Or, alternatively, you could switch to absolute mode, back to the beginning of track and continue from there.

Because of this, every time you do something that doesn't output timecode, you should tell about this to Traktor by a short click of CUE-button. This way Traktor can keep up with you.

Of course, on my opinion, assuming that when you load a new track that "whatever position it starts from" is not the "current position" is justy plain silly on NI's part.

 

yah disconova, that sounds like the issue. that's exactly what's happening. but what is the difference between absolute or relative mode anyway?

by the way, i have uninstalled/reinstalled traktor, so we'll see if anything different occurs.

 

If the problem is the one I described, I don't think a reinstall will have any effect (to one way or another). What I've described is a feature... it can be remedied by changes to the application, but still, it will require a fair amount of guessing what the user actually "attempted to do".

I'm not saying that it is not fixable, because it can be "fixed". What I mean is that even if a fix is implemented, the software will still get it wrong sometimes (but - on my opinion, fixing this shouldn't be too hard; usually, when we load a new track, we do want it to start from where we are at, not from where we are in relation to where we were before).

This one actually is quite an interesting question... basically there is quite a huge difference.

Absolute mode means that whereever you are in your timecode, that is exactly where you are on the track you're playing. What this means that if you skip a minute of timecode, the playback of the track will skip one minute. If you do a spinback on timecode, the track will spinback accordingly.

Relative mode means that only the speed and direction of the timecode are handled, but nothing else. If you do a spinback, that will work. If, on the other hand, while playing, you use a hotcue on the CDJ, nothing will happen - the playback will continue as if you never pressed the hotcue button; your track is still going in the same direction at the same speed. This was how the earliest TSP versions worked...

What makes things a bit more complicated is the fact that Native Instruments implemented "advanced relative mode" (I still don't know what they call it actually). This means that when you spinback, that will work as expected. Also, if you make a loop on the CDJ, that will work (when the timecode skips from the end of the loop back to the beginning, the software will make the audio track do the same). Also, the hotcues will work (up to a certain limit). Basically, it no longer matters, where the actual playback position of the timecode is at, the track usually works as you'd expect it to...

The advanced relative mode was implemented because the absolute mode has it's problems (because we never actually know where the track "really" starts) but also to make features that (in most timecode controlled software) only work in absolute mode to also work in relative mode...

...Unfortunately, NI made a minor mistake during implementation; the relative position of the timecode is not cleared when a new track is loaded. This is causing the somewhat unexpected behaviour. From software's point of view, nothing is wrong. For the user who does not think like the software, things do appear "wrong".



As said earlier, there is an easy fix - it just requires a tiny change into workflow; when you do something that does not output timecode (like pressing CUE, or pressing PAUSE followed by <<, or something similar) ... just click the CUE-button (since this will output enough timecode for the software to realise what happened) and things should be alright again.

 

Do you recommend still playing on Relative Mode? If so, how do you prevent this from happening - could you elaborate on what your solution was? All I do now is that when the block occurs I press |< on the cdj so that its 0.00 on the CDJ on track 2, and then press CUE - and TSP has loaded the track at the start, where it should be.

I've been in contact with NI over the issue and that yellow block is definitely the lead in track.

Screenshot: http://i39.tinypic.com/11h3xg2.png

See how there is -3.47 remaining but the track is actually 3.37 long?

 

Definetly. When thinking of DVS, relative mode is actually the only one that makes sense. In fact, NI's advanced relative mode is the best thing since sliced bread (or possibly even better than that).

With that being said, this might come as a bit of a surprise, but I have Preferences > Timecode setup > Switch to Absolute Mode when loading checked. The reason for this is that it fixes most of the problems. I've also checked Preferences > Loading > Initially cue to Load marker ... with these two settings things usually work the way I want to. Whenever I load a new track, the software will go into absolute mode... but if I have a load marker (set at the point where the audio actually starts) set, TSP will stay in relative mode... and it works exactly like I'd expect it to.

I think I might need to do a video of this... English is not my first language (not even my second one) and I think trying to put this in words might not be enough

This is something I learned already when I was first experimenting with timecode controlled systems. Not much has changed since, and for most of the systems, everything still works like at that time.

Anyway, since the timecode control relies on receiving the timecode from the player, there are certain things that don't work as one would expect. For example, if you're playing a track, no matter how you make the track "stop", it always stops in the same manner - exactly where you were (because there is quite a large number of reasons why the timecode would stop; you could press CUE, you could press PAUSE, you could even press EJECT, or set pitch to -100%).

Because of this, if I intend to "reset" the play position, I doubleclick on the CUE-button. Similarly, if I press the "previous track"-button - in order to get to the beginning of the timecode track, I follow it with a fast click on CUE-button. If I press PAUSE, I don't do anything else, because the software already is where I want it to be; when I press PLAY, I expect it to continue from where it stopped.

Hope this made any sense

 

duckpatch....this is exactly what i'm going through!

i'll read all the above comments disconova, and comment shortly
---
disconova, you've been very very helpful. this all makes sense, now all that rests to do is to try it out, lol.

i'll give this all a try, and will report back. and perhaps if it doesn't, a short video clip would certainly help in better explaining.

thanks again!

 

ok still running into some problems disconova....

are you saying that to avoid this problem, i need to make sure that before i load a track into one of the decks, i need to make sure the track before is back at it's starting point?