JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, RTAS and AAX audio plug-ins.

alt text

JUCE is an open-source cross-platform C++ application framework used for rapidly developing high quality desktop and mobile applications, including VST, AU (and AUv3), RTAS and AAX audio plug-ins. JUCE can be easily integrated with existing projects or can be used as a project generation tool via the Projucer, which supports exporting projects for Xcode (macOS and iOS), Visual Studio, Android Studio, Code::Blocks, CLion and Linux Makefiles as well as containing a source code editor and live-coding engine which can be used for rapid prototyping.

Getting Started

The JUCE repository contains a master and develop branch. The develop branch contains the latest bugfixes and features and is periodically merged into the master branch in stable tagged releases (the latest release containing pre-built binaries can be also downloaded from the JUCE website).

JUCE projects can be managed with either the Projucer (JUCE's own project-configuration tool) or with CMake.

The Projucer

The repository doesn't contain a pre-built Projucer so you will need to build it for your platform - Xcode, Visual Studio and Linux Makefile projects are located in extras/Projucer/Builds (the minumum system requirements are listed in the System Requirements section below). The Projucer can then be used to create new JUCE projects, view tutorials and run examples. It is also possible to include the JUCE modules source code in an existing project directly, or build them into a static or dynamic library which can be linked into a project.

For further help getting started, please refer to the JUCE documentation and tutorials.

CMake

Version 3.15 or higher is required for plugin projects, and strongly recommended for other project types. To use CMake, you will need to install it, either from your system package manager or from the official download page. For comprehensive documentation on JUCE's CMake API, see the JUCE CMake documentation. For examples which may be useful as starting points for new CMake projects, see the CMake examples directory.

Building Examples

To use CMake to build the examples and extras bundled with JUCE, simply clone JUCE and then run the following commands, replacing "DemoRunner" with the name of the target you wish to build.

cd /path/to/JUCE
cmake . -B cmake-build -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build cmake-build --target DemoRunner

Minimum System Requirements

Building JUCE Projects

  • macOS/iOS: macOS 10.11 and Xcode 7.3.1
  • Windows: Windows 8.1 and Visual Studio 2015 64-bit
  • Linux: GCC 4.8 (for a full list of dependencies, see here).
  • Android: Android Studio on Windows, macOS or Linux

Deployment Targets

  • macOS: macOS 10.7
  • Windows: Windows Vista
  • Linux: Mainstream Linux distributions
  • iOS: iOS 9.0
  • Android: Jelly Bean (API 16)

Contributing

For bug reports and features requests, please visit the JUCE Forum - the JUCE developers are active there and will read every post and respond accordingly. When submitting a bug report, please ensure that it follows the issue template. We don't accept third party GitHub pull requests directly due to copyright restrictions but if you would like to contribute any changes please contact us.

License

The core JUCE modules (juce_audio_basics, juce_audio_devices, juce_blocks_basics, juce_core and juce_events) are permissively licensed under the terms of the ISC license. Other modules are covered by a GPL/Commercial license.

There are multiple commercial licensing tiers for JUCE, with different terms for each:

  • JUCE Personal (developers or startup businesses with revenue under 50K USD) - free
  • JUCE Indie (small businesses with revenue under 500K USD) - $40/month
  • JUCE Pro (no revenue limit) - $130/month
  • JUCE Educational (no revenue limit) - free for bona fide educational institutes

For full terms see LICENSE.md.

Comments
  • LV2 support

    LV2 support

    for a cross-platform environment, it would be great if juce could include LV2 as supported audio plugins.

    see https://forum.juce.com/t/juce-lv2-plugin-wrapper/14209 for a discussion on this.

  • Projucer Linux Makefile Linking error: undefined reference to symbol

    Projucer Linux Makefile Linking error: undefined reference to symbol

    Hi! I created a simple GUI project in Projucer in my Ubuntu 18.10 64 bits system.

    When trying to compile such project using make, I got

    Linking Juce_GUI_Test - App /usr/bin/ld: build/intermediate/Debug/include_juce_graphics_f817e147.o: undefined reference to symbol '[email protected]@PNG16_0' /usr/bin/ld: //usr/lib/x86_64-linux-gnu/libpng16.so.16: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make: *** [Makefile:96: build/Juce_GUI_Test] Error 1

    I had to add the following flags to the JUCE_LDFLAGS macro in the Makefile in order to make it work: -lpng16 -lz -ljpeg -lFLAC -logg -lvorbis -lvorbisenc -lvorbisfile

    The workaround is achieved specifically following these steps:

    1. Open the Makefile in any text editor you like.
    2. Go to line 44, the line JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell pkg-config --libs alsa freetype2 libcurl x11 xext xinerama webkit2gtk-4.0 gtk+-x11-3.0) -fvisibility=hidden -lGL -ldl -lpthread -lrt $(LDFLAGS) should appear.
    3. Add the flags before $(LDFLAGS) so now line 44 should be JUCE_LDFLAGS += $(TARGET_ARCH) -L$(JUCE_BINDIR) -L$(JUCE_LIBDIR) $(shell pkg-config --libs alsa freetype2 libcurl x11 xext xinerama webkit2gtk-4.0 gtk+-x11-3.0) -lGL -ldl -lpthread -lrt -lpng16 -lz -ljpeg -lFLAC -logg -lvorbis -lvorbisenc -lvorbisfile $(LDFLAGS).
    4. Now compilation does work after running make.

    I think that it has something to do with function StringArray getLinkerFlags (const BuildConfiguration& config) const of the jucer_ProjectExport_Make files of the repository.

    Hope it helps!

  • Plugin standalone version window doesn't change size

    Plugin standalone version window doesn't change size

    	setResizeLimits (150, 100, 600, 400);
    	getConstrainer ()->setFixedAspectRatio (1.5);
    	setSize (600, 400);
    

    When you click on the resizer control in the bottom right corner, the editor resizes, but the standalone window retains it's full size.

    Windows 10, 64-bit

  • API-doc search not available / many content like jucePlatformDefs is missing / isPositiveAndBelow not findable

    API-doc search not available / many content like jucePlatformDefs is missing / isPositiveAndBelow not findable

    The inheritance diagrams of the doxygen generated api-docs on the website don't work. Eventually due to javascript. The search field is no longer present.

    To be observed with

    • firefox on Mac OSX 10.10,
    • Chrome on Mac OSX
    • Safari on Mac OSX
  • Visual Studio 2015 : '_InterlockedDecrement': ambiguous call to overloaded function

    Visual Studio 2015 : '_InterlockedDecrement': ambiguous call to overloaded function

    Hi there,

    I have been playing with the faust2juce script of the Faust language which generate a ready to compile JUCE project. Here is the generated cpp file I'm using: https://gist.github.com/xaviergodart/66e3b7ac9483735bb8ec1bba82ec923b

    I'm targeting VST 64bits. It works perfectly when using the Linux Makefile exporter. However, when using the Visual Studio 2015 exporter on Windows 7 64bits, I get the following error:

    Error	C2668	'_InterlockedDecrement': ambiguous call to overloaded function (compiling source file ..\..\FaustPluginProcessor.cpp)	gainCtl	c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory\juce_Atomic.h	260	
    

    It seems that there is some sort of collision between Windows headers. I'm fairly new to cpp development, especially on Windows, and I can't figure out if the problem is coming from the faust generated file, JUCE, or my side.

    I tried both 4.3.1 and the develop branch.

    Here is the build log:

    1>c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(260): error C2668: '_InterlockedDecrement': ambiguous call to overloaded function (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\intrin.h(209): note: could be 'long _InterlockedDecrement(volatile long *)' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\winbase.h(8875): note: or       'unsigned __int64 `anonymous-namespace'::_InterlockedDecrement(volatile unsigned __int64 *)' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\winbase.h(8864): note: or       'unsigned long `anonymous-namespace'::_InterlockedDecrement(volatile unsigned long *)' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\winbase.h(8855): note: or       'unsigned int `anonymous-namespace'::_InterlockedDecrement(volatile unsigned int *)' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h(2706): note: or       '`anonymous-namespace'::LONG `anonymous-namespace'::_InterlockedDecrement(volatile `anonymous-namespace'::LONG *)' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(260): note: while trying to match the argument list '(volatile long *)' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(259): note: while compiling class template member function 'int juce::WindowsInterlockedHelpersBase<Type,4>::dec(volatile Type *) noexcept'
    1>          with
    1>          [
    1>              Type=int
    1>          ] (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(381): note: see reference to function template instantiation 'int juce::WindowsInterlockedHelpersBase<Type,4>::dec(volatile Type *) noexcept' being compiled
    1>          with
    1>          [
    1>              Type=int
    1>          ] (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(305): note: see reference to class template instantiation 'juce::WindowsInterlockedHelpersBase<Type,4>' being compiled
    1>          with
    1>          [
    1>              Type=int
    1>          ] (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(322): note: see reference to class template instantiation 'juce::WindowsInterlockedHelpers<Type>' being compiled
    1>          with
    1>          [
    1>              Type=int
    1>          ] (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_Atomic.h(317): note: while compiling class template member function 'int juce::Atomic<int>::get(void) noexcept const' (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_ReferenceCountedObject.h(103): note: see reference to function template instantiation 'int juce::Atomic<int>::get(void) noexcept const' being compiled (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_LeakedObjectDetector.h(101): note: see reference to class template instantiation 'juce::Atomic<int>' being compiled (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_LeakedObjectDetector.h(88): note: see reference to class template instantiation 'juce::LeakedObjectDetector<OwnerClass>::LeakCounter' being compiled (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  c:\users\xavier\documents\juce\juce-grapefruit-windows\juce\modules\juce_core\memory/juce_LeakedObjectDetector.h(114): note: see reference to class template instantiation 'juce::LeakedObjectDetector<OwnerClass>' being compiled (compiling source file ..\..\FaustPluginProcessor.cpp)
    1>  juce_osc.cpp
    ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
    
    

    Thank you very much for your help.

  • contribution guidelines

    contribution guidelines

    @ed95 @julianstorer

    is there a way to submit patches without having them rewritten by someone else with no mention of the original author (see #548 and e206bbe)?

    if copyright ownership is an issue, isn't it what a Contributor License Agreement is about? besides the fact that for such one-liner fixes, signing a CLA should not even be required.

    README.md mentions contacting the authors, so here i go. I do have a few of such simple fixes for linux down the pipe.

    cheers, Paul

  • [Bug]: JUCE 6.1.5 fails to compile with 20220209 release of llvm-mingw

    [Bug]: JUCE 6.1.5 fails to compile with 20220209 release of llvm-mingw

    Detailed steps on how to reproduce the bug

    Containerised repro using JUCE audio plugin example:

    git clone https://github.com/Birch-san/juce-repro.git
    cd juce-repro
    docker build .
    

    juce_win32_ComInterfaces.h attempts to define UIA_ constants. These clash with the macros defined in MinGW's uiautomationclient.h.

    When we compile with llvm-mingw 20220209, we get the following error:

    In file included from /linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/juce_gui_basics.cpp:309:
    /linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/native/accessibility/juce_win32_ComInterfaces.h:123:12: error: expected unqualified-id
    const long UIA_InvokePatternId = 10000;
               ^
    /opt/llvm-mingw/x86_64-w64-mingw32/include/uiautomationclient.h:34:30: note: expanded from macro 'UIA_InvokePatternId'
    #define UIA_InvokePatternId (10000)
    

    JUCE tries to declare a constant:

    const long UIA_InvokePatternId = 10000;
    

    But the token UIA_InvokePatternId already exists as a MinGW macro, and expands to (10000), making the statement:

    const long (10000) = 10000;
    

    This compiles fine in llvm-mingw 20211002. Perhaps the MinGW uiautomationclient.h header was different back then?

    I am currently working around the problem by telling MinGW not to define any UIA_ macros, and manually supplying the macros upon which JUCE depends.

    What is the expected behaviour?

    Successful compilation. JUCE should not declare any constants whose names would clash with macros provided by MinGW.

    Operating systems

    Linux

    What versions of the operating systems?

    Ubuntu 22.04 cross-compiling for Windows 7 x86_64

    Architectures

    x86_64

    Stacktrace

    Full stack here:
    https://gist.github.com/Birch-san/0364f650a70505ce8c4b1859eab19b0e
    
    In file included from /linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/juce_gui_basics.cpp:309:
    /linux_native/include/JUCE-6.1.5/modules/juce_gui_basics/native/accessibility/juce_win32_ComInterfaces.h:123:12: error: expected unqualified-id
    const long UIA_InvokePatternId = 10000;
               ^
    /opt/llvm-mingw/x86_64-w64-mingw32/include/uiautomationclient.h:34:30: note: expanded from macro 'UIA_InvokePatternId'
    #define UIA_InvokePatternId (10000)
    

    Plug-in formats (if applicable)

    No response

    Plug-in host applications (DAWs) (if applicable)

    No response

    Testing on the develop branch

    I have not tested against the develop branch

    Code of Conduct

    • [X] I agree to follow the Code of Conduct
  • PopupMenu broken on embedded, bridged plugins

    PopupMenu broken on embedded, bridged plugins

    A number of DAWs these days feature bridge processes to enable loading 32-bit plugins into a 64-bit host, or vice-versa. The plugin is loaded into the bridge process, with which the host communicates to process/generate audio. A number of DAWs also embed VST GUIs into their main window, usually as an MDI child. However, when a VST from a bridge process is embedded as a child window of the DAW, JUCE's PopupMenus can break, where the popup menu does not appear, or only appears very briefly.

    This was originally observed with the Helm VST loaded into LMMS, but I have reproduced it with Helm in Hermann Seib's VSTHost too. (I have heard others have had this problem with other JUCE-based VSTs such as Dexed, but I have not been able to reproduce this particular case.)

    To reproduce: download Helm and VSTHost (both 32- and 64-bit). Load an instance of Helm with a matching architecture to that of VSTHost, and observe that opening the "PATTERN" menu under "ARP" and the "TYPE" menu under "DISTORTION" behaves exactly as expected. Now load an instance with a non-matching architecture. VSTHost will load this in a bridge process, and attempts to open the same menus will not succeed, the menus either not appearing, or only appearing very briefly.

    This behaviour occurs for both 32- and 64-bit VST2 builds under Windows. It may well exist in other versions but I don't own a host with the capabilities to test this. I have built Helm with the latest version of JUCE's develop branch (f80df37 at time of writing; a few simple patches to Helm were required) and the issue still persists.

    The issue seems to stem from the Win32 version of Process::isForegroundProcess https://github.com/WeAreROLI/JUCE/blob/f80df37183382a3194023129f3c2badf23176b74/modules/juce_gui_basics/native/juce_win32_Windowing.cpp#L3699-L3710 which returns false in the case that the plugin is bridged and embedded, since the foreground window belongs to the DAW, which is in a different process to the plugin. Then MenuWindow::doesAnyJuceCompHaveFocus returns false, causing MouseSourceState::checkButtonState to immediately dismiss the menu.

    FL Studio, while it can have embedded, bridged plugins, has a workaround; they don't set the WS_CHILD style on their VST wrapper window when embedding. Thus, while the plugin is embedded as a child of FL, Windows recognises it as a separate top-level window for the purposes of GetForegroundWindow and so the above code works as intended. This, however, is not standard/correct usage of the Win32 API as far as I am aware - child windows should always have WS_CHILD set - and so ideally should not be required.

  • CoreAudioReader::readSamples() bug

    CoreAudioReader::readSamples() bug

    There is a bug in CoreAudioReader::readSamples(). The bug is present in develop branch at least of revision 16dd266

    The bug stems from the fact that the interface to ExtAudioFileRead specifies that for the non-const pointer argument *ioNumberFrames, "Fewer frames may be read than were requested".

    However CoreAudioReader::readSamples() treats ExtAudioFileRead() as if it either returns exactly the number of frames requested or fails. As a consequence readSamples() works incorrectly when the number of frames read by ExtAudioFileRead() is lower than requested.

    This can be seen in the code excerpt below:

    auto numThisTime = jmin (8192, numSamples);
    auto numBytes = sizeof (float) * (size_t) numThisTime;
    
    audioDataBlock.ensureSize (numBytes * numChannels, false);
    auto* data = static_cast<float*> (audioDataBlock.getData());
    
    for (int j = (int) numChannels; --j >= 0;)
    {
        bufferList->mBuffers[j].mNumberChannels = 1;
        bufferList->mBuffers[j].mDataByteSize = (UInt32) numBytes;
        bufferList->mBuffers[j].mData = data;
        data += numThisTime;
    }
    
    auto numFramesToRead = (UInt32) numThisTime;
    auto status = ExtAudioFileRead (audioFileRef, &numFramesToRead, bufferList);
    
    /****************************************************************************************************************/
    //     BUG
    //     numFramesToRead may now be less than numThisTime
    /****************************************************************************************************************/
    
    if (status != noErr)
        return false;
    
    for (int i = numDestChannels; --i >= 0;)
    {
        auto* dest = destSamples[(i < (int) numChannels ? channelMap[i] : i)];
    
        if (dest != nullptr)
        {
            if (i < (int) numChannels)
    
               /****************************************************************************************************************/
               //     BUG!!! 
               //     numBytes is numThisTime * sizeof(float) but should be numFramesToRead * sizeof(float) 
               /****************************************************************************************************************/
    
                memcpy (dest + startOffsetInDestBuffer, bufferList->mBuffers[i].mData, numBytes); 
            else
                zeromem (dest + startOffsetInDestBuffer, numBytes);
        }
    }
    

    If needed I can provide a simple JUCE project with an audio file that produces erroneous audio output as a result of the above.

  • VST3 in Ardour on Linux - resizing fix

    VST3 in Ardour on Linux - resizing fix

    Hi JUCE team, I believe this PR fixes resize loop issues I have been experiencing trying to build VST3 plugins on Linux to run in Ardour.

    Initially I took a look at the Ardour VST3 host code to see if there was an issue there. That lead to this PR, but upon further digging I found that JUCE's call to updateBounds on the ComponentPeer seems to be interfering with Ardour's own window resizing. It seems like JUCE is trying to modify the plugin window size directly during the onSize callback, while the VST3 spec indicates that the host should handle window resizing.

    Prior to this change, any resizable JUCE plugin causes huge performance issues in Ardour (Linux) when the GUI is opened and immediately enters a resize loop. It's not usable at all. After the change is applied, the plugin UI behaves fine and everything seems stable.

  • pre-compiled Projucer binaries fail to run on Debian/amd64

    pre-compiled Projucer binaries fail to run on Debian/amd64

    downloading JUCE for Linux on my Debian/buster amd64 system, I cannot run the pre-compiled binary Projucer:

    $ wget https://d30pueezughrda.cloudfront.net/juce/juce-5.3.2-linux.zip
    $ unzip juce-5.3.2-linux.zip
    $ JUCE/Projucer
    JUCE/Projucer: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by JUCE/Projucer)
    $
    

    btw, DemoRunner starts nicely.

    Self-compiling Projucer produces a working binary (but is impractical under certain circumstances, like continuous-integration where you don't want to spend time compiling your build-system)

    libcurl3 is being faded out of Debian/Ubuntu; while (on older distros) there is a libcurl3 package which can be used to satisfy the dependencies to run Projucer. however, there are no more -dev packages (all have switched to libcurl4 - conflicting with libcurl3), making it impossible to compile any JUCE-plugins at the same time as having a running Projucer.

    I don't know the exact state on recent Ubuntu releases (being a Debian guy), but I expect problems there as well (so probably a lot of Linux devs are bitten by this)

  • [Bug]: Seeking certain FLAC streams can result in empty sample buffers during reads

    [Bug]: Seeking certain FLAC streams can result in empty sample buffers during reads

    Detailed steps on how to reproduce the bug

    See https://github.com/spotify/pedalboard/issues/170 for a test audio file and reproduction steps (albeit ones that go through the pedalboard Python bindings).

    The bug appears to be due to this code from 2009 in FlacAudioFormat, which attempts to work around an unspecified bug very likely no longer present since upgrading FLAC to v1.3.4 (as of JUCE v7.03): https://github.com/juce-framework/JUCE/blob/bbd6ccbc863edec3150e1e024e4fa3f636802596/modules/juce_audio_formats/codecs/juce_FlacAudioFormat.cpp#L265-L273

    This code assumes that every FLAC frame decoded will be at least 511 samples in length, ensuring that a call to FLAC__stream_decoder_seek_absolute operation will fill enough of the buffer such that requestedStart is covered. However, that's not a guarantee; for some files, FLAC__stream_decoder_seek_absolute can return as few as 128 samples (or less), which causes FlacReader to silently fill the remainder of the buffer for the current read call with zeroes. (This often occurs mid-stream, when the file is nowhere near complete.)

    While I don't have a pull request to offer, I can confirm that I've tried changing this locally (by removing || jmax (bufferedRange.getEnd(), bufferedRange.getStart() + (int64) 511) < requestedStart and & ~511 from the above-linked code) and can confirm that I get no crashes with any test FLAC files, even seeking as granularly as one sample at a time.

    What is the expected behaviour?

    The juce::FlacReader class should return the correct decoded audio for a given FLAC file, regardless of the current seek position of the file.

    Operating systems

    macOS

    What versions of the operating systems?

    macOS v12.6.1

    Architectures

    x86_64

    Stacktrace

    No response

    Plug-in formats (if applicable)

    No response

    Plug-in host applications (DAWs) (if applicable)

    No response

    Testing on the develop branch

    The bug is present on the develop branch

    Code of Conduct

    • [X] I agree to follow the Code of Conduct
  • [Bug]: Heap corruption due to virtual function call from destructor of AccessibilityHandler

    [Bug]: Heap corruption due to virtual function call from destructor of AccessibilityHandler

    Detailed steps on how to reproduce the bug

    Inherit from ListBoxModel and override virtual function getNumRows During destruction of SectionedListBox virtual function getNumRows will be called for partially destroyed object of class SectionedListBox from inside destructor of AccessibilityHandler.

    Moreover, depending on implementation of SectionedListBox::getNumRows potentially this can lead to pure-virtual function call [error.](Screenshot 2022-12-01 at 22 00 25)

    The implementation of AccessibilityHandler violates C.82 Rule of C++ Core Guidline: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c82-dont-call-virtual-functions-in-constructors-and-destructors

    class SectionedListBox: public juce::Component,
        private juce::ListBoxModel
    {
    public:;
        // juce::ListBoxModel interfaces
        int getNumRows() override;
    

    workaround:

    disable AccessibilityHandler for SectionedListBox

    SectionedListBox::SectionedListBox()
    {
        setAccessible(false);
    }
    

    stacktrace

    Screenshot 2022-12-01 at 22 57 06

    What is the expected behaviour?

    AccessibilityHandler should be properly destroyed.

    Operating systems

    Windows, macOS

    What versions of the operating systems?

    OSX 12.6.1

    Architectures

    x86_64

    Stacktrace

    No response

    Plug-in formats (if applicable)

    No response

    Plug-in host applications (DAWs) (if applicable)

    No response

    Testing on the develop branch

    The bug is present on the develop branch

    Code of Conduct

    • [X] I agree to follow the Code of Conduct
  • [Bug]: MacOS 13 returns UnknownOS in SystemStats::getOperatingSystemType()

    [Bug]: MacOS 13 returns UnknownOS in SystemStats::getOperatingSystemType()

    Detailed steps on how to reproduce the bug

    Apple has changed the way it's using OS numbering on MacOS, and has started to use the Major number for each years new release, starting with MacOS 11.

    Juce has added support for the versions 11 and 12 manually, but lacks support for future version. The function simply returns UnknownOS in juce_mac_SystemStats.cpp at line 119.

    This causes unexpected behauvour, since on the fly operating system checking should be done with:

    getOperatingSystemType() & SystemStats::MacOSX

    I've checked the Develop branche, and 13 is now added, but:

    I think this function should be re-designed so that it will work for future versions as well. At this moment, Juce is behind on the current version, and Beta's of future version will also be invalid.

    Adding the new version each year is not a sustainable solution.

    A quick fix for me now is to use ENV variables en check with ifdefs.

    What is the expected behaviour?

    function should return the correct os version in newer version, despite the literal implementation

    Operating systems

    macOS

    What versions of the operating systems?

    13

    Architectures

    x86_64, ARM

    Stacktrace

    No response

    Plug-in formats (if applicable)

    No response

    Plug-in host applications (DAWs) (if applicable)

    No response

    Testing on the develop branch

    The bug is present on the develop branch

    Code of Conduct

    • [X] I agree to follow the Code of Conduct
  • Fix vst3 data races

    Fix vst3 data races

    Fixes data races detected by Thread Sanitizer on both midiBuffer and bufferMapper members of JuceVST3Component Witnessed on macOS 12.6, in Studio One 6, running a debug build of ARAPluginDemo with Thread Sanitizer enabled Occurs when two different threads call process() one after the other on the same JuceVST3Component instance, because their evaluations of the above data members aren't synchronized (i.e. https://eel.is/c++draft/intro.races)

    diff is very small (see without whitespace)

  • [Bug]: use after free in Component::MouseListenerList::sendMouseEvent

    [Bug]: use after free in Component::MouseListenerList::sendMouseEvent

    Detailed steps on how to reproduce the bug

    when building with -fsanitize=address, i get this in develop, despite the recent fix for #1145

    this happen every time a dragged component gets deleted on mouse up.

    this patch fixes it:

    index 3ed50b82b..9fc0b3a7f 100644
    --- a/modules/juce_gui_basics/components/juce_Component.cpp
    +++ b/modules/juce_gui_basics/components/juce_Component.cpp
    @@ -137,6 +137,9 @@ public:
                     if (checker.shouldBailOut())
                         return;
     
    +                if (checker.nearestNonNullParent() != parent)^M
    +                    return;^M
    +^M
                     i = jmin (i, list->listeners.size());
                 }
             }
    
    ==58065==ERROR: AddressSanitizer: heap-use-after-free on address 0x00011c4a4dac at pc 0x000102695ab8 bp 0x00016f640340 sp 0x00016f640338
    READ of size 4 at 0x00011c4a4dac thread T0
        #0 0x102695ab4 in juce::ArrayBase<juce::MouseListener*, juce::DummyCriticalSection>::size() const juce_ArrayBase.h:201
        #1 0x10297a0dc in juce::Array<juce::MouseListener*, juce::DummyCriticalSection, 0>::size() const juce_Array.h:218
        #2 0x1023a7ed4 in void juce::Component::MouseListenerList::sendMouseEvent<void (juce::MouseListener::*)(juce::MouseEvent const&)>(juce::HierarchyChecker&, void (juce::MouseListener::*&&)(juce::MouseEv
    ent const&)) juce_Component.cpp:140  
        #3 0x1023aaeb4 in juce::Component::internalMouseUp(juce::MouseInputSource, juce::PointerState const&, juce::Time, juce::ModifierKeys) juce_Component.cpp:2578
        #4 0x1026a7438 in juce::MouseInputSourceInternal::sendMouseUp(juce::Component&, juce::PointerState const&, juce::Time, juce::ModifierKeys) juce_MouseInputSource.cpp:140
        #5 0x10269de10 in juce::MouseInputSourceInternal::setButtons(juce::PointerState const&, juce::Time, juce::ModifierKeys) juce_MouseInputSource.cpp:185
        #6 0x1023c2d78 in juce::MouseInputSourceInternal::handleEvent(juce::ComponentPeer&, juce::Point<float>, juce::Time, juce::ModifierKeys, float, float, juce::PenDetails) juce_MouseInputSource.cpp:312
        #7 0x1023c2200 in juce::MouseInputSource::handleEvent(juce::ComponentPeer&, juce::Point<float>, long long, juce::ModifierKeys, float, float, juce::PenDetails const&) juce_MouseInputSource.cpp:609
        #8 0x10262a56c in juce::ComponentPeer::handleMouseEvent(juce::MouseInputSource::InputSourceType, juce::Point<float>, juce::ModifierKeys, float, float, long long, juce::PenDetails, int) juce_ComponentP
    eer.cpp:90
        #9 0x102897034 in juce::NSViewComponentPeer::sendMouseEvent(NSEvent*) juce_mac_NSViewComponentPeer.mm:787
        #10 0x10289b1c8 in juce::NSViewComponentPeer::redirectMouseUp(NSEvent*) juce_mac_NSViewComponentPeer.mm:669
        #11 0x102894500 in void juce::JuceNSViewClass::callOnOwner<void (juce::NSViewComponentPeer::*)(NSEvent*), NSEvent*&>(objc_object*, void (juce::NSViewComponentPeer::*&&)(NSEvent*), NSEvent*&) juce_mac_
    NSViewComponentPeer.mm:2240
        #12 0x102868278 in juce::JuceNSViewClass::asyncMouseUp(objc_object*, objc_selector*, NSEvent*) juce_mac_NSViewComponentPeer.mm:2245
        #13 0x102868424 in juce::JuceNSViewClass::mouseUp(objc_object*, objc_selector*, NSEvent*) juce_mac_NSViewComponentPeer.mm:2269
        #14 0x1b834f170 in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:]+0x9fc (AppKit:arm64e+0x1b2170)
        #15 0x1b834e508 in -[NSWindow(NSEventRouting) sendEvent:]+0x158 (AppKit:arm64e+0x1b1508)
        #16 0x1b834d4b0 in -[NSApplication(NSEvent) sendEvent:]+0xad8 (AppKit:arm64e+0x1b04b0)
        #17 0x1b86070f0 in -[NSApplication _handleEvent:]+0x48 (AppKit:arm64e+0x46a0f0)
        #18 0x1b81cf004 in -[NSApplication run]+0x278 (AppKit:arm64e+0x32004)
        #19 0x1021da2a0 in juce::MessageManager::runDispatchLoop() juce_mac_MessageManager.mm:359
        #20 0x1021d9fe8 in juce::JUCEApplicationBase::main() juce_ApplicationBase.cpp:262
        #21 0x1021d9c84 in juce::JUCEApplicationBase::main(int, char const**) juce_ApplicationBase.cpp:240
        #22 0x100a1e434 in main Main.cpp:187
        #23 0x108909088 in start+0x204 (dyld:arm64e+0x5088)
    

    What is the expected behaviour?

    do not try to read size of deleted array

    Operating systems

    macOS

    What versions of the operating systems?

    12

    Architectures

    ARM

    Stacktrace

    No response

    Plug-in formats (if applicable)

    No response

    Plug-in host applications (DAWs) (if applicable)

    No response

    Testing on the develop branch

    The bug is present on the develop branch

    Code of Conduct

    • [X] I agree to follow the Code of Conduct
Framework for Enterprise Application Development in c++, HTTP1/HTTP2/HTTP3 compliant, Supports multiple server backends

The ffead-cpp Framework ffead-cpp is a web-framework, application framework, utilities all bundled into one. It also provides an embedded HTTP/Web-Soc

Nov 26, 2022
openFrameworks is a community-developed cross platform toolkit for creative coding in C++.

openFrameworks openFrameworks is a C++ toolkit for creative coding. If you are new to OF, welcome! Build status The master branch contains the newest,

Nov 28, 2022
An open-source C++ library developed and used at Facebook.

Folly: Facebook Open-source Library What is folly? Folly (acronymed loosely after Facebook Open Source Library) is a library of C++14 components desig

Nov 23, 2022
An open source library for C

Homo Deus - C Library Introduction The Homo Deus C Library (hdelibc) is an open source collection of tools for the C programming language. The project

Nov 28, 2022
A toolkit for making real world machine learning and data analysis applications in C++

dlib C++ library Dlib is a modern C++ toolkit containing machine learning algorithms and tools for creating complex software in C++ to solve real worl

Nov 24, 2022
C++14 evented IO libraries for high performance networking and media based applications

LibSourcey C++ Networking Evolved LibSourcey is a collection of cross platform C++14 modules and classes that provide developers with an arsenal for r

Nov 22, 2022
hypertextcpp - is a hyperfast HTML templating system for C++ applications.
hypertextcpp - is a hyperfast HTML templating system for C++ applications.

It provides a highly readable .htcpp template file format and a command line utility that transpiles it to C++ HTML rendering code. Include a generated C++ header file in your project, then setup a build system to update it when necessary, and you're all set.

Oct 18, 2022
An eventing framework for building high performance and high scalability systems in C.

NOTE: THIS PROJECT HAS BEEN DEPRECATED AND IS NO LONGER ACTIVELY MAINTAINED As of 2019-03-08, this project will no longer be maintained and will be ar

Nov 20, 2022
Idle is an asynchronous and hot-reloadable C++ dynamic component framework
Idle is an asynchronous and hot-reloadable C++ dynamic component framework

Idle is an asynchronous, hot-reloadable, and highly reactive dynamic component framework similar to OSGI that is: ?? Modular: Your program logic is en

Nov 29, 2022
? A glib-like multi-platform c library
? A glib-like multi-platform c library

A glib-like cross-platform C library Supporting the project Support this project by becoming a sponsor. Your logo will show up here with a link to you

Nov 27, 2022
🔥 bhook(aka ByteHook) is a PLT hook framework for Android app.

?? bhook(aka ByteHook) is a PLT hook framework for Android app. Most of ByteDance's Android apps use bhook as the PLT hook solution online.

Nov 28, 2022
PYNQ Framework for ANTSDR
 PYNQ Framework for ANTSDR

PYNQ Framework for ANTSDR This project was inspired by PYNQ and PlutoSDR. There are already many SDR platforms based on ZYNQ and AD9361, so does ANTSD

Oct 20, 2022
Fast, orthogonal, open multi-methods. Supersedes yomm11.

YOMM2 This is a complete rewrite of YOMM11, which is now deprecated. This library is much better, see here to find out why. TL;DR If you are familiar

Nov 23, 2022
Nov 27, 2022
EASTL stands for Electronic Arts Standard Template Library. It is an extensive and robust implementation that has an emphasis on high performance.

EA Standard Template Library EASTL stands for Electronic Arts Standard Template Library. It is a C++ template library of containers, algorithms, and i

Dec 1, 2022
Functional Programming Library for C++. Write concise and readable C++ code.
Functional Programming Library for C++. Write concise and readable C++ code.

FunctionalPlus helps you write concise and readable C++ code. Table of contents Introduction Usage examples Type deduction and useful error messages T

Nov 28, 2022
Easy to use, header only, macro generated, generic and type-safe Data Structures in C
Easy to use, header only, macro generated, generic and type-safe Data Structures in C

C Macro Collections Easy to use, header only, macro generated, generic and type-safe Data Structures in C. Table of Contents Installation Contributing

Nov 23, 2022
A collection of single-file C libraries. (generic containers, random number generation, argument parsing and other functionalities)

cauldron A collection of single-file C libraries and tools with the goal to be portable and modifiable. Libraries library description arena-allocator.

Oct 26, 2022
C++ Parallel Computing and Asynchronous Networking Engine

As Sogou`s C++ server engine, Sogou C++ Workflow supports almost all back-end C++ online services of Sogou, including all search services, cloud input method,online advertisements, etc., handling more than 10 billion requests every day. This is an enterprise-level programming engine in light and elegant design which can satisfy most C++ back-end development requirements.

Nov 25, 2022