Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Presets sharing should be a basic feature for all iOS based synth.
I first noticed presets sharing on Jamup. Ironically it is not that useful for a guitar amp simulator. Not because it is not necessary, but guitar sounds heavily depend on what guitar you are using.
But for synth it is another story. There is huge benefit for all the users, and of course devs. It doesn't matter what iOS devise or midi keyboard you are using, a preset sounds same. So everyone has an opportunity to get most of his arsenal, since not everyone is a presets guru, and not all the presets you made are useful for yourself but they could be for someone else.
I hesitated about this idea for synth like Animoog, because Animoog is making money out of presets. But think about it, if you like some presets made by other people and these presets need an expansion pack, you have to buy it. Actually that is why I finally bought all the expansion bundle in Jamup.
If a synth doesn't sell presets, like Sunrizer, presets sharing does no harm. On the contrary, it makes a synth more useful, so more people would buy it.
So I think all the synth devs should consider add presets sharing feature in future.
Comments
I like the idea of each app having an option to upload user presets to icloud to share with the community for sure.
And have a ratings system like the App Store and an icloud preset browser where you just press the name of the preset in the browser and it plays the preset !
Totally agree. I've wanted to build a site that would facilitate that sharing for a while. The problem is developing an easy API + iOS SDK for all developers to use isn't trivial. Let alone getting them to use it. Ask the audiobus fellas!
There are a couple of patch sharing sites around now but they all require you to export to a PC and upload. End users generally have to do the same, often resorting to ifunbox.
If there is an iOS developer reading this who is interested in working on the SDK half, I'm interested in building the web/API half. Another part of the problem is that in order for it to gain traction it a) had to be easy and useful enough for a dev to want to use it and b) probably free*. Free is hard to keep alive!
* though perhaps it could be managed via a single 'presets' app and that app could be a paid app - like audiobus.
I've been wanting to do this for a long time - actually that's always been my end-goal aspiration for Rhism Nation as a platform. Not sure if I have the time (actually I most definitely don't!) but I've already done a ton of background thinking / structuring / work around this anyway for guitarism, so would definitely like to at least be in the conversations if something like this is happening.
The technical pieces are non-trivial, but the hardest part of all this is getting the preset browser UX right. So let's say there are 10,000 presets available for Animoog. How should that browser work so that people can browse casually or search for something specific or discover something via serendipity? Ratings mechanism are well and good (if users opt to use them) but a lot of this is subjective stuff...
Initially you would have the patch type search eg:Bass, Lead etc...then creator search eg:ChrisG..then Genre eg:Electro..
I think total Number of dowloads is one element to consider filtering the most popular presets, and then also filtering to new presets...
Keywords like the AppStore search maybe eg: Sub, Fat, Space etc...also a look for similar presets function...
I also like the idea of presets that have been used in popular tracks so if I wanted the bass from a certain track I could search it.
@DaveMagoo Filtering by creator would be very effective, once someone knows which users' patches they like. Filtering by "used in track X" would be very effective if that's where you're starting from (you heard a track and want to get its patches) but too time consuming if you're starting from a more conceptual place.
Sorting by date is often used, but somewhat meaningless unless you are constantly checking the list and keeping up to date on every single patch. Sorting by # downloads or average rating is good as a starting point, but becomes stale quickly since those numbers don't change much over time.
Which brings us to search by genre/category/keywords, probably the best general option. Unsurprisingly, this also would probably balloon the development cost of this stuff, and would burden patch creators with putting in all this extra metadata about each patch they submit to the patchcloud.
@syrupcore Your thoughts on all this?
I always categorise my synth patches by keywords, bass, lead, pad, chord, fx, etc., in the synth app when I create them. It's in the preset already, so it's no extra work at the client end, you just have to cater for it in the online search engine.
Ahem.
There you go folks - @Sebastian's "Ahem" CONFIRMS without the shadow of a doubt that AB2 will include in-app preset sharing for all AB compatible apps out of the box
Or maybe he just ate a bit too fast...
Or his space key stopped working and he's wearing a dress with a hem on it...
That's the best justification imaginable for having a photo upload feature on this forum...
Ahem.
Just sign up for our newsletter and wait: http://audiob.us/two
I like the idea of online community preset sharing, but not at the expense of local preset storage. There needs to be both. I always worry that a developer may get the idea that all presets for an app need to be stored in the cloud. That is a bad idea.
Having presets stored locally, but retrievable (including new community shared presets) from the cloud is OK.
zMORS is doing it where the emphasis is on the cloud, and local storage is only used for presets not sync'ed AFAIK. I don't like this, so I thought this thread would be a good time to voice my opinion. All downloaded presets should always be available, whether there is an internet connection or not.
....just giving my opinion on the subject.... Now, back to our regularly-scheduled thread conversation. ;-)
@Rhism said:
LOL!
@Audiojunkie to clarify you're mainly saying you want access to your presets when you're offline, right?
I ask because the next guitarism update will have cloud sync of presets (for syncing across devices and/or if you delete + reinstall the app) and just want to make sure I'm not forgetting any important user needs. It will definitely still give you offline access to all your presets, but it does store all presets in the cloud too. It's like how Dropbox works more or less.
I think an advanced search functionality allowing you to search according to:
App / User / Genre / Category / Keyword
singularly or in any combination.
Some random thoughts to soon be even more pointless when the AB team does it all:
I'd say sorting by date would be pretty important but it would be better if the system simply knew the last one you saw and showed you new ones.
Title search ala @paulb would be essential.
Definitely local storage. My god. Though, perhaps the bigger picture here is cloud syncing. If we could all sync all of our app's presets in the cloud and mark them public, then searching/discovering would be possible. Find one, add it to your 'collection', go to your app and tap 'sync'. Got it.
Tagging would be essential. I imagine something like sunrizer here with a set of predefined tags that could be toggled (one or more). Plus free text perhaps.
Other people should be able to tag presets they didn't create. Owner can remove or they're somehow noted as not the owner's tag.
see all by app|user|date|tag|...
Automatic app registry would very helpful. I don't want to see presets for apps I don't have (though discoverability shouldn't be ignored).
Preset commenting
Preset rating or favorites.
Soundcloud oauth log in to upload/comment. Who needs yet another username/password? Plus, it'd be cool to click someone's soundcloud link. Plus, presets could more easily be associated with a demo or finished song. Or perhaps presets/comments/ratings by your soundcloud friends are called out/higher ranked.
Browse/search presets either on the web site, in a separate 'presets' app or from within any app that had the SDK. When browsing from within an app it would only show you presets for that app. The search/filtering UI might look exactly like the tagging UI when saving where those toggles filter the results (again, much like Sunrizer)
Most of that stuff is pretty easy, I think (not the global cloud sync bit). The harder stuff:
turnkey preset file system for devs to drop in to their app. Sounds easy in a sentence! this would standardize the way presets are stored and shared with the preset site/app. Pretty much the hardest part because...
Dealing with banks of presets and individual presets. Having an easy way for devs to incorporate a system that utilized both.
What about presets that involve samples? Or multiple samples?
Unless every developer adopts the same preset file type, there has be a completely separate meta data registry/localDB that points to an app's internal presets to store things like tags, creator, date...
What about binary presets?
Only presets created by the user should be shareable. Legal stuff aside, if we all sync our iMini presets there will be 1000 copies of the same preset on the site.
Awesome UI. I reckon a mashup of Yonac's and Arturia's stuff is almost there.
Paying for all this development.
PLUS the other 400 questions/problems you can't think of until you actually start building something like this. I'd love to hear the behind the scenes on whatever @sebastian and team are cooking up.
Cool stuff for v2.
:
The SDK could offer to also upload audio samples so that browsers could preview it first. Low C, Middle C, High C, CM chord. The code in the SDK would tell the app to 'silently' play each and record them to a file of fixed length then upload it with the patch. Playback is like using a graphic sprite (0:00 = Low C, 0:03 = Mid C, 0:06 = ... ). Something short enough to make upload painless but long enough to let most sounds ring a bit. Fixed length to reduce headaches.
Forking presets. I download a preset @audiojunkie made, tweak it and upload it as my own. A maintained history would be rad.
Versioning in general.
Server side comparison to find dupes. Ugh @ binary formats.
Bank builder. Add presets you like to a bank on the website (ala add to cart), download or share the whole bank.
Paid downloads
I'd want the turnkey preset/filesystem SDK thingy to eventually (help) solve the almost complete absence of midi program/bank change capability in iOS apps.
shit, that was longer than I thought! Sorry for the brain vomit!
@Rhism said:
Yes, correct. :-)
@Rhism said:
This sounds great! :-) Some synths require access to the cloud in order to access presets. I'm just saying that the presets should always be available to the user, and not be dependent on wifi access. :-)
@syrupcore Check out how it's being done by Big Tick in the VST world. It should give some good ideas for iOS developers:
http://www.bigtickaudio.com/zen/about-zen
It seems to do well. :-)
I guess I am in the minority. When I get a new synth I check out a handful of presets and then ignore the rest or sometimes delete them.
@MrNezumi You probably are skilled enough to make your own. ;-) I am making progress in the art of synthesis, but there are still a ton of presets and patches that are fantastic and blow my mind! I'm still a patch kiddie at heart. :-)
@syrupcore Still processing all of that but I really like the "date-based but start you where you last left off" thinking (like the Twitter app on iOS).
The SDK could wrap up app-specific presets into its own wrapper which adds the metadata elements (date, creator, tags etc). Each app could thus still have its own internal preset format, no need to try unifying that across apps (pretty much impossible). A compare could still be done to identify duplicates (v2).
The SDK could do all the work to sync presets to the cloud for each user, and then offer them up for sharing to the community. Managing permissions / publish state is tricky. If the user has to manually select which presets to make public (to the community) that's a lot of work for the user and for the app to expose the UI - no app would do this. But if all presets are public by default that'd create a lot of clutter and I sense that people wouldn't want that... (right?)
A couple of stupid questions since I know next to nothing about synths:
The tags / keywords / categories part is the hardest for me to grok here. Perhaps a screenshot of Sunrizer's keywords screen that you referred to?
Banks of presets vs individual: is it fair to say that a preset can either be on its own or in a bank, not both? And not in more than one bank?
Typically how large samples are we talking about wrt presets that include audio samples?
@Rhism said:
Without unifying it, would it mean that the SDK would have to 'understand' every dev's preset system? How else could the wrapper... wrap? I may be trapped in my way of thinking here. Part of the appeal of something like this to me is consistency across apps. Make the best possible preset system in the world and make it so good that dev's want to use it. Users get consistency, devs get an awesome preset system for their app for which they don't have to recreate the wheel.
In your mind, would the sharing/browsing SDK be a separate interface from the app's preset system? Where the dev would make objects out of its presets and pass them to the SDK's interface? (I'm a FT nerd but very little Objective-C so...)
@Rhism said:
I'd say it would default to off. Global toggle for on/off. Again, only user created presets would be published (publicly or privately) so I don't think noise would be a problem.
I'll upload a screen but imagine a series of buttons with labels like "Keys", "Dark", "Bright"... They work like checkboxes in that you can select more than one.
Correct. If it lives in more than one bank, even if it's the same preset, it would have to be treated as a second preset. Just cause.
Totally depends. In Nave? Generally short. In Thumbjam? Longer. In Nanostudio or Beatmaker? Could be 16 bar loops. In TJ, NS, BM, BS16i... they can be sets of samples that make up a drum kit or a multi-sampled violin.
@syrupcore Right I wasn't counting a TJ sampled instrument as a "preset" - those are full-blown instruments
I think this project would have to draw the line somewhere between a Nave preset and a TJ instrument. Simplest would be to disallow audio samples above a certain size. A bit more inclusive would be to allow larger samples if they're uploaded to a server somewhere.
The tagging thing sounds like the loop browser in GB on OSX. Fair comparison?
Wrt preset wrapping for metadata: It's all going to be structured groupings of number, string, date, array and dictionary (and probably would need to allow a binary type, base64-encoded). Obj-C offers foundational classes for all these, and they all map directly to their JSON equivalents (dictionary is basically a JSON object). An app preset would be a dictionary containing a bunch of numbers, strings, dates, arrays and dictionaries. The SDK doesn't need to understand any of this - it just creates its own outer dictionary, sets the app-specific preset as a key-value on that outer dictionary and then sets its own metadata properties (creator, date, version etc) on the outer dict.
As for unifying the preset format for all apps - never gonna happen. It's too much work for the app dev to do this, which will kill adoption. The reason AB adoption is so great is because it hitchhikes on the frameworks apps are already using, doesn't make them rewrite their audio engine. Same goes for presets (or anything really). Maybe a couple years down the road a migration effort could be conceived if it does really well, but to get off the ground it needs to be compatible with what these apps are already doing.
Wrt the sharing / browsing SDK being same or different - that needs some thought. I can see an SDK being pretty easy for an app to integrate if it's just about the app handing over its presets to sync up, and being handed back new ones that were synced down, and the app owns its own local preset browser. But there needs to be an in-app cloud preset browser UX in order to have a decent "audition" experience, which significantly increases an app's dev cost of integrating this SDK. If the UX is owned by the SDK that'd make it easier but it'd create a very disjoint UX for the user (local preset browser looks totally different from cloud preset browser). Thoughts?