performance killer revealed

[KrzysiekK]

In research of what causes weird problems with T3, I noticed it is logging various events ALL THE TIME (writes into log.txt). It even captures every move of automation env point! Similar thing with playback.

Looks like DEBUG mode is turned on by default in this application (we all know why...). It is well understood that turning this "feature" off will help to get rid of some certain performance problems. Is there anyway to get rid of logging process in T3?


I observed when T3 exactly writes into log.txt.

Guess what... the problems with playback start exactly when T3 starts writting into log.txt. What it writes? Something useless like this:

9:29:12 pm 1

not only when editing but also when playing back !
according to log, it sometimes writes above messages few times per second !

Here is why I still can't use CC/automation successfuly. Too bad that Mackie apparently forgot about their product already.

Simply turn off DEBUG mode in this software and let me do my job.

Nothing about that in manual...

[artlowell]

That's interesting. I have been unaware of a "de-bugging" feature. Are you talking about playback problems only? Where do you find the option to turn the de-bug off and on? I didn't find it anywhere on the settings page.

As you say, the manual is useless on this (as is so often the case).

[KrzysiekK]

That's interesting. I have been unaware of a "de-bugging" feature. Are you talking about playback problems only?

As you say, the manual is useless on this (as is so often the case).

According to my further observation, I will try to be more specific:

- when I just load a new edit and do not touch any automation points and just playback then there is no weird logging issue
- as soon as I move any automation point, logging starts and T3 loggs even during moving the transport cursor. It is logging like a crazy all the time (yes I checked it several times). But it is enough to switch to eg. "settings" tab and then go back to edit tab and everything's OK since then until I move any automation point - same problems occurs again

so it seems like T3 is strangely starting intensive logging since editing the automation curve. Sometimes it just unlocks itself and starts working w/o logging for a moment, but then I just do another automation edit and bang...

my second observation (second one which I am sure about) is that when Tracktion3 exceed some limit of number of VST/VSTi loaded, there start CPU hiccups - 100% of use with no reason - I tested by playing back just one VSTi opened and a few automation curves of this VSTi). It must be noted that it does not matter which plugins are on Tracktion3 list (VSTCACHE in T3 temporary dir) - I tested with different plugin sets, there was no rule - T3 always started its problems after exceeding some number of VSTs.

What is particulary strange is that these plugins are just on T3 list - i.e. they are not loaded at the moment when the problem occurs.

Where do you find the option to turn the de-bug off and on? I didn't find it anywhere on the settings page.

nor I - hence my question how to turn it off. Anybody knows? My only idea is to direct T3 a RAMDISK directory to make things kinda faster (write log into RAM directly)...

I tried setting temporary directory to the removable drive and make T3 to write into readonly device (heh ) but ... well, here the application is very clever and jumps into old temp dir as soon as it detects something's wrong.

Best regards,
Krzysiek

[KrzysiekK]

TIP TO ALL TRACKTIONERS (in some circumstances may improve the performance greatly):

- in "SETTINGS" tab, go to "FILE SETTINGS" group; check the temp directory path
- close Tracktion3
- with any file explorer, open the Tracktion3 temp directory and find log.txt file there - give it readonly attrib

Tracktion3 will not log anymore - it will probably still attempt to do this all the time as I doubt it will give up when recognizing readonly attrib (but who knows...), but there are no write op1erations performed to harddrive anymore.

for refference: this is Tracktion3.0.4.8 running on PC machine

Krzysiek

[oxbee]

Here's a workaround.

Remove all the rights to the file "log.txt". Just put the SYSTEM and your current user as "read-only" and remove all the other rights. Also, you will probably need to uncheck the "inherit rights from parent..." in the advanced parameters of the file Security tab to be able to change those rights.

The file won't be written anymore. I've just tried that and it works. Nothing has been logged since I've changed that. At least, it forbids Tracktion to physically write datas to a file but the logging still exists anyway.

It sounds silly to log anything like that but on the other hand it shouldn't kill the performance.

Let me know if you feel any difference !

EDIT: looks like we had the same idea at the same time. I just used the system administrator way !

[UncleAge]

It sounds silly to log anything like that but on the other hand it shouldn't kill the performance.

Maybe / maybe not. I won't pretend to know the inner workings of things in T3 but read/writes to a text file is not something I would program my app to do while other high priority processes were occuring. Its neither here nor there really since we don't know if Mackie looks in on this forum any more, but it is an interesting find...

