My point was that it might be useful to point out that there already exists a good library for animation in JUCE in case anyone else reads this public thread.
Additionally, I thought it might spark some conversation about how the proposed JUCE animation classes differ from this existing library.
Fair enough! animator is pretty well-rounded, and is listed in the awesome-juce repository in case people want to explore any other solutions out there.
In terms of conversation about animations, what I’d ideally like to happen (at some point) is that designers would just design, and JUCE devs would just point code to the designs (and obviously tie the business logic).
That being said, it’d be nice to know what’s inbound because, with decent groundwork in place, I’m hoping there’s enough flexibility to bridge an animation solution to content from the liking of InVision or Figma. (All of which is possible… don’t ask me how!).
Anyway, I created an FR long ago to cover useful features off the top of my head: FR: Add Animation Support with Timeline Controls
Looks like it’s pushed to master now, when can we buy it?
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.
You forgot to add LV2 to the README.md :#
Also worth updating the description on github 
RTAS LV2
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.
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())
image->invalidateAll();
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.
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)
UPD:
Reading the source, it looks like the feature is indeed not explicitly announced
to the plugin, but the min/max options are set.
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.
