# VFLib vs BEAST

**URL:** <https://forum.juce.com/t/vflib-vs-beast/11428>\
**Category:** Useful Tools and Components\
**Created:** [September 8, 2013, 2:46pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428 "2013-09-08T14:46:03Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![lalala](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/lalala/32/8577_2.png) [@lalala](https://forum.juce.com/u/lalala)\
**Post date:** [September 8, 2013, 2:46pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/1 "2013-09-08T14:46:03Z")

</div>

vinnie, do you still maintain VFLib, or should we move to beast ?

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [September 13, 2013, 11:21am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/2 "2013-09-13T11:21:00Z")

</div>

I would be very interested to know the answer as well. As it seems, we can not simply replace VFLib with Beast. Last time i checked not all the classes where included. I'm diving, head first, deep into this library. I would really appreciate if Mr. Vinnie Falco, the author could share a little bit of his plans please?

---

<div class="post-metadata">

**Author:** ![TheVinn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/thevinn/32/806_2.png) [@TheVinn](https://forum.juce.com/u/TheVinn)\
**Post date:** [September 13, 2013, 3:03pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/3 "2013-09-13T15:03:30Z")

</div>

VFLib and Beast are two completely different things. VFLib is oriented towards a JUCE application, with a GUI. Beast is designed for server applications and peer to peer software.

&nbsp;

I'm using Beast in Ripple (see my signature). Beast has a dependency on Boost, for the SSL support and the multi-protocol socket handshaking. And also, the HTTP Client. We dont want VFLib to have a dependency on Boost. They are two different libraries. In a few years when I revisit JUCE I will probably merge parts of the two libraries but for now they are completely separate and should be considered individually.

&nbsp;

Do note that VFLib is GPL, while Beast is ISC Licensed.

&nbsp;

---

<div class="post-metadata">

**Author:** ![lalala](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/lalala/32/8577_2.png) [@lalala](https://forum.juce.com/u/lalala)\
**Post date:** [September 13, 2013, 3:26pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/4 "2013-09-13T15:26:53Z")

</div>

thanks for your answer.

\>\>&nbsp;Do note that VFLib is GPL

? it is said as MIT here :&nbsp;https://github.com/vinniefalco/VFLib &nbsp;!

&nbsp;

At the moment VFLib won't compile & work with the latest juce from git.&nbsp;What you would recommend to VFLib users ? How do you plan to maintain VFLib ?

On the other thread about VFLib&nbsp;missing&nbsp;decReferenceCountWithoutDeleting&nbsp;you advise me to look at SharedPtr, SharedObject, and SharedSingleton. But those are part of Beast no?

that's why I'm a bit confused..

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [September 13, 2013, 3:39pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/5 "2013-09-13T15:39:39Z")

</div>

Thank you very much for answering. This is good to know and actually i'm very comfortable this way. I'm growing to like VFLib quite a lot!

I guess you mean VFLib is GPL when used with GPL-licenced JUCE, but MIT licenced when used with commercial JUCE license?

Maybe you want to mention in the documentation that VFLib requires VS 2010 or later, because of stdint.h and std:ref and other bind stuff not available prior to VS 2010,&nbsp; whereas JUCE builds on earlier versions of VS.

---

<div class="post-metadata">

**Author:** ![TheVinn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/thevinn/32/806_2.png) [@TheVinn](https://forum.juce.com/u/TheVinn)\
**Post date:** [September 13, 2013, 4:03pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/6 "2013-09-13T16:03:31Z")

</div>

What I am saying is that Beast has diverged from VFLib. I dont have any active projects that use VFLib so I am not really maintaining it.

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [September 13, 2013, 4:21pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/7 "2013-09-13T16:21:00Z")

</div>

Forget it...

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [November 19, 2013, 12:29pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/8 "2013-11-19T12:29:42Z")

</div>

Is anyone else using VFLib? Are you stuck with version 2.1.1 of Juce like i'm, because the decReferenceCountWithoutDeleting broke VFLib? or have you managed to hack VFLib to build with the current Juce?

---

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [November 21, 2013, 9:35am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/9 "2013-11-21T09:35:00Z")

</div>

I'm not using VFLib any more, but I did do a heinous hack to get it to compile so I could just use the FreeType stuff:

**modules\vf\_core\events\vf\_OncePerSecond.cpp**

```
old    new    
...    ...    @@ -33,7 +33,7 @@
33    33     class OncePerSecond::TimerSingleton
34    34       : public RefCountedSingleton <OncePerSecond::TimerSingleton>
35    35     {
36        -private:
    36    +public:
37    37       TimerSingleton ()
38    38         : RefCountedSingleton <OncePerSecond::TimerSingleton> (
39    39             SingletonLifetime::persistAfterCreation)
...    ...    @@ -49,6 +49,7 @@ private:
49    49         jassert (m_list.empty ());
50    50       }
51    51     
    52    +private:
52    53       void run ()
53    54       {
54    55         for(;;)
```

**modules\vf\_core\memory\vf\_RefCountedSingleton.h**

```
old    new    
...    ...    @@ -150,6 +150,11 @@ public:
150    150           destroySingleton ();
151    151       }
152    152     
    153    +  inline bool decReferenceCountWithoutDeleting() noexcept
    154    +  {
    155    +    return m_refs.release ();
    156    +  }
    157    +
153    158       // Caller must synchronize.
154    159       inline bool isBeingReferenced () const
155    160       {
```

There was also a fix for **modules\vf\_gui\mouse\vf\_MouseEnterGroup.h**

```
**​** old    new    
...    ...    @@ -150,7 +150,7 @@ private:
150    150           mouseWasDragged = !e.mouseWasClicked ();
151    151         }
152    152     
153        -    MouseInputSource* source;
    153    +    const MouseInputSource* source;
154    154         Point <int>       position;
155    155         ModifierKeys      modifiers;
156    156         Component*        eventComponent;
```

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [November 21, 2013, 11:41am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/10 "2013-11-21T11:41:00Z")

</div>

I had to also expose private destructors in two classes:

**modules/vf\_concurrent/memory/vf\_GlobalFifoFreeStore.h**

```
diff --git a/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h b/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h
index 1bb9bbc..3528180 100644
--- a/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h
+++ b/VFLib/modules/vf_concurrent/memory/vf_GlobalFifoFreeStore.h
@@ -67,6 +67,7 @@ private:
   {
   }
 
+public:
   ~GlobalFifoFreeStore ()
   {
   }
```

**modules/vf\_concurrent/memory/vf\_GlobalPagedFreeStore.h**

```
diff --git a/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h b/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h
index 45adf22..1ae6049 100644
--- a/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h
+++ b/VFLib/modules/vf_concurrent/memory/vf_GlobalPagedFreeStore.h
@@ -47,9 +47,9 @@ class GlobalPagedFreeStore
 {
 private:
   GlobalPagedFreeStore ();
- ~GlobalPagedFreeStore ();
 
 public:
+ ~GlobalPagedFreeStore ();
   inline size_t getPageBytes ()
   {
     return m_allocator.getPageBytes ();
```

At least it compiles now with Juce 3.0.0. Thank's a lot! [Edit: It compiles but at least the CallQueues are broken. Assertions go off when the memory management singletons under the hood are destroyed.]

I remember from some old posts that you were quite into VFLib. May I ask how and why you got rid of it?

---

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [November 21, 2013, 2:06pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/11 "2013-11-21T14:06:34Z")

</div>

I used Vinnie's FreeType amalgam first and changed to VFLib when he moved FT into that. I got very interested in his method for updating between threads, but never got round to implementing it as a simple timer arrangement was sufficient for me. When he&nbsp;mentioned he had found a problem with the implementation but didn't detail&nbsp;it - and then there were&nbsp;the compile issues, it made it clear he had&nbsp;moved on and I couldn't expect any support.. So I decided to cut loose for now, which is a shame because there is a lot of cool stuff in there.

I still use FreeTypeFaces, and I might grab some of the other graphic stuff. But I'm&nbsp;wary of the MessageThread stuff as I don't understand the implementation well enough to dig myself out of a hole!

---

<div class="post-metadata">

**Author:** ![onar3d](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/onar3d/32/4972_2.png) [@onar3d](https://forum.juce.com/u/onar3d)\
**Post date:** [November 21, 2013, 3:28pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/12 "2013-11-21T15:28:47Z")

</div>

Hi!

Only slightly off-topic: when you refer to "his method for updating between threads", it it the vf::ConcurrentState, vf::CallQueue etc classes that he made the SimpleDJ example for?

I just found your marathon thread&nbsp;http://www.juce.com/forum/topic/whats-best-practice-gui-change-notification, was it there he said that his implementation had a problem but didn't specify it? I think I should read that thread regardless!

I was just about to get into learning from the SimpleDJ example, but if there's a problem in the implementation now I get cold feet, since this is stuff I still only barely understand anyway :)

&nbsp;

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [November 21, 2013, 5:17pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/13 "2013-11-21T17:17:00Z")

</div>

I would recommend to forget all about VFLib for now. It has some really awesome stuff like the CallQueues! But the stuff is so complicated that i doubt anyone will ever maintain this library, unless Vinnie takes it up again, which at the moment he has clearly stated that he will not do.

I could compile VFLib after applying the above modifications, but the singletons in VFLib are broken. I'm back to Juce 2.1.1 and i'll rather loose VFLib at the first opportunity, than invest the time to teach myself the lib's sources from top to bottom in order to be able to fix these issues, being uncertain if that's even possible.

My adventure with VFLib was one of those Murphy moments. I got all exited about this library, spent about a week reimplementing the state management using CallQueues, and after another week or two, the library is broken and Vinnie throws in the towel. Quite frankly, i can't remember when was the last time i've felt so stupid. I'm literally banging my face with the keyboard .l isy öö oifg - auch! öoi shnhjklvfs - auch! :p

---

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [November 22, 2013, 2:43am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/14 "2013-11-22T02:43:00Z")

</div>

To onar3D,

Yes - those methods may or may not&nbsp;be OK. Vinnie has gone quiet&nbsp;here and we haven't got any confirmation. All we've got is this:&nbsp;http://www.juce.com/forum/topic/vflib-significant-defects-found

---

<div class="post-metadata">

**Author:** ![onar3d](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/onar3d/32/4972_2.png) [@onar3d](https://forum.juce.com/u/onar3d)\
**Post date:** [November 22, 2013, 10:07am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/15 "2013-11-22T10:07:49Z")

</div>

Thanks for the warning, I'll stay clear for now then!

Refactoring a program to make it multithreaded is hard enough, doing it with an unsupported library that uses things I've never heard of before (Functors...????) seems risky... :)

Too bad since it seemed to solve things in a neat way. Maybe Beast? But not right now...

---

<div class="post-metadata">

**Author:** ![P4tr3ck](https://avatars.discourse-cdn.com/v4/letter/p/e79b87/32.png) [@P4tr3ck](https://forum.juce.com/u/P4tr3ck)\
**Post date:** [November 27, 2013, 10:58am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/16 "2013-11-27T10:58:00Z")

</div>

Disclaimer: My app relies almost completely on VFLib for managing concurrent state. It works great for me. What Vinnie has accomplished with VFLib is amazing.

Having said that I agree that its best not to start new projects using VFLib until it becomes maintained again. Vinnies remarks about bugs got me worried as well. In any case, with much help of Vinnie I started bringing over the for me most important pieces of VFLib to Beast. For the multi-threaded concurrent thread management only the ListenerList is missing: [https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast\_vflib](https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast_vflib)

In the meantime, a proper quick fix to the compile problems of VFLib with the latest JUCE tip is to add template specializations of the ContainerDeletePolicy for the VFLibs singletons. Attached is a patch that adds these. Vinnie was very helpful creating these because my knowledge about template is small. As soon as I find time I’ll provide a pull request for [https://github.com/vinniefalco/VFLib/tree/develop](https://github.com/vinniefalco/VFLib/tree/develop)

PS: Jules, could you allow the file extension .patch for uploads? I had to rename the patch to .txt to upload it.

---

<div class="post-metadata">

**Author:** ![widdershins](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/widdershins/32/20_2.png) [@widdershins](https://forum.juce.com/u/widdershins)\
**Post date:** [December 10, 2013, 2:01pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/17 "2013-12-10T14:01:00Z")

</div>

I'm in the same boat. VFLib has been working fabulously for my concurrency needs, only problem being I'm stuck on JUCE 2.1.1.

It's a real shame that Vinne decided to discontinue developement - when I switched my app to use vf::concurrent instead of a timer approach it became much smoother and more responsive, which is important since it's a synthesiser. The problem of cross-thread communication is one of the few things that JUCE doesn't solve satisfactorily for me, and VFLib solved it beautifully.

I'd love to fork and maintain just the concurrency module from VFLib, but I don't believe I have the skill as a developer.

Anyway, many thanks for your patch, I'm going to apply that and see how I go with JUCE 3.0.

**EDIT** : Your patch works great! It's obviously a short term solution, but it's a big help for now, thank you.

---

<div class="post-metadata">

**Author:** ![P4tr3ck](https://avatars.discourse-cdn.com/v4/letter/p/e79b87/32.png) [@P4tr3ck](https://forum.juce.com/u/P4tr3ck)\
**Post date:** [December 15, 2013, 8:07am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/18 "2013-12-15T08:07:15Z")

</div>

I have started with much&nbsp;help from Vinnie to work on bringing the concurrency module to&nbsp;beast:&nbsp;https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast\_vflib

Before it is really usable the ListenerList must be implemented. As soon as time permits I'll give that a try. Its not a 100% drop in replacement but it will hopefully not take to much effort to switch over.

&nbsp;

---

<div class="post-metadata">

**Author:** ![mjokipii](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@mjokipii](https://forum.juce.com/u/mjokipii)\
**Post date:** [January 28, 2014, 8:16am UTC](https://forum.juce.com/t/vflib-vs-beast/11428/19 "2014-01-28T08:16:10Z")

</div>

I applied P4tr3ck's patch and made the transition to JUCE 3 very smoothly. After testing a while the call queues seem to be working fine. Updating to JUCE 3 has fixed a lot of host compatibility problems. I can't thank you enough P4tr3ck! Good luck with your effort to bring the call queues to Beast!

---

<div class="post-metadata">

**Author:** ![rdthompson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/rdthompson/32/5476_2.png) [@rdthompson](https://forum.juce.com/u/rdthompson)\
**Post date:** [July 22, 2019, 8:06pm UTC](https://forum.juce.com/t/vflib-vs-beast/11428/20 "2019-07-22T20:06:11Z")

</div>

> [@P4tr3ck](#):
>
> [https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast\_vflib](https://github.com/vinniefalco/rippled/tree/develop/src/beast/modules/beast_vflib)

Does anyone in this discussion have further updates? Some of the repos above are no longer available.

On that note, what is the best option for POSIX type thread concurrency in JUCE 5.4.3 ?

[Next page](https://forum.juce.com/t/vflib-vs-beast/11428.md?page=2)
