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.

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.

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 'png_set_sBIT@@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!

	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

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

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.

@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

Detailed steps on how to reproduce the bug

Install fresh raspbian 64-bit on raspberry 4 clone JUCE make launch Projucer

The window is buggy

Additional notes :

I’ve been compiling on CI for raspberry many times without problems, and I just discovered that one of my apps is having troubles rendering the main window on raspberry. Strangely, I have another app that works just fine. I decided to compile it directly from the Raspberry, starting with the Projucer, and I discovered that the Projucer itself is having the exact same problem

I’ll try to summarize my findings, you can try the bleeding edge version to see the problem

OS = Raspbian Bullseye 64-bit JUEC : Fork synchronized to latest commit of develop branch (slightly modified but no big UI changes) App1 = Chataigne ( Chataigne | Chataigne 1 ) App2 = LGML ( LGML | Le Grand Mechant Loop )

Normal GUI Mode (not using OpenGL Renderer) : App1 = Works App2 = Does not work (screenshot above) Projucer = Does not work (screenshot above)

OpenGL renderer mode : App1 = Works App2 = Works but not really : the app shows quite alright but the menubar is showing the same bug Projucer = Not tested with GL renderer

App1 & App2 are both using the same sub-framework for generating the UI ( OrganicUI : GitHub - benkuper/juce_organicui: A massive JUCE module that adds multiple UI and control features 1 ) which allows to switch between renderers.

It’s quite reassuring that Projucer is having the same problem but then I don’t know why App1 is actually working…

If you have any idea about that I’m all ears ! Thank you

What is the expected behaviour?

The GUI is showing normally

Operating systems

Linux, Other

What versions of the operating systems?

Raspbian OS 64-bit JUCE 7.0.3 (latest develop branch)

Architectures

ARM, 64-bit

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

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

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.

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.

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.

Detailed steps on how to reproduce the bug

Take the Audio Plugin Example (from examples/CMake/AudioPlugin), replace line 9-11 in AudioProcessor.cpp

                       .withInput  ("Input",  juce::AudioChannelSet::stereo(), true)
                      #endif
                       .withOutput ("Output", juce::AudioChannelSet::stereo(), true)

with

                       .withInput  ("Input",  juce::AudioChannelSet::ambisonic(5), true)
                      #endif
                       .withOutput ("Output", juce::AudioChannelSet::ambisonic(5), true)

and include the layout in bool AudioPluginAudioProcessor::isBusesLayoutSupported. An assertion gets triggered.

When using 4th order ambisonics, only 4 in-/output channels instead of 25 are available in Reaper.

A 7.1.6 layout seems to be working fine, I cloud also create multiple input buses with this layout exceeding 16 channels.

What is the expected behaviour?

No assertion and the correct channel count

Operating systems

macOS

What versions of the operating systems?

13.0.1

Architectures

ARM

Stacktrace

No response

Plug-in formats (if applicable)

VST3

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

Reaper

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

Detailed steps on how to reproduce the bug

here

What is the expected behaviour?

n/a

Operating systems

Other

What versions of the operating systems?

7.0.3

Architectures

x86_64

Stacktrace

n/a

Plug-in formats (if applicable)

No response

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

n/a

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

AudioFormatReader::searchForLevel currently just checks the first two channels in a given file, regardless of channel count. The screenshots below show a simple command line utility I wrote, which checks for the first and last non-zero samples in an audio file, regardless of channel count. The bottom two files in the table include results from analyzing multi-channel files after making this change, with 8- and 10-channel files respectively.

Detailed steps on how to reproduce the bug

• install JACK for macOS
• build a standalone with -DJUCE_JACK
• run the application, and open the audio-settings
• notice that it does not offer JACK as an audio device

What is the expected behaviour?

i would expect optional JACK support, just like under linux.

it seems that it would be sufficient to also search for libjack.0.dylib (resp libjack.dylib) when trying to dlopen() the jack libraries:

https://github.com/juce-framework/JUCE/blob/bbd6ccbc863edec3150e1e024e4fa3f636802596/modules/juce_audio_devices/native/juce_linux_JackAudio.cpp#L597-L600

Operating systems

macOS

What versions of the operating systems?

10.11

Architectures

x86_64

Stacktrace

No response

Plug-in formats (if applicable)

Standalone

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

Detailed steps on how to reproduce the bug

Tested on both Standalone Plugin and Basic GUI Application.

1. Create JUCE App
2. Try to set a crash handler i.e. in MainComponent.cpp

juce::SystemStats::setApplicationCrashHandler([](void* crashData){
        DBG("CRASHED");
        [... your crash handling code ...]
    });

3. Try to trigger a crash later in the code, i.e. when pressing a button:

 button.onClick = [](){
        abort();
    };

Also tried different approaches to trigger the crash, like assigning a value to a nullptr, or raise(SIGILL) etc., no way. The code inside the handler is never called, and the IP will never stop on a breakpoint inside it.

What is the expected behaviour?

The Crash Handler is invoked and the crash handling code is executed.

Operating systems

Windows, macOS

What versions of the operating systems?

Windows 10, Mac OS 12

Architectures

x86_64, ARM, 64-bit

Stacktrace

No response

Plug-in formats (if applicable)

VST3, AUv3, Standalone

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

Detailed steps on how to reproduce the bug

When trying to remove a LV2 plug-in in Reaper on macOS (Intel and ARM), the DAW crashes due to a segfault. This occurs only if the editor is open, it doesn't crash if the editor is closed or the whole track is being removed. This behavior can be observed with different plug-ins (I've tested it with the IEM Plug-in Suite on v7.0.3 and the empty pamplejuce template on v7.0.2 and the latest JUCE commit on the develop branch). It happens during or shortly after LV2_SYMBOL_EXPORT const LV2_Descriptor* lv2_descriptor (uint32_t index) is called in juce_LV2_Client.cpp.

What is the expected behaviour?

Removing the plug-in without a crash

Operating systems

macOS

What versions of the operating systems?

13.0.1 (M1 Pro) 12.6.2 (Intel)

Architectures

Other

Stacktrace

No response

Plug-in formats (if applicable)

LV2

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

Reaper

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