I collected up some code I’ve written / ported to juce over the years and put them into a module named Gin. Some I’ve posted before as individual files, but I thought it would be better to have them all in a juce module. All code ported to juce was originally BSD license or similar, credits are in the files. This adds a few useful classes such as:
BMPImageFormat - Load and Save Windows Bitmaps. 8, 24, 32 bit, uncompressed reading supported. Write 32 bit.
ColourPropertyComponent - Colour picker for PropertyComponent
Ellipse - Determine if point is on ellipse. Find point at angle on ellipse.
FilePropertyComponent - File chooser for PropertyComponent
FileSystemWathcer - Get notified when files in directory change
ImageEffects - Sepia, Vignette, Soften, Sharpen, Invert, Contrast, Hue, Saturation, etc. Works on ARGB formatted images only.
Integrator - Calculate integrals
LeastSquaresRegression - Fits a curve to data points
LinearRegression - Fits a line to data points
MapViewer - Displays a map. Shows map tiles noly, you will need to extend it to draw paths, markers, etc.
OpenStreetMaps - Fetch tiles from various OSM servers
SharedMemory - Share a memory block between processes
Spline - A smooth curve from a set of discrete points
Did the json to valueTree stuff get pulled? I recently had to write one of these and it felt pretty clunky by the end. I’d be interested to see how did it. Maybe this is even possible now with the latest versions of JUCE? I’m still rocking out 5.4.7!
@RolandMR -
Hi, I’m not sure if this is the appropriate place to post about it, but gin does not build against JUCE 7 - there are warnings and errors. I just tried the latest version from the git.
I was using the one downloaded back in April, and that gave a different set of errrors from the ones encountered with the one downloaded today.
I commented out a few things I wasn’t using to get it to work, so it’s not stopping me from moving forward with JUCE 7…
I’ve always had C++14 (default) set in my JUCE projects. So I changed it to C++17. Does not seem to have introduced any issues, and it fixes the gin problems. Thanks!
Just for the records because it seems to pertain to this discussion, JUCE has the Optional class as a replacement for std::optional until the requirement for JUCE is raised to C++17 (stated in their docs)
This isn’t really intended to be used by JUCE clients. Instead, it’s to be used internally in JUCE code, with an API close-enough to std::optional that the types can be swapped with fairly minor disruption at some point in the future, but without breaking any public APIs .
But then again, it has already been used in public APIs. C++17 is well supported by now, I don’t see any reason to hold back.
Sure, the intention of my post was to add information for someone that might end up here searching “std::optional” and “C++14” on the forum.
By no means I’m suggesting that you should use the class provided by JUCE if you decide that C++17 is the minimum requirement for your lib (which I personally think it’s quite reasonable)
etc., etc.? I’ll give it a whirl. I’m particulrly interesting in websocket class, but I see no example code. I wonder if anyone has a basic example they can share?
[edit] seems to work, thanks for this Unfortunately, the one project I want to use it on is still using JUCE6. I might be able to roll gin back to a compatible version…