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

• configure JUCE to build the extras
• build JUCE with extras
• export the XDG_CONFIG_HOME envvar, setting it to /tmp/
• run the SystemInfoDemo:

  XDG_CONFIG_HOME=/tmp/ ./SystemInfoDemo_artefacts/SystemInfoDemo
  

notice that the SystemInfoDemo window says:

> User application data folder:   /home/user/.config

### What is the expected behaviour?

i expect it to honour the `XDG_CONFIG_HOME` *envvar, so that SystemInfoDemo says:

> User application data folder:   /tmp



note, that adding a line `XDG_CONFIG_HOME=/tmp`  to the `~/.config/user-dirs.dirs` file works.

however, when i read the [specifications](https://specifications.freedesktop.org/basedir-spec/latest) i only see that the *environment variables* must be honoured.
i guess that falling back to values in `~/.config/user-dirs.dirs` is fine, as long as the environment variables take precedence.

it should be simple enough to first check the envvar whether it exists, before parsing the `user-dirs.dirs` file for a fallback.

### Operating systems

Linux

### What versions of the operating systems?

Debian/bookworm

### 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

I have not tested against the `develop` branch

### Code of Conduct

- [X] I agree to follow the Code of Conduct

The issue has been described on the JUCE Forum: thread.

The are two commits in this PR, the first one is important and fixes the issue and the second one is just formatting, but they can be squashed into one.

The issue has been described on the JUCE Forum: thread.

This PR reverts the commit. that introduced the bug with some minor adaptations to fix the conflicts with later modifications.

When the Projucer is built under Linux, the symbol "linux" must be undefined to avoid colliding with the TargetOS::OS::linux enumeration member. Presently, this is only done when building with GCC. This pull request modifies jucer_CommonHeaders.h to also under it when building with clang.

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.