[size=150]VFLib 1.1[/size] available on Github under the MIT License!
This is a collection of new modules that build on Juce. It has been officially released. I’m working on the Documentation and cleaning up the interfaces. If anyone wants to pick it up and poke around in it, I would appreciate the feedback.
[attachment=0]VFLibProject.png[/attachment]
great!
That looks very cool. Easy to integrate lock-free patterns - awesome. 8)
Bruce
PS - Did you have to commission a portrait to keep up with Jules? 
Ahhh well ermm…looks can be deceiving 
They come with tons of caveats. That’s why there’s a whole section of memory allocators, for avoiding the “ABA” problem (without resorting to 64 bit CAS).
LOL…I made Jules’ portrait and sent it to him after I made mine.
Cool stuff, Vinnie!
Once I’ve got the module-based library officially released, it’d be great to start adding 3rd-party modules like this to my master database, so that the introjucer’s download tool will help people discover and install them automatically.
Thanks although there are still some unresolved issues I need to address before it plays nice.
One item in particular, since I am doing a lot of stuff with objects having static storage duration (SharedSingleton for example) the juce::RunningThreadsList is very troublesome (I have threads that get destroyed after the juce::RunningThreadsList).
How would you feel about pull requests from https://github.com/vinniefalco/Juce ?
I’ve never had a github pull request, so don’t really know how they work, but am certainly happy to look at any suggestions you have!
Since Juce is not hosted on Github (it’d be great if it was!), and I’m fairly new to Git so I’m not 100% about this, but you would make a new branch in your local Juce repo, pull one of my remote branches (I would put my changes in a separate branch) into your new branch, then you could review the changes. If you were on github you could do this through the web page and make comments on specific files and lines. Otherwise you could just email me or use the Juce forum.
We’d go back and forth until you liked what you saw at which point you merge your local branch with my changes into your master branch.
On github you can open an “Issue”, for example:
https://github.com/vinniefalco/Juce/issues/1
This automatically starts a dialog where anyone can participate. Commits can be tied to issues with a simple comment in the commit line.
OT: I’ve been considering moving juce to github… Ideally it’d be best if I could somehow tell either github or sourceforge to mirror the other one, so that both remain up-to-date, but don’t know too much about how they work or whether that’s possible. Will investigate this at some point if I have more time.
You can do this right now, without changing your work flow at all:
sh$ git remote set-url --add --push origin git@github.com:rawmaterialsoftware/Juce.gitAssuming your GitHub user name was “rawmaterialsoftware”, and your existing sourceforge remote is named “origin”, after executing this line all future “git push” operations will send to both repositories.
Yeah, that’s a possibility. I’ll tinker with this kind of thing next time my brain is too tired to code.
I’ve posted the first iteration of this library, called “VFLib” - to Github:
VFLib:
Documentation:
http://vinniefalco.github.com/VFLib/annotated.html
Any feedback is appreciated. I’m still cleaning things up but it should compile for you.
I’m surprised to see it’s GPL’d. Are you planning to offer a closed source compatible license?
At some point in the near future I will address that. But for now, until I’m done cleaning everything up, documenting all the important classes I’m going to leave it as GPL. I also need to get some legal opinions on the inclusion and dependence on the external modules that VFLib uses before I can make any claims to offering non-GPL licenses. Additionally, I’d like to get some more information on the utility of these classes: Are they helpful? Do they have any commercial value? What is the eventual popularity? Depending on all of this I may likely offer a dual license smiliar to how JUCE is presented.
Of course, your thoughts on the usefulness of these objects is welcome! Constructive criticism also equally welcomed - it seems I don’t have quite the knack that Jules has for making things simple and clear.
Cool, that’s understandable. I’ll keep an eye on it and if I end up using something I’ll be sure to give some feedback. Keep up the good work Vinn!
Just saw this, very exciting, TheVinn!
Regarding the GPL license or not - I believe that given what you have uploaded there, you can use any license you like or none at all. You aren’t actually distributing any other libraries in your code as far as I can see - just talking about GPL’ed libraries does not GPL your code automatically.
[quote=“TomSwirly”]Just saw this, very exciting, TheVinn!
Regarding the GPL license or not - I believe that given what you have uploaded there, you can use any license you like or none at all. You aren’t actually distributing any other libraries in your code as far as I can see - just talking about GPL’ed libraries does not GPL your code automatically.[/quote]
Yeah actually I am re-distributing all the libraries I mention with the exception of JUCE. That’s one of the cool things about this library, it provides bZip2, sqlite, my modified Soci (tuned to work only with sqlite), FreeType, Lua, luabridge, and TagLib each as individual Juce-style modules.
Full sources for these external libraries are provided, some in amalgamated form (FreeType, sqlite, and TagLib). The project has no external dependencies with the exception of JUCE - everything compiles, and there’s no need to fiddle around with compilation settings (just like JUCE). You do need to add a few magic lines to your AppConfig.h but these are documented in AppConfigTemplate.
On my to-do list is to improve these external modules so that they can use system-provided or user-provided libraries if they exist. For example using the native sqlite on iOS, or the native FreeType on GNU/Linux systems, instead of the copies that come with VFLib.
You don’t have to use these external modules if you don’t want to, just don’t add those .c or .cpp files to your project. Some of my objects depend on them however. For example, FreeTypeFaces depends on FreeType but it gracefully compiles itself out via preprocessor directives if FreeType support is configured to off (VF_USE_FREETYPE in AppConfig.h)
None of the outside libraries that I’ve included are GPLed. And I don’t plan on adding any GPLed externals, since I might want to move to either a more permissive license or a dual license (provide a commercial license like Juce) in the future.
[b][color=red]Moved from http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=8923[/color][/b]
SEXY!!! This looks exactly like CallQueue and ThreadWithCallQueue !!
I’ve encapsulated SafeBool in an easy to use template, and also put together a very robust Error object that uses it.
Hmm…I just looked over all of your thread and callback code and it seems that we are addressing two completely different use cases (correct me if I’m wrong but you’re creating a new thread to handle each callback).
The purpose of the objects in my library is to implement concurrent synchronization without using CriticalSection objects to protect mutable data, not to perform lengthy asynchronous operations (although I do have a facility for that, see the discussion of the idle function in ThreadWithCallQueue).
To this end I provide the GuiCallQueue for synchronizing shared data in the message thread, a ManualCallQueue for synchronizing shared data in the audioDeviceIOCallback (or any other system or library-provided thread), and a ThreadWithCallQueue for synchronizing your own thread that performs tasks in the background (for example, a separate thread which scans through a library of audio files and extracts meta-data).
I don’t mean to sound boastful…it’s just that I’m well, I guess you can say “highly competitive” lol 
Tom thanks, upon consideration of your code and my targeted use-case I should document that functions placed into a CallQueue need to follow the same restrictions as code that executes in the audioDeviceIOCallback.
Although this should have been obvious to me after writing the example for ManualCallQueue