[UncleAge]

Simply turn off DEBUG mode in this software and let me do my job.

I wonder... If we had 100 or more users email Mackie all at once maybe they would comment on this. It does seem to be logging as if it were in some debug mode.

[mystran]

It sounds silly to log anything like that but on the other hand it shouldn't kill the performance.

Maybe / maybe not. I won't pretend to know the inner workings of things in T3 but read/writes to a text file is not something I would program my app to do while other high priority processes were occuring. Its neither here nor there really since we don't know if Mackie looks in on this forum any more, but it is an interesting find...

Yup, and since it's debugging stuff, I wouldn't be surprised if it further forced the data to disk (well filesystem cache, but get the point) after each and every line of data (something you have to do to get useful logs when hunting crash-bugs), making the problem potentially much worse.

I don't have Tracktion so no idea about the details, but it really sounds like something someone forgot there..

[MelodyMan]

Wow. This tweak makes my T3 much more responsive! Thanks guys .

[artlowell]

I think this log.txt thing must be PC specific. The only similar files I find on my hard drive are Quicken related. BUT:

my second observation (second one which I am sure about) is that when Tracktion3 exceed some limit of number of VST/VSTi loaded, there start CPU hiccups

This was what inspired me to learn how to use multis rather than bring down a new sample player for each instrument. Initially, it was a matter of saving memory (something like 1 MB per sample player). Ultimately, I learned a little bit about how CPU usage was involved. With each instrument loaded, a sample player will generate a certain amount of "background" CPU usage whether there is any MIDI data present or not. Enough instruments in a multi and the CPU can become overwhelmed. The answer to that was managing latency (settings>audio). Increasing latency will stop those pesky CPU hitches. I also learned that, while there are 16 channels in a sample player, it can be overloaded with too many instruments. I hit my limit at 8 or 9 with SampleTank. The cure was to start another multi.

With experience, I have found many nice things about using multis, not the least of which is that it is easy to save a multi as a preset, thus providing an extra measure of backup protection. Between that and archiving frequently, there is little reason to ever lose any of my work.

[rainydays]

It does the same thing on the MacOS build. Not sure why it would be a resource hog though. Compared to the amount of data that is written while recording a track it's pretty much nothing, but perhaps there's something more to it.

I can't say that I noticed much difference when locking the file here.

Either way, it's most likely not intentional, probably some debugging code they forgot to uncomment.

[UncleAge]

I can't say that I noticed much difference when locking the file here.

Me either.

[MelodyMan]

I can't say that I noticed much difference when locking the file here.

Me either.

Strange. On my system it is very much noticeable. Especially the graphics seem much smoother and faster.

[KrzysiekK]

Hi

my second observation (second one which I am sure about) is that when Tracktion3 exceed some limit of number of VST/VSTi loaded, there start CPU hiccups

[...]With each instrument loaded, a sample player will generate a certain amount of "background" CPU usage whether there is any MIDI data present or not. Enough instruments in a multi and the CPU can become overwhelmed.

actually, the problem is regardless the plugins are loaded or no. Simply - the bigger VSTCACHE library is (list of VST plugins available in Tracktion), the worser performance, even if you have just one plugin loaded within an edit. Strange, isn't it?

Krzysiek

[KrzysiekK]

actually, the problem is regardless the plugins are loaded or no.

Further on this - I just prepared a large VSTCACHE list consisting of NONEXISTING VST plugins. So this is just a large fake list. Set Tracktion not to scan at startup. Tracktion still suffers from the performance issues, though in this big VST list just one plugin exists.

This proves that T3 has problems with resources management.
The VSTCACHE list in T3 should be used for two initial purposes ONLY:
- to fill available plugins list (the list when adding a new filter)
- to check whether plugins used in edit exist

these are initial jobs and should not affect performance during work with an edit. But there is severe impact (on my PC the CPU use raises from 2% to 100%; with same edit, just one plugin loaded and some automations; 0%-2% I get when VST list is almost empty; 100% I get when I use full list of all plugins).

---

another observation: according to Process Explorer tool, Tracktion keeps performing constant I/O operations (around 200 per second, all the time), right after loading the application, without opening any project. It is just idle (should be). Note that these are not HD operations.

Krzysiek