JUCE community ideas


#1

Hi guys,

I've been playing around with other frameworks for cross-platform mobile development recently and one that I really enjoy is Facebook's React Native framework. It's only a year old but it has progressed super, super quickly so that now you can easily do lots of common mobile tasks with it. I'm actually gonna use it for my next mobile project, with JUCE only for the DSP/audio. I know Facebook and ROLI are different beasts and Facebook clearly has a lot more resources to pile into the project...but one of the main reasons I think that it's progressed so fast is because Facebook has made it super easy to collaborate and share components and modules.

This is something JUCE is really lacking: a standardized central repo for sharing modules. I'm thinking something like the way Node's NPM works. When sharing a module you add a package.json file that describes the dependencies and necessary versions, so that when you snatch that module it automatically gets all the dependencies. 

Then the GUI on to all this would be in the Projucer. Modules are all tagged and categorized and thus can be easily searched. All modules are hosted on Github, and within Projucer you can see the git readme file, which might have screenshots and usage info. It could have download statistics. Look at https://atmospherejs.com/, a site for browsing Meteor packages. That site does it well I think.

Imagine it! Wouldn't it be awesome! Sharing LookAndFeels, Components, Whatevers without having to use the bloody forums. I think it could really boost the JUCE community and cut down on JUCE users constantly re-inventing the wheel.

What are your thoughts? Is something like this already in the pipe-line?

Rob


#2

We'd certainly like something like this! In fact, the juce_module_info file exists for that exact reason; you could be able to write your own. However I do agree that the lack of a central place to go look for such custom JUCE modules hinders its uptake.


#3

Ah yeah, I just took a look at the juce_module_info file...it's exactly what I was thinking. Perhaps a juce_module_info generator could be nice then, like with node.js. With npm when you install a new module you can set it to automatically update the package.json file. Users rarely have to edit the package.json file directly.


#4

Processing does the same, since version 2, so since a few years back.

I'm saying this because processing is open source, so you may get an idea or two on how to implement the same for the (pro)juicer.


#5

I've made a few posts on this subject over the past year or so! 

An easy to use system for both creating and finding Juce modules would be massively beneficial to the community, and I believe would attract more users to Juce. Part of the reason Node.js has become so popular is how easy it is to create, publish and find useful node modules.

Personally I would welcome a skeleton module generator as a command line tool like "npm init". Also some good documentation on creating modules. There are a few caveats and things to know when creating a Juce module, which I did not get from reading the existing docs. 

Also really interested in the idea of using React Native to build an app's main UI.


#6

Have you folks checked out biicode? It adds some npm / pods kind of dependency management for C++. Very cool indeed. I switched to CMake quite some time back to build JUCE core. It might be a good foundation for JUCE modules.


#7

Agree, a place to share modules would be very nice.


#8

Regarding the React Native UI, I'll report back in a few months to tell you how it went! The android side is a bit lacking atm though, especially with custom drawing which is essentially for any customised controls. But Facebook have said that's in their roadmap, and also I'm sure the community will smash it out soon. The module is called React ART. 


#9

Not wishing to derail this thread, but why not use JUCE for your custom graphics and React Native for the common UI elements? Thats the approach I've been taking with my app anyhow... (native iOS / Android, although I'm seriously looking at React Native now!)