[Fixed on develop] Projucer errors in juce_Matrix.h from the dsp module


#1

Does anyone else see a bunch of errors from the juce_Matrix.h in the Projucer?

“no member named ‘plus’ in namespace ‘std’” etc.

Xcode builds OK. I am on OS X 10.12.4, with JUCE 5.1.1. I have selected C++14 in the project settings.

//cc: @IvanC


#2

That was fixed a while ago - grab the latest code from develop.


#3

Thanks @jules.

Is there any way I can check when the next release is scheduled for? I try not to use bleeding-edge work and wait for official releases where possible.


#4

We don’t pre-announce release dates, because that’s never a good idea…

But regardless, anyone using release versions should always check the develop branch before reporting things like this - it can avoid wasting your own time puzzling over bugs as well as ours in answering.


#5

Sorry to have wasted your time. I’ll be checking the dev branch from now on.

Should I be updating the Projucer with some dev-version, too?


#6

:slight_smile:

It’s always best to use the version of Projucer that matches the code that you’re using, as if you use out-of-sync versions it could lead to subtle problems.


#7

We don’t pre-announce release dates, because that’s never a good idea…

Sorry for the derailment, just thought I’d share this funny tidbit on that note: Valve Time


#8

Sorry, I was under the impression that I can’t build the Projucer because of a proprietary part you guys haven’t released as open-source code (the live build?). Now I see I can build it and then download the engine from the app.

Got the latest develop branch from github (& built Projucer) and the problem is resolved.

Thanks.


#9

Furthering your derailment, for anyone who wants more context (since non is given on the wiki page) Valve is a video game company notorious for announcing things with very specific to non-specific release times when the reality is that the release date is “when it’s done”.

This leads to the aforementioned Valve time, where engineers wildly mispredict release times, often with zero communication to customers before, during, or after the missed release date. It’s funny in hindsight because the finished product is usually better than without the delays but can totally piss off your customers for obvious reasons.

Recent example: the DSP module, which seems to have been in (or at least I imagine was) development hell for a loooong time. Luckily the finished product is great, I’m sure largely because of a large number of iterations (taking lots of time) between @IvanC and ROLI to make it awesome.