search

op1hacks / opie

your OP-1's best bud
33 stars 3 forks source link

Repo for server? #1

Open dustMason opened 7 years ago

dustMason commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Excited to see your code!

webratz commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

👍

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 commented 7 years ago

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

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

dustMason commented 7 years ago

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 commented 7 years ago

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 :(

mcginty commented 7 years ago

Here's what I'm thinking as a compromise plan for the site to make the timescale realistic:

Thoughts?

mcginty commented 7 years ago

Also, as far as I've seen so far in this thread, while it would be rad to have parseable third party metadata in OP-1 patches, it's not a necessity for creating packs so we can add the AIF metadata spec in as v2 or something, especially if it's more likely to cause incompatibilities with different OP-1 firmwares, etc.

dustMason commented 7 years ago

I've spent some time over the last few days throwing together a site for sharing patches. It's still missing a few key features, and doesn't yet address the Pack concept we've been discussing in this thread but I wanted to show you where it's at and get your thoughts. All data on there is just test stuff for now. Still working on the front end as well.

http://op1.fun

(click the name of a patch to see it's detail page)

You can go ahead and sign up and upload a patch or two to see how it parses the audio and metadata.

I would like to add a feature that lets users create Packs. They will be able to upload/download them in some kind of open format as discussed here. Some kind of command line tool that used the website's JSON api to load packs on and off the OP1 would be awesome.

While working on this, I tested both adding a new APPL block to the aiff files and adding new keys to the existing op1 metadata with no success in either case. Using ID3 tags is still an option, and might be the best way to go since that has the advantage of being an open standard.

webratz commented 7 years ago

I think that this already looks pretty awesome. Especially I like that for drum you show the the different parts of the file. Adding a license field would be great so people know what they are allowed todo with it. As I was on vacation there is no progress from my side

dustMason commented 7 years ago

Thanks. I'm working on a preview of the synth settings for synthesis patches, too.

Good call on the license field, I will add that. How about a menu of standard choices? creative commons? I know us folks on GitHub are familiar with acronyms like GPL and MIT but not sure if that will just confuse most people.

webratz commented 7 years ago

Actually I'm not so sure which licenses people use for patches and things like that. But I guess different variations of Creative Common licenses and a default that is set on uploading are enough for a start.

mcginty commented 7 years ago

@dustMason THAT LOOKS AWESOME! Wow. This has a lot of potential.

I'm not an expert in this by any means, but I think Creative Commons licenses are designed more specifically for media, whereas GPL/MIT/Apache are tailored more for code and require a clear definition of what the "source code" for the media is to be effective.

dustMason commented 7 years ago

Thanks for input @webratz and @mcginty!

I pushed a couple updates today to https://op1.fun (including Creative Commons license selection for patches) and I feel like the site is nearly ready to be shared with the world.

I want to make an announcement on https://www.operator-1.com and https://www.reddit.com/r/OP1users/ soon. I could use your help making sure it gets noticed and used! I think it could be a real boon for the community. I will post another comment here when I make the announcement. Any other places I should share it?

I'd like to continue the discussion on the Pack format as well, since I plan to implement it on the site!

mcginty commented 7 years ago

@dustMason https://www.reddit.com/r/WeAreTheMusicMakers/ may also be a possible place to advertise, since in theory the patches could be used outside of the OP-1 with some finagling...

The site's really looking good. I'm super impressed with how quickly you got something up and running that's this feature complete.

Are you planning on open-sourcing the server? I'd be interested in contributing to it either way, alongside the implementation of the Pack standard.

mcginty commented 7 years ago

After I see where this idea is going, I'm imagining the opie tool instead as an electron app (since with Node we can interact with libusb and the filesystem) that is the companion to op1.fun.

It would serve as the easy interface to pull user presets and build them into packs and then upload them to op1.fun.

Users could register on op1.fun, then op1.fun could give them an API key to easily attach it to the native app which can talk to the OP-1 directly. Then the native app could also serve your website and handle the downloads of patches/packs and syncing it to the OP-1.

If we used your existing AIFF parsing and playback previews, it would make life so much easier for people when organizing the contents of their device.

dustMason commented 7 years ago

Thanks for the kind words. It has been a fun project so far.

Creating an API for op1.fun sounds great and is definitely something I want to do. Electron sounds like a good choice for getting the opie tool up and running quickly on several platforms with a native UI. For reasons that @webratz pointed out earlier it will also be useful outside of the context of op1.fun. A couple REST endpoints serving JSON and accepting a multipart form post for sample upload shouldn't take much time to add.

I love the idea of building out op1.fun to serve users of more devices. Right now the OP-1's limitations allowed me to make some design choices that made deploying the site easier – with a 12-second sample limit, the file sizes are fairly small so handling uploads is not a major challenge. The waveform/mp3 previews are limited to the first 1MB of the uploaded AIFF, which is no big deal for OP-1 patches. However I'm sure that would not work well for other devices that handle larger samples. It's a problem that can definitely be solved well, just with a bit more work.

I haven't made up my mind about open sourcing the entire app, but I'm more than happy to share the AIFF parsing and SVG waveform previews. The AIFF parsing is written in ruby using a wrapper for libsndfile so it might not be useful for you, but the SVG preview is just vanilla js written as a standalone component. I'll work on making a repo for that. Let me know if you do want the AIFF parsing code.

As for this Pack format, I suppose I will work on adding the pack creation feature to the site and let that guide me towards proposing an "official" format which I'll share in this thread.

dustMason commented 7 years ago

OP-1 patch previewer js now at https://github.com/dustMason/op1-patch-preview

webratz commented 7 years ago

regarding the packaging format: if i remember it correctly the metadata contains information wether it is a synth or a drum file. Therefore a basic pack format could be simply a zip file containing the aiff files. The local tool then can place them into the right folders according to their metadata.

Not sure what you use for authentication, if you are using AWS cognito the up and download also could work directly via S3 easily for the local application.

dustMason commented 7 years ago

@webratz yes the metadata has that info. a zip file would work fine as a portable pack format, so as I suspected early on it looks like we don't really need anything special.

I'm using S3 to store the AIFFs and MP3 previews and EC2 to serve the app. Cognito looks like a really cool service, haven't tried it yet. I'll look into that as an option for direct uploads, thanks.

webratz commented 7 years ago

As this thread is already hijacked anyway: At least chrome has a MIDI api (https://webaudio.github.io/web-midi-api/) that works nice with the OP-1. So a super fancy feature (for drum) would be a preview where you just hit the keys on the OP-1 and you would be able to listen to how it would soud in the browser (ignoring things like LFO and FX).

Sadly I don't have a clue about javascript and coming more from a backend world I can't help on that really. But I hope I will find a bit time to work on a simple packager.

dustMason commented 7 years ago

I love that idea!! How cool would it be to browse op1.fun with your OP-1 plugged in and tap out some preview beats?

mcginty commented 7 years ago

@dustMason while code can easily distinguish synth vs drum AIFFs, I think the benefit to having a more specific folder structure for packs that imitates the OP-1 mounted drive would be for people to easily know where to put patches if they don't use any tools and just want to drag and drop the things they want.

dustMason commented 7 years ago

@mcginty ah yes, that makes sense. sounds good.

@webratz I dug into the web midi api and got your idea working! Its so cool! You can plug in your OP-1, set it to MIDI mode, and tap out notes while looking a sample detail page on op1.fun! When it detects a connected OP-1, it shows an icon in the lower left of the page.

If you try it, give the page a few moments to load the sample before you can play notes. Also, it only works in Chrome.

The feature is still rough and missing a lot (ADSR, more UI feedback, more accurate sample points on audio preview) but I'm really excited about it already.

webratz commented 7 years ago

awesome, will check it on the weekend

dustMason commented 7 years ago

Alright, sorry if I'm spamming you guys. Almost ready to make an announcement about op1.fun :)

I've added a Pack feature to the site. It lets you create packs and fill them up with patches, then download them as a zip file with the correct file structure. If one of you wants to take a crack at implementing the op1.fun API for a desktop patch management tool (like opie) that would be amazing. We can start a new thread for that one ;)

I also imported a large batch of patches which were at one point shared on ohpeewon.com, a now-defunct community site. I've made sure to include proper attribution for these patches and have also added a page explaining their origin. When I announce the site I hope to reach the creators of these patches so that I can make sure they are shared with their consent and with the correct licenses. I really hope this is not perceived as shady.

webratz commented 7 years ago

i would be glad to build a local tool that then pushes the stuff to the OP-1 device. I guess opie could be extended to do it. Altough I currently have very limited spare time, so that might take a while. But I'm keen to have a look at the APIs and see whats possible

dustMason commented 7 years ago

@webratz Great! I've got the first version of the API deployed. Its documented at https://github.com/dustMason/api.op1.fun

Let's use issues on that repo to discuss implementation.

In other news, yesterday I made a post on operator-1.com about op1.fun and already almost 50 people have signed up! Some have started to upload patches and create packs.