Would it make sense for Roli to set up a Juce asset store ?
Similar to for example Unity , where users can make assets and sell them.
I know I would love to be able to buy some pre-made modules.
Just a thought . 
3 Likes
It’s a good idea, and one that we’ve already discussed internally. To do something like this we would need a lot of support from the web team at ROLI and I don’t want to commit to anything publicly!
maybe after they implement the search field in the online documentation for the API? it’s been what, over a year since that was requested? Api search
We just love it when people hijack unrelated threads to repeatedly bang on about their pet-hate or favourite request.
4 Likes
well, maybe if the API search for the online docs worked after the web team updated the whole website over a year ago, we wouldn’t be asking for it to be fixed… just sayin’… If you want to sell more licenses for JUCE, you should make the entry bar as low as possible so potential buyers aren’t scared away by a hard-to-use or hard-to-find-information-about API, meaning making it easy to search the online docs to begin with! So, you should probably make fixing that API search bug a higher priority than adding an Asset Store…
mea culpa
promise to try harder to comply in future
On thread, just wanted to say this would be really really awesome. I’d LOVE to release a lot of my stuff under dual GPL/commercial like JUCE, I just have no convenient way of doing it.
Odds and ends for power users like native system font detection, inheritance-based reimplementation of the knob/slider, raw packet I/O, hardware emulations under AudioProcessor interfaces, the list goes on.
The big blocker to releasing on my own is that these things are all heavily dependent on non-ISC JUCE bits, so sub-licensing them myself becomes a weird situation because of the licensor’s need for an additional JUCE license. Under the context of an official JUCE asset store, this becomes a lot more viable. Not to mention small developers like myself can then focus on what we care about, development, not licensing.
Also, obligatory “yeah but there are lots of serious longstanding issues like API search” (sorry Jules).
3 Likes
Yes , I can imagine this has been discussed , I think its a win, win, end even win.
Developers can sell modules they have lying about as well as even dedicating time and effort into smaller modules specifically for an asset store rather then full plugins, resulting in more focus on each and every aspect of said modules. An incentive to come up with solutions to problems we might not yet have if you will
Users obviously will benefit hugely , both buying modules for use and for learning.
New users will have an easier entry into Jucer , which is definitely a win.
Everyone saves time and everyone makes more money 
As I started using Unity for example , the asset store is what sold me on that, without a doubt.
I would buy stuff in such an asset store for sure.
Hi, I’m Ari and I’ve been programming for the past few years using various languages.
This idea makes so much sense. I mean, it has been quite the hassle to start out using JUCE as the next go-to solution for building Audio Plug-ins.
I imagine this might have a seriously positive impact, such as it has already proven to do, with Unity game engine. Many developers and artists have been selling their assets to other game-devs, and this includes everything from 3D model kits, animations, shaders, decals, textures or even character controllers. I think that being able to buy a set of sexy audio filters, a great looking scope ,with easily readable code to customise, some compressor with a nice sidechain function… and so on, would be a great way to proceed in the next step of the audio development revolution.
In many other technical industries, things are opening up. For instance, Microsoft are moving towards a more open and transparent ground, Tesla open the source to their second newest builds and there are many more examples that I can’t remember, at least right now. Even in finance, there are successful and open source crypto trading bots for anyone to set up and use. They feed on data sets and compare them between different coins, and then use current events to determine the future of value.
I love many things about JUCE, but there are several things about assets and the API documentation on how to proceed with developing that are rather baffling.
I get that it’s all the matter of handling basic data types and structures via methods, streaming data in and data out or even just generating audio via c++ where JUCE comes in as a cross-platform solution to produce components for any platform of the developer’s choice.
But then it brings me back to the beginning. I haven’t even been able to compile the FFT example that comes with the most recent JUCE package on this website because it might have had its structural integrity mixed with during an update or something.
What has been the single most difficult for me to understand in my first steps is knowing whether or not i’m doing everything wrong, and / or the 3rd party module repos are using deprecated environment etc. etc. Another thing is that in Xcode 7, the .cpp’s won’t compile at all unless I change all the include strings with a “./” prefix. otherwise the compiler does not know where to start browsing.
I could go on explaining all night but this should do.
There’s lots of free stuff it would be useful to have easy access too as well.
Adam and I looked at doing a JUCE package manager once. But time and other paid work got in the way. I’m toying with super-simple version that’ll be easy to get working. Maybe just a script around git for version 1!
3 Likes
Good Idea, Reaper has the reapack , very useful.
As someone that is starting out in Juce I find I am lacking stuff to test and play with , not sure where to find the free stuff that has passed a “quality test” or is known to work properly.
For now you could take stuff from the example projects. The JUCE Demo project contains properly vetted code.
1 Like
I like the idea in general. I’m just not sure, how it would work from a source and licensing perspective…
Would the provider sell precompiled static libs? Or would it be in source code? As soon as money is involved, there is the matter of resellers. And I’m not even talking of any kind of DRM, I hope that can be avoided by using proper T&Cs.
For me there are many questions to be solved before starting to implement such thing. It is not done by creating a platform and a bit of e-commerce…
Also learning from sourcecode, that was read by many is way more helpful than buying modules, that were only done by a single person. A community edited collection of modules on github would help for that, it’s just not a business model (could be a donation driven model?)
Just my 2 pennies
This is not really the case. For instance the “simple FFT” spectrogram does not compile out of the box in the most recent version of JUCE.
You should report the bug on github or on another thread here
This has been fixed on the develop branch already
+1 on the idea for a package manager and some simple web interface to preview modules.
I believe a bunch of free content will get uploaded and it will lower the threshold for entry in this field.
It doesn’t really matter if the average quality is lower than JUCE itself (which I guess is what bothers the JUCE team about this idea). Content (in the form of source-code) can be useful even if not completely passing the JUCE standard, and a handful of people just can’t produce as much content as a whole community.
Package manager can substantially grow the JUCE crowd and this benefits us all.
P.S. The C++ world, to my knowledge, doesn’t seem to have a great (popular) package manager. So the npm of the C++ world hasn’t been made yet. Hm…
2 Likes
I did have another look at this and remembered where I got bored.
Any decent solution needs to use libgit I think - and building libraries for WIndows is so tedious:)
However … on the upside … once libgit2 is sorted the rest looks pretty easy to get something useful going!
1 Like
I honestly think that C++ is not the the best fit for a package manager - hence why CocoaPods is written in Ruby. If I was to build a JUCE package manager now I’d probably do it in NodeJS or Ruby. Why go through the tedium of linking libgit, having to compile, making sure it works on different platforms etc when you could just alter the script and run your tests…?
There is already a Node binding for libgit2. https://github.com/nodegit/nodegit
(Unless of course you want it to run from within Projucer…)