Renoise + Git

I might be crazy to suggest something like this and I might also be alone in wanting it, but being a programmer using Git every day for more and more tasks, I’m thinking about starting to use it on my Renoise songs as well. I think my Git workflow will fit great with my musical creative workflow in that they share a lot of common properties.

Branching

Exploring different ideas and directions is hard to do if you want to preserve the idea without destroying another idea or the original song. Preserving all directions a song can take can lead to a horrible mess of obscurely named XRNS files on disk with dates interpolated to give some idea of which idea is newer and to separate between several versions of the same idea.

With Git, this mess can be replaced with branching. One branch per idea that I can switch between any time I want. With full revision and “undo” history of every change I’ve ever made on any idea since the song was first created. Since branches can have verbose descriptions(and all Git commits are date-stamped by default), it’s easy to describe what idea you’re exploring so it’s easy to find back to old ideas.

Tags

My songs usually reach milestones of different sorts. Up until now, I’ve catalogued these by first creating a folder for each XRNS file I’m working on and then subfolders for each milestone I reach. I usually copy the XRNS file along with WAV renders of it into the subfolder and name the folder after the date of the milestone and some description of what it is. An example would be 2015-07-11.Solskogenfor a song I just released this Saturday on Solskogen.

With Git, this space consuming and limiting system can be replaced with tags. Since tags can have verbose descriptions (and all Git commits are date-stamped by default), it’s easy to find back to old versions of the song. And since a tag is just a 40 byte large reference to a given commit, I’d save a lot of space as well.

Merging

Now here’s the problematic part. Since XRNS files are binary, merging is just not possible. So I wonder; could it be an option when saving a Renoise song to save it to a folder instead of as a binary ZIP file? This would make merging two ideas possible, for instance. There’s probably a plethora of problems with this I haven’t thought of, but with some support in Renoise, I think this could become really powerful and time saving. It would also save drive space and help in the rare occasions where a song gets corrupted (not necessarily by Renoise).

Git support within Renoise

The ultimate dream would be if Renoise itself initialized a new Git repository with each new song and for every time you saved, it created a new commit with an optional message. Every time you rendered, it could automatically create a new tag. Every time you added a new track, it created a new branch. Okay, that last idea would probably be a bit over the top, but I hope you get the idea of how powerful this could be if it was properly integrated into Renoise.

I’m going to start using Git with Renoise on my next song anyway, but I would love to hear what other people think about this idea and whether merging is possible at all. What do you guys think?

Thread of interest:

https://forum.renoise.com/t/rnsgit-wrapper-script-to-help-manage-versioning-songs-with-git/43667

Thread of interest:

https://forum.renoise.com/t/rnsgit-wrapper-script-to-help-manage-versioning-songs-with-git/43667

Interesting indeed! Thanks!

Interesting indeed! Thanks!

Let me know if you have questions. I wrote rnsgit to scratch my own itch.

I use it on Windows and Ubuntu. It depends on being able to call 7z via the command line, so you need to have that installed (as well as git, of course). Since I tend not ot do any Renoise work on OSX I don’t know what OS quirks there might be.

I’ve been adding/fixing things as I use it and run into interesting situations.

One issue: With git you can check the current repo status to see what files have changed.

You can’t do that with rnsgit. It will always tell you nothing has changed since the changes occur in the xrns file, not the repo files, and the repos files are only updated when you tell rnsgit to commit.

I’ve been thinking of how to get around this, so that there can be a diff between the repo files and the current contents of the xrns file. Maybe extract the song to a temp folder and do a diff of some kind. Or just extract them to the repo folder.

It’s close to, but not quite the same as, working directly with git. A sort of goal is (was?) to make it a mostly invisible wrapper around git but that’s not quite how it is right now.

But it’s been a real help to me, allowing me to make and track assorted song changes while not dealing with binary copies of the song each time.

Being able to bounce back to another branch is quite handy.

I love the idea and that you executed on it. I have a feeling that solving it with Lua within Renoise instead of Ruby on the command line would make for a better experience, though. Then you could probably plug in to the save event in Renoise to have stuff extracted from the ZIP archive into the repository without issuing any separate commands to RnsGit. Using libraries in Lua instead of system installed executables would also help with distribution. Using Renoise’s plugin format would make installation simpler as well. I’m not well versed in Lua, but would love to help out. I’ll do a fork of the repository and see what I can do with it.

I love the idea and that you executed on it. I have a feeling that solving it with Lua within Renoise instead of Ruby on the command line would make for a better experience, though.

I listed some related Lua libs on a Reddit discussion about rnsgit: https://www.reddit.com/r/renoise/comments/36ybyb/rnsgit_commandline_tool_to_help_version_renoise/crjghap

I’ve forked and made a pull request. As I write, there’s still not much going on in the plugin, but it’s a start. With your existing code as a reference, I think that once we get zip and git to work in Lua, we should get feature parity with the Ruby version pretty fast.

neat!

I’ve forked and made a pull request. As I write, there’s still not much going on in the plugin, but it’s a start. With your existing code as a reference, I think that once we get zip and git to work in Lua, we should get feature parity with the Ruby version pretty fast.

I rejected the pull request. A Lua-based Renoise tool should be a separate project.

I agree that having a single repository maintaining two separate languages doesn’t make sense. I’m sorry, but I got the impression that you would like to move the project from Ruby and CLI to Lua and XRNX. I take it from your comment and rejection that I’ve misunderstood?

I’d love to see an xrnx version. I think it will take a bit of time to be stable, and I will continue to update the command-line tool because it works well for me.

Long-term I think Renoise should have song versioning built in.

Understood. And agreed! I’ll just reset my repository and start from scratch, then. I’d love to do some cooperation on the XRNX version, though. Is it too much hassle creating an RnsGit organization on GitHub for this purpose, you think? I can always just give you access to my repository if you would like to push to it as well.

I’m sure you’ve seen it, but http://git-lfs.github.com/, http://doc.gitlab.com/ee/workflow/git_annex.html. Not sure I’m going to use any of them but maybe, with http://gogs.io for free local issue tracking.

I’m sure you’ve seen it, but http://git-lfs.github.com/, http://doc.gitlab.com/ee/workflow/git_annex.html. Not sure I’m going to use any of them but maybe, with http://gogs.io for free local issue tracking.

I’ve not seen the LFS approach before. Interesting, but not something I wouldlikelyuse since I do not want to have to rely on an Internet connection or the availability of a remote site in order tomanipulatemy local repo.

Ah… I thought you could push-pull to a local repo with file://. Seems it’s planned(related)and possible toself-hostin the meantime… Too chancy for me but something to keep an eye onat least.