`juce7` technical preview branch

You can buy it now!


The first step towards improving message-thread animations will be hooking up functionality similar to openGL’s setContinuousRepainting. This helps to avoid any redundant drawing, or skipped frames, caused by timers falling out of sync from a display’s FPS.

1 Like

You forgot to add LV2 to the README.md :#

Also worth updating the description on github :slight_smile:



Thanks for the mention @dave96 - I’m looking forward to seeing what’s in this branch and how it affects my little library.


We don’t have anything animation-specific published yet.

The initial JUCE 7 release contains the important groundwork on Windows, macOS and iOS, but it’s not yet accessible to users.


@drmr1 @ttg Thanks, we’ll get that fixed.


The first step towards improving message-thread animations will be hooking up functionality similar to openGL’s setContinuousRepainting. This helps to avoid any redundant drawing, or skipped frames, caused by timers falling out of sync from a display’s FPS.

Sure hope this will become true. One day.

The timing behavior was always very strange on Windows. It seems to fluctuate, even if called at a very high rate with correct delta time calculation.

One good example is the GraphicsDemo project. The one with the moving JUCE icon. If you turn off rotation, so it’s really just an image moving on float coordinates you will perceive micro stutter no matter what. Even with OpenGL and setContinousRepainting!

If you turn off the timer
startTimerHz (60);
and use

if (auto image = getCachedComponentImage())

in GraphicsDemo::paint, it seems less noticeable, but it’s still there.

This is not a driver or Vsync issue, since a simple comparison with an JS + Canvas animation loop in any browser shows butter smooth movements. Tested the latest repaint consolidation stuff on JUCE 7 and unfortunately it didn’t change this behavior.

1 Like

This is my number 1 pet peeve with juce. I wrote a OpenGL vertex buffer style histogram to get around it. It’s when you touch the g.doStuff() commands that it starts. Doing stuff via native OpenGL while keeping to its thread is perfect, but that makes the entire graphics API in juce useless (in this context). Hope the new animation classes fix it!

Can we have the last “legal” commit which we’re allowed to access for Juce 6? thx

This is the most recent commit on the master branch before we bumped the version number to 7.

I’ve debugged these crashes a bit, but it’s quite difficult to see what’s going wrong as the crash is inside the pre-built (stripped) plugin binaries. I’ve also tried building the plugins from source, so that they retain debugging information, but wasn’t able to get very far. Building the plugins in an MSYS Mingw-w64 environment seems to dynamically link dependencies (cairo, pango etc.), and the UI can’t be loaded in the APH, even when I copy all of the DLL dependencies next to the running APH executable. @x42, please could you describe how the Windows build environment should be configured so that I can debug this further?

One clue, which may or may not be related: When opening and then exiting the AudioPluginHost with an instance of fil4.lv2, and with Application Verifier active, I see the following output in the debugger. This happens even if no editor window is opened - it’s triggered by just loading and then unloading the UI dll.

3b74:0e6c @ 01364875 - LdrpProcessDetachNode - INFO: Uninitializing DLL "C:\Program Files\Common Files\LV2\fil4.lv2\fil4UI_gl.dll" (Init routine: 00007FFE6B527530)
3b74:0e6c @ 01364875 - LdrpCallTlsInitializers - INFO: Calling TLS callback 00000000627F5FE0 for DLL "C:\Program Files\Common Files\LV2\fil4.lv2\fil4UI_gl.dll" at 00000000627C0000
3b74:0e6c @ 01364875 - LdrpCallTlsInitializers - INFO: Calling TLS callback 00000000627F5FB0 for DLL "C:\Program Files\Common Files\LV2\fil4.lv2\fil4UI_gl.dll" at 00000000627C0000

VERIFIER STOP 0000000000000201: pid 0x3B74: Unloading DLL containing an active critical section. 

	0000000062DA73A0 : Critical section address. Run !cs -s <address> to get more information.
	0000022B5F50E060 : Critical section initialization stack trace. Run dps <address> to dump the stack trace.
	0000022B07E12FD6 : DLL name address.
	00000000627C0000 : DLL base address.

I’ve got a response from ardour: 0008942: Ardour LV2 host doesn't provide boundedBlockLength in features array - MantisBT

It’s a feature that plugins can require (lv2:requiredFeature), and the host in turn implements and provides
LV2 Buf Size
LV2 Buf Size

In case of Ardour both are set, minBlockLength is 1 and maxBlockLength 8192. This has been implemented since 2015.

Compare to other plugins that use it (ZynAddSubFX.lv2, KlangFalter.lv2, Pianoteq 6.lv2, moony.lv2 etc)


Reading the source, it looks like the feature is indeed not explicitly announced
to the plugin, but the min/max options are set.

1 Like

Looks like this will be fixed in Ardour 7.

yeah, and patch is applicable to 6.9

It might be something stupid on my side, but I can’t get any sound from LV2 plugins built with JUCE 7.0.1
Neither from any I build locally, neither prebuild from http://socalabs.com/ (GitHub - FigBug/slPlugins: Various VST/AU Plugins from SocaLabs.com) or OB-Xd synthesizer 2.9 Nightly Builds (GitHub - reales/OB-Xd at development)

I’ve tried many hosts, and APH also.

EDIT: If I build with cmake (not with Projucer) - then sound is working. I’ll look further.

What platform + compiler version are you using to build the plugins? I’d like to try to repro the issue.

I just tried building the AudioPluginHost and the AudioPluginDemo LV2 in Xcode using Projucer-generated projects. The resulting AudioPluginDemo loads in the APH, and produces audio in response to incoming MIDI.

It might be interesting to compare the .ttl files (located inside the plugin’s .lv2 folder) for the Projucer-generated and CMake-generated plugins. I would expect these to be identical; any differences may indicate a problem in the Projucer exporter.

If you’re on Linux, then the CMake builds and Projucer builds may use different compilers, stdlibs, build flags etc. depending on your environment and CMake options, so it might also be informative to run both builds in ‘verbose’ mode and to compare the compiler invocations. I’d be surprised if this was the cause of the problem, given that the plugins can be loaded, but it can’t hurt to check.

You could also try running the host under a debugger and check whether the plugin’s prepareToPlay, processBlock etc. are being called.

Yes, I’m on Linux openSUSE TW. I think the bug occurs when .jucer has Plugin Channel Configuration set.
If you add {0,2} to the AudioPluginDemo with Projucer then it should be reproduced and actual input/output channels weren’t configured.

More info here:

Is there a way to patch juce_LV2_Client.cpp so that it works with ardour 6 ? I thought commenting the “return nullptr” at line 1371 should allow it to proceed since ardour is returning a valid block size, but it crashes later in the run() method while calling “ports.prepareToWrite()”.

That’s a bit annoying for me as my previous releases were using the LV2 wrapper by falktx, and used to work with ardour. Since ardour 7 is not even released I’ll be getting a ton of support issues if I switch to the new lv2 wrapper.