AppletJUCE is a public Github repository containing an assortment of simple applications and plugins to demonstrate JUCE, certain algorithms, or just a programming talent in general! Anyone can clone the repository and build the provided applications. The amalgamated version of JUCE is included, so you don’t need to perform any extra steps.
Everyone is encouraged to fork the repository and contribute their own sample programs, demonstration applications, or audio plugins! Just clone your fork locally, add a new directory, and put your code in there. Use the provided JUCEAmalgam sources so that your project will build without external dependencies. The sample HelloWorld application comes with an IntroJucer project file as an example.
Great idea, I know a lot of people have been asking for something like this, it could definitely be coupled with the Wiki for some serious tutorials. Do you keep the amalgamations at the tip? It would be good if you could monitor the repository for changes (RSS feed?) and then run some scripts to regenerate the amalgamation and push the changes.
The amalgamation is always brought in as a squashed set of commits. But you can always tell whats in it from the COMMITLOG. I use this technique for all my amalgamations. And you can even create the amalgamation yourself, including the updating of COMMITLOG (the script is part of the repo) by using the template:
The Visual Studio project for the templates is set up to automatically amalgamate, compile the source and amalgamated files (for error checking) and regenerate the COMMITLOG.
Cool stuff, you do have to run these update scripts yourself though (not really a big issue if you use JUCE daily) as I see the amalgamation isn’t bang up to date. I was thinking you could automate the process, what happens if you go on holiday for a week or two?! Perhaps have a small program that runs on your computer or a web server and checks every hour or two for updates to the repository.
Personally I just use local copies of the modules folder for stability when developing client code, updating it periodically when a change I need is brought out or I do some major tweaking. Just seems safer fo me to have control over this. But for students this is a good idea as it will definitely save on account space.
I’m waiting for the next officially tagged release of JUCE (which is soon apparently). When that happens, I will update the amalgamation to the release code, give it a matching tag, and then open a new branch called develop. From that point on, “master” in the amalgamation will only contain tagged releases from the official JUCE repo, while the tip branch will have the latest tip, updated as often as possible.
If I move this to a Github Organization are you volunteering to maintain the amalgamation from time to time? I need to know now if anyone wants push access, since that’s only possible with an Organization.
I like the idea.
Just checked out the git depository.
What should be added is a readme file, that explains, what each application does.
Right now I am not quite sure, what e.g. the “SwingBeats” example is.
Probably it is about beats in “Swing/Jazz”-Style. But it could also be beats that are rendered in a swinging buffer…
Each Applet is completely managed by the contributor. So if you go into SwingBeats, it has its own README.md - try it on Github, you should see the file.
Of course, this project is in its infancy so things are evolving.
Now, if you want to prepare a branch that includes the dRowAudio sources (separately licensed) along with your demo program that uses it, I would be happy to integrate it
