After having a burning desire to track how much time I actually spent on each of my songs, and reading a few requests for such a thing in the forum, I put a time tracker tool together.
It’s a totally automatic time tracker for monitoring time spent on each song. If you have the tool installed, it will just work in the background, without altering your workflow in any way. If you choose to open the tool’s dialog, you’ll see the tool window below update in realtime based on your usage.
Saving the file will save the tracking information for the time you spent. If you open a file, fiddle a bit, and close it without saving, no tracking data will be altered.
The tool classifies time spent based on activity, for insight into which tasks take the most time.
To do this, the tool will create a report file alongside each of your opened XRNS song files:
songname.xrns - Your Renoise song file
songname.time-report.txt - A text file containing a human-readable report of how much time was spent on the song. Updates automatically whenever you save the song.
Uploaded a fixed version 1.1 with improved performance and code quality, and a couple dumb bug fixes. Please update to the new v1.1 version if you’ve already downloaded.
PS. Maybe it would just be slightly better if data was saved encoded in song comment. I tend to save a bit of xrns files on my desktop, and it can become cluttered
I agree, that would certainly be cleaner. But you can’t update the comments on song save without dirtying the save state, requiring another save to really save them (i.e., hooking into renoise.tool().app_saved_document_observable). The alternative is to periodically update the comment with the data every N seconds, but there’s no way to know if the comment is currently being edited in the Song Comments dialog, which can cause line skips and lost characters when editing song comments (when the comments are periodically updated by the tool). The API would need something like renoise.app().window.song_comments_is_visible to be able to pause updating while comments are being edited.
The other alternative is to keep timer data tucked away in the tool folder, but linking the data to a particular song is very tricky. If you tie the data to the song’s filename, songs with the same name could muck up each other’s data. If you tie the data to the absolute path to the song’s filename, if the file gets moved, you’ve lost the timer data. You could assign an arbitrary ID to a song, and store that once in the comments for a 2-way link, but if you ever Save As Song… to make an alternative or a new version, that data will now be shared with the original song, and you wouldn’t be able to count on the timer data anymore. Since there’s no renoise.tool().app_saved_as_document_observable, there’s no way to know when this happens to be able to give the song a new ID. You could update the ID on every save, but then we run into the same problem with comments saving.
I know the API stuff makes sense to you because I’ve read your contributions throughout the forum.
With the data file kept alongside the XRNS, it’s messier visually, but you can be sure you don’t lose any time data. You can move/rename the files together, and it’s always up to date. I couldn’t see a more reliable solution. I could make those data files hidden (prepend filename with dot), but then it wouldn’t be as obvious to the casual user that they need to keep the files together.
Regarding putting a general .xml with timer data in the tools folder - isn’t timestamp+filename good enough to identify a song? (timestamp meaning the filesystem thing) I think I used that approach in some project. The only problem I can see is if the user changes the filename via some file explorer, but you already have a similar issue now, so I think that’s acceptable.
I am guessing you understand the method. If you go by modified timestamp, you’ll have to keep that updated in timelogger.xml. Saving as new file is also a little bit of a special case, but it just means that you will have to keep the file_path variable in memory to check if it’s been changed on song save.
v1.2: 2020-06-03
----
- NEW: Data files now tucked away in tool folder
- Shorter report filename -- FOO.tracked_time.report.txt`-> FOO.time-report.txt
- Conflict management / data file merging
- Export button to save a time report to the folder of your choice
- Fix for Windows paths
NB:FOR CURRENT USERS: The tool will migrate any data from existing data files from previous versions. Once you open your session, you should see a Conflict manager that will allow you to select the data you wish to migrate to the new scheme. You will only need to do this once. Once you save your song, check the new songname.time-report.txt to make sure everything went as planned. If it looks good, you’ll be able to delete the song’s old songname.tracked_time.xml and songname.tracked_time.report.txt, as they won’t serve any further purpose.
Also note that you can delete the time-report.txt files at any time without affecting the timekeeping data. The next time you save your song, a new one will be auto-generated.
The tool folder is not a good place to keep those files stored for a user. What will happen is, that when you release an update to your tool and a user installs it through Renoise the whole folder will be cleared and the new version is extracted, all the data is lost then. I’d put the folder somewhere in a folder dedicated to this type of stuff, eg. C:\Users\Username\AppData on Windows or somewhere along Documents & Settings.
And thanks for the heads up. Hopefully I was able to get out the fix before too many people used the tool. Anybody who used it between yesterday and today will probably get their data wiped.
There is a way to pause, though it’s not something you can turn on or off (though I might work activity detection into a future version).
Click the Settings button at the bottom of the Session Time window and make sure “Stop tracking when Renoise window loses focus” is checked. Then, whenever you decide to go outside or take a break, just switch to a different application on your computer (so Renoise loses focus), and the timer will effectively pause while you’re gone.
I painted myself into a nasty corner…
