My Jupiter-80 librarian tool for OS X is now of sufficient quality that I've uploaded it to GitHub. This means the project has an official home, with the source code available to everyone under a permissive MIT (open source) license.

While the GUI is OS X only, the source is written in Swift. Since Swift is now open source, and is already successfully ported to Linux, I plan on making a cross-platform command-line version available for exporting the SVD sound lists to a CSV format that can be imported in a spreadsheet or similar.

I've clicked on the link but am unfamiliar with GitHub and hence not clear what you have put there. Could you provide some download and install instructions? I downloaded the available zip file but only find a replica of the GitHup environment in there, with no executable. Do you require it to be compiled on the host computer?

On an operational level - could you tell us what the librarian does? Can it, for example, allow for the building of new files containing Registrations, Livesets and Tones on computer, for load onto the Jupiter? And, can one open two files on computer and delete, add, copy/transfer Registrations, Livesets and Tones within files and across files?

GitHub is for source code, not for executables, so my intent is to allow following the progress and making contributions (work, time, not money). But the source code can be compiled and run on any up-to-date Mac with Xcode (free on the Mac App Store).

I plan on distributing an executable in the near future and will provide a link then. I'm figuring out the specifics.

The current version of the tool is for reading SVD files only, not for modifying them. Modification is still in the planning stage (and might not happen). But I find the tool useful for managing sound sets and use it frequently.

Thanks for the update and thank for confirming it's a prototype / early stage development project - very helpful to know for non-techies (and for techies who may wish to contribute to it's development :-) ). At first I thought you meant there was a compiled binary OSX package available, so your clarification is genuinely appreciated at this stage.

Will truly look forward to downloading it as and when it's available as a package for install, with some useful and badly needed librarian functionality (and will be more than willing to make a financial contribution if you set that up when the time comes :-) ).

If you don't mind a suggestion or two - the following functionality would, in my opinion, hugely enhance the ease of use of the JP80:

1. Ability to store entire contents of JP80 into your librarian via USB; and for the librarian to be able to manage multiple backups / saved sound sets on an on-computer archive.

2. Ability to move Partials, Tones, Livesets and Registrations from one backup file set to another on computer - either individually or by multiple selection. For example - suppose you want to copy 10 new Livesets you made during a media-job on the Jupiter 80 into a personal on-computer permanent archive. That sort of flexible management would be huge.

(I realise of course the complexity in this because of the the Tone-liveset-Registration dependencies).

This is huge and very good news! I shelved my Mac G3 years ago and have been PC ever since so this is of no use right now, BUT! It gives us PC users hope at least :) I just got my Jupiter 80 and have lots to keep me busy right now, but at some point a PC editor/librarian will be very useful. I just tried the iPad editor app and it works ok but looks horrible on my iPad Pro 12.7, hope whoever made that app updates it for the big iPad.

I’m afraid the GUI is Mac only. But the underlying Swift code could also run on Linux, with some modifications. Since Linux can run under Windows, even officially on Windows 10, it could be used there as well. But the code is not adapted to run without the GUI in its current form.

Severe lack of time, as well as other priorities, have stalled this project for my part. But it would be an interesting experiment.

It only took a couple of evenings to port the file format reader from Lua, my first version, to Swift. So porting that to e.g. C# on a PC shouldn’t be much work either, for anyone with some time and programming skills.