Repo for server?

[dustMason]

I love the idea of integrating this with a server for uploading/downloading packs. It looks like localhost:5000 is hardcoded at the moment. Is the repo for the server on github as well? I'm just getting into my OP-1 and would love to contribute to this project, I think it's a great idea.

[mcginty]

Hey @dustMason, so sorry for the late reply!

I had only done the most rudimentary work on the server, so haven't open sourced it. HOWEVER, I'm still super interested in the idea of a collective "pack" repo, and if you have some time to try implementing it I'd love to help. I just don't know if I have the time right now to take it on by myself :).

[webratz]

I also started building a tools that generates packs (a bit more than opie does), will upload the code in the next few days.
I think the most important thing is to define a package format and have some tools that check for compatibility.
The actual upload could also be just to AWS S3 for example

[mcginty]

Yep, I was planning the same thing. The current pack format is only made for local storage, so a standardized format for sharing is a must definitely.

[mcginty]

Excited to see your code!

[webratz]

most interesting part is the OP1Pack function.
https://github.com/webratz/ohhpee1/blob/master/op1device.py#L47

Adding something like zip afterwards should be easy

[dustMason]

Excellent. Have you looked into the metadata that the OP-1 currently adds to its AIFF files? Creating our own pack format might be re-inventing the wheel here. It might make more sense to simply read (and cache?) the existing metadata on OP-1 .aif files. See https://github.com/sowbug/op-1-tools#notes

Presumably we could add some extra metadata of our own if needed. That way the "packs" are simply the aif files themselves, eliminating the need for an extra step on the user side.

I might be misunderstanding the goal of the pack concept though, so feel free to clarify.

[webratz]

In the script there is also a function named OP1Aiff that reads the json metadata from the aiff file, but they are only partially interpreted.There are many attempts of documentation for these, but I'm not yet sure if they are really useful without the graphical representation of the OP1.

A "pack" for me is a set of files, that go either to the drum or synth folder, on contains either sound (samples) or just the metadata for a synth engine. (for example: https://www.operator-1.com/index.php?p=/discussion/3168/new-cuckoo-op-1-subtle-patch-pack-c-mix )

[dustMason]

I see, looks like I was misunderstanding the feature.

A pack should be allowed to contain a combination of synth, drum and sampler patches, right? I believe Cuckoo's pack does. As far as I know the OP1 stores synth engine metadata in aiff files, just like samples. Those include a sound "preview" as the actual sound data, which could help make this theoretical repo site really nice. It also specifies, of course, what type of patch it is (drum, synth, sample).

Considering that, I think the OP1 aiff is already the right format for all the patch data. All we need is a lightweight collection around these that holds info about the author.

What do you think?

[mcginty]

Yes, exactly! I see a pack as basically a folder within the synth or drum folders (or both, just like what cuckoo does).

My imagination for the site was almost exactly what you describe, a way to preview the sounds, possibly including allowing the uploader to also put up a longer demo song of the pack used in practice as well.

OP-1 aiff is definitely the right format for patch data, I agree. I think any transcoding back and forth will lead to failure and excess complication.

Here's an example of how I might imagine a "pack", simplistically, as a tarball:

manifest.json
synth/katebush/babooshka.aif
synth/katebush/msfc.aif
drum/katebush/babooshka.aif

and in manifest.json, something like

{
  "display_name": "Kate Bush",
  "group_name": "katebush",
  "author": "mcginty <mcginty@katebushfancluborwhatever.com>",
  "license": "CC0"
}

The website, when a pack is uploaded, can extract the tarball and verify the contents before finally indexing it. I'm sure there are some other fields in the manifest that I'm not thinking about off the top of my head, but yeah.

[webratz]

Yeah i agree. For the pack part my code pretty much does the first part already.
I also differentiate between userpacks (pressing long one a key from 1-8) and provides packs

The JSON is pretty much enough of data for a start i guess.
Thinking about data structures and relationships it might make sense to add this metadata also to the actuall aiff files in another part.
I would have to test if the OP1 still works with those files then

[mcginty]

Yeah, I wouldn't be surprised if the OP-1 didn't have robust support for different AIF data structures it wasn't expecting. I've crashed my OP-1 a number of times playing around with it hahah.

[dustMason]

👍

I'm starting to wonder if this "pack" format needs to live outside of this website idea at all... If it were possible to add our own metadata to the AIF then I think attaching author and license fields might be all that's needed for a good experience.

What if the website allowed users to browse around and create their own collections (packs) of patches by organizing them (somewhat like soundcloud allows you to make playlists)? If the author/license data were attached to each patch then it would make sense to let people compile their own novel groups of these. They can then download the AIFs and do as they please – using tools like opie, etc as usual.

When downloading packs from the site it can make a zip file with subfolders for the three types on the fly. For completeness it could also generate a txt file with author / license info for the patches within, but as described above that same data should already live inside the AIFs themselves.

Instead of asking users to do the step of making a pack locally before uploading it to the site, we can just let them upload a pile of AIFs and write some metadata to each one automatically. They can then group them into a "pack" on the site and share that as they like. Other users can grab specific patches from that pack to use in their own packs, and we can make sure that author and license info follows each patch around in the UI.

Of course this hinges on whether or not we can get away with adding our own JSON metadata to the AIF files. I will do some testing in the next few days.

Another thought is that Teenage Engineering may be open to including these proposed author and license fields into the official metadata spec, since it seems they would have general appeal.

[webratz]

metadata

Just did several tries with the mutagen library, to first simply read the existing metadata, and then writing it back unchanged to aiff.
The json format is subtle different from what you would expect, but could be easily generated with something like data = "op-1%s" % json.dumps(self.op1data, sort_keys=True, separators=(',', ':'))

Altough I had no luck in getting the actual write done with mutagen. So i can't say if the op-1 would be reading that files.

Regarding adding own metadata: There are several other chunk types defined in the aiff spec that could probably be used. See http://www.muratnkonar.com/aiff/
Also ID3 Tags would be possible, but sadly also had no luck in getting them working with mutagen.

general design

I guess most user (of the op-1) won't find it very easy to install python and use a command line tool.
Instead my idea would be to build a small go application that only does

• detecting moutpoint
• mounting
• read and write files from the op-1
• upload to the server
• launch a small and simple webserver, as interface to the user
  All of this should be working probably at least for OSX and Windows.

On the server side a small python app could take the files in, analyze and store them.

[dustMason]

Awesome! Thanks for that info on AIFF spec. From The Application Specific Chunk section of that document:

Any number of these chunks may exist in a one FORM AIFF.

That leads me to believe we should be able to safely add an extra bit of JSON data as discussed above. I will experiment as well.

I agree that users should not be expected to use a CLI tool. Go sounds like a good choice for your application. However, will it be useful? I feel that copying files to the OP-1 in disk mode is already quite convenient and users are already familiar with it. Uploading the files to the website could be helpful but if the website features a nice UI for that it may also not be needed.

I don't mean to dissuade you from building such a tool. Just sharing thoughts.

I plan to take some time to write up an initial version of this website we've been talking about over the next few days.

[webratz]

Well, there are many small restrictions with uploading to the op-1 (eg max 40 patches) but indeed. For a first step this might not be needed.
I'm not sure what isn't working in my code to write to the files. May be an issue with mutagen :(