JP Cimalando

@farvardin then it's a user interface issue? if, so please discuss this topic in a new issue if you don't mind. I will keep this open until adding the LV2...

A backtrace pointed at the code juce_LV2_Wrapper.cpp:1501 This could be an error on the host side, possibly a race condition of some kind. (maybe also why it's difficult to reproduce)...

> perhaps it is just i686, x64 and arm64? yes that's it exactly and the arm32 support which is broken at the moment (according to eel makefile "armv6t2 + VFP")

musl does not have fts, so it seems, it's provided by an external library. Given that all problems seem to stem from fts, i'm considering to implement a posix-only directory...

> Or is the core ysfx lib supposed to be juce-free? It is a goal that the core lib remains free of juce. (and its license constraints) For the directory...

just added: flag `-DYSFX_NO_FTS` replaces fts with posix iteration jpcima/ysfx@958f61d

This issue has received a fix in branch `develop`. juce-framework/JUCE@0e33d45

> how fast is the scanning for these files? This is not yet at a stage where I'm able to tell about the scanning speed. > limited to carla instead...

There is the current status at this branch. Currently it builds the support libraries. https://github.com/jpcima/Carla/tree/jsfx

> How are we going to deal with plugin folder, is there a spec to where these would be stored? It's from some knowledge gathered so far, correct if I'm...