Missing Dependency in Audio Plugin Host Example Project


#1

Hi, I just downloaded the most recent version of JUCE for Mac from the downloads page. I tried to build the Audio Plugin Host example project, but build fails with an error:

/Applications/JUCE/modules/juce_audio_processors/format_types/juce_VST3Headers.h:93:11: ‘base/source/flock.cpp’ file not found

Apparently there is a missing dependency. This is without my doing anything to the project. Any idea what I can do to fix this?


Flock.cpp missed (wrong location) - Plugin host
#2

You need to update to VST 3.6.7

Rail


#3

The question arises: Why is the VST SDK not referenced as a sub project?


#4

What do you mean by a sub-project?

The licensing of the VST3 SDK forbids distributing it with JUCE.


#5

If you read the comment above the line where you see the error then it’ll tell you:

“”"
These files come with the Steinberg VST3 SDK - to get them, you’ll need to visit the Steinberg website and agree to whatever is currently required to get them.

Then, you’ll need to make sure your include path contains your “VST3 SDK” directory (or whatever you’ve named it on your machine). The Projucer has a special box for setting this path."
""""


#6

I am not talking about distributing the VST SDK. I am talking about the way the projucer generated projects are referencing the VST SDK. All world would reference the VST SDK as a subproject (i.e. .xcodeproj, .vcxproj, etc.) instead of referencing its source files directly. The result is you let JUCE users run into the above issues for no benefit at all.


#7

which would mean that the VST SDK is hosted on a public GIT repository. But nobody except Steinberg is allowed to do that, so better ask them, if they would mind change to more modern development pactice. And good luck with that…


#8

Why would that be? I am talking about the way the projucer generated project references the source files. That has nothing to do how the VST SDK itself is distributed.


#9

It would be silly to complicate everybody’s build by adding an extra layer of project build dependencies + troublesome extra static libraries (in multiple flavours for multiple IDEs and compilers), when all that’s needed are some header files and a handful of trivial cpps.

There are no issues as long as you’ve got the right VST SDK and set the header paths correctly. And you need to set those up correctly, regardless of how we build or link it.


#10

Sorry, I thought you were talking about submodules and how to reference the sources, which is the actual problem the OP has.
How it is laid out in the project I don’t care, as long as it compiles with “one click” and I can click on “Go to definition” and it shows me the source code.


#11

Why would referencing the VST SDK as an IDE sub project require extra static libraries and setting up extra dependencies?


#12

Well the only point in having a sub-project would be to build a static library that the main project uses… Maybe you’re using “sub-project” to mean something else.


#13

I see: You are referring to libraries built by the sub project as the “extra” libraries.
But in the end the issue is the projucer dictating the project organization instead of allowing the users project to reference all various dependent sub projects (i.e. AAX, VST, installer and other shared subproject). And because of various JUCE design decisions its hard to avoid using the projucer.


#14

Hmm, I think we may be talking at cross-purposes.

The way we include the VST code has nothing whatsoever to do with the projucer.

And for people who aren’t using the projucer, the way we handle the VST code by including the cpps means that their project will just magically link, without them needing to mess around with those files in their IDE or makefile. There’s no downside I can see to the way we’ve structured things.


#16

OK, thanks jules,

I think we exchanged arguments. There is no progress in positions. You will continue to advocate projucer as the means of project maintenance while I prefer standard tools and techniques.


#17

I don’t understand your point… Nothing we’ve done makes it any more difficult to use juce code in a non-projucer project. In fact, it makes it easier, because if you pull in the juce cpp files, you also get the VST linked with zero extra setup.

We offer the projucer as a tool that we think is really useful, but we don’t discourage people who roll their own projects, and do everything we can to make it easy to use juce in all contexts.


#18

Zero extra setup?
We are forced to use the projucer and keep any project changes out of the way of the projucer, because its pretty awkward to otherwise follow JUCE changes. That is because JUCE does not come in form of any kind of standardized sub project. This is accompanied by a MACRO orgy that actually makes any self maintained juce-as-a-sub-project a pain.
Beneath the limited projucer meta project functionality itself - which prevents build integration at a single place it also pollutes each projects folder structure with those duplicated JuceLibraryCode for no benefit at all.

I understand that the projucer might be helpful for plugin projects with no or limited dependencies to other projects. But as soon as there are some generics based on JUCE or other dependencies in the play the maintanance of JUCE based projects are pretty time intense: wether by working against the projucer or by integrating JUCE oddities without the projucer.

Since by using the projucer we can’t use sub-projects: changes to shared functionality need to be placed and maintained in any projucer project using the shared functionality. For VST it might be acceptable, to directly link to .cpps (although this will break whenever Steinberg changes a bit of its project structure as seen above), its impossible referencing larger sub projects this way.

I understand for all those issues exist workarounds, further complicating maintenance.

It seems there are so profound differences in the way we think about project organization that it actually does not make any sense to further discuss this here.

I would be happy with a JUCE maintained juce.vcxproj / .xcodeproj (maybe linux) subproject I just can reference from my plugin projects.


#19

I honestly don’t understand what you’re getting irate about!

You seem to be complaining that the projucer doesn’t organise things the way you want them, but if you don’t want to use the projucer, that’s fine. Lots of people don’t use it. It’s not compulsory, and we try to make it super-easy to just throw the juce code files into your own project and have it work. So if you really want sub-projects, just build your own projects however you want!

Um… well, it does: juce modules. We use them ourselves for internal sub-projects and find it really helpful, but again, it’s just a suggestion, you can do whatever you want if this doesn’t fit your use-case.

Yes, and that’s all I meant, since that’s the topic of this thread!

But you should welcome this trick, because it’s particularly useful for people who DON’T use the projucer, because it avoids having to faff around manually adding dozens of dependent libraries to a project. We don’t just hide away VST stuff, we do it for all kinds of other embedded things, e.g. jpeg, png, zlib, flac, etc etc, and it’d be a real pain to use juce outside the projucer if you also had to deal with all that junk yourself as sub-projects.


#20

Hi guys!

I have the same problem as well! I’ve downloaded the latest VST3 SDK (3.6.8) and placed the path on Global Paths. However, flock.cpp exist not on “base/source/” but on “base/thread/source/” and I can’t manage to make it work! I still get an error about “base/source/flock.cpp file not found”.

Any suggestions?

Thank you in advance!


#21

We haven’t updated JUCE to be compatible with version 3.6.8 of the VST3 SDK yet - but we will shortly!