Maybe extract the song to a temp folder and do a diff of some kind. 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. 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. One issue: With git you can check the current repo status to see what files have changed. I’ve been adding/fixing things as I use it and run into interesting situations. Since I tend not ot do any Renoise work on OSX I don’t know what OS quirks there might be. 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). 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. 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. Every time you added a new track, it created a new branch. Every time you rendered, it could automatically create a new tag. 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. It would also save drive space and help in the rare occasions where a song gets corrupted (not necessarily by Renoise). 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. 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. Since XRNS files are binary, merging is just not possible. And since a tag is just a 40 byte large reference to a given commit, I’d save a lot of space as well. 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. With Git, this space consuming and limiting system can be replaced with tags. Solskogenfor a song I just released this Saturday on Solskogen. 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. 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. My songs usually reach milestones of different sorts. 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. With full revision and “undo” history of every change I’ve ever made on any idea since the song was first created. One branch per idea that I can switch between any time I want. With Git, this mess can be replaced with branching. 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. I think my Git workflow will fit great with my musical creative workflow in that they share a lot of common properties.Įxploring different ideas and directions is hard to do if you want to preserve the idea without destroying another idea or the original song. Execute `git pull origin master` to pull the remote branch so that they are in sync.Ħ.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. To attach your remote repo with the name 'origin' `git remote add origin `ĥ. ` then `git commit -m 'initial commit comment'`)Ĥ. Locally, add and commit what you want in your initial repo (for everything, `git add. Locally, at the root directory of your source, `git init`ģ. Create the remote repository, and get the URL such as or Ģ. If your local GIT repo is already set up, skips steps 2 and 3ġ. If you've got local source code you want to add to a new remote new git repository without 'cloning' the remote first, do the following (I often do this - you create your remote empty repository in bitbucket/github, then push up your source) It appears as though the back ticks ` are causing the code inside the back ticks to be executed instead of treated as a code block in markdown. I have some markdown that isn't being parsed correctly.
0 Comments
Leave a Reply. |