Projucer unusable on OSX


I'm trying to use the new Projucer on OSX and it seems like every 5 seconds it freezes for about 20. The CPU goes through the roof. Is it trying to communicate to a server or something? What's the deal? Is it trying to live build? It's current state it's unusable.



It's constantly trying to live build, yes. If you want to disable that, there's some options in the Build menu (Enable Compilation, Enable Continuous Recompiling).

It shouldn't freeze though. What part of the app freezes? The text editor? The whole app?

XCode and Visual Studio have millions of man-hours worth of development time invested in them and are extremely solid tools.   why are you, robclouth, trying to use the projucer when those IDEs will do a much better job assisting with code development, and timur, why are you guys even bothering to develop Projucer?  you guys should be working on other areas of JUCE that need attention (DSP module, multi-bus, how about a windows virtual midi driver??).  Between XCode, Visual Studio, Eclipse, and all of the IDEs listed here:, why even waste resources on ProJucer trying to reinvent the IDE wheel?  Have you guys never heard of Edit-And-Continue for visual studio? 

The projucer's not an IDE, it's a complementary tool to all these IDEs, and it does things that none of the others do. If you think it's just edit-and-continue, then we obviously haven't explained it very well!

Thanks for the quick reply. The whole app freezes and the rainbow wheel appears. It seems to happen even if I change tabs in the software or open the file menu. Or just at anytime, I can't figure it out. With compilation disabled the problem disappears. I assume it's doing the compilation on a separate thread, but then why is it stopping the GUI? I'm not interested in the dynamic compilation so it's fine to disable it, but the fact it defaults to enabled and freezes the app is somewhat...ugly.

I think the OP might be related to this thread?

As far as I can tell, if the Projucer application resides at a path containing whitespace

e.g. ~/My Current Project/juce-grapefruit-osx/

it (mis)behaves as described in my original post (beachbally), remove the spaces from the path

e.g ~/MyCurrentProject/juce-grapefruit-osx/

and it behaves as expected. It seems to be the path to the Projucer that matters, not the path to the project.

I just re-tested this with Projucer 4.1.0 and it does still seem to go unresponsive if there's whitespace in the path to

I'm constantly getting "JIT process stopped responding" messages.  I'm using it as a test bed, so my project just has a mainContentComponent.cpp/.h and all I am doing is adding an extra class to these files in addition to the MainContentComponent class.  I can't really code anything without the compiler quitting.  

Projucer is kinda unusable in its current state.  

Also, i got an error that said I couldn't use it on my machine running 10.9.5.  I have only used on it the machine running 10.11.1 thus far.  

I absolutely agree with the statement "then we obviously haven't explained it very well!"

I posted a similar topic where I figured you were wasting your time trying to compete with Studio, etc as an IDE.

THEN, I happened to watch the CPPCON video and it is so cool.  In a sense it becomes the WHOLE GUI editor, with live code access to be able to see what is happeing.  

Is this a correct assumtion : You can bang up a quick and dirty screen with the traditional GUI editor and then play with the code to get it right?

Do you have any time frame for the Windows and Linux versions?  Seems kinda ironic that a cross platform toolset only runs on OSX.  I wasted my demo time of the ProJucer on a Windows test.  Had I known the ins and outs I would have happily setup a system with OSX for the test.  And from what I now think I know, it would have been full steam ahead with development using OSX.  The resulting code is till cross platform, right?  Who cares what you develop it on.

I moved ProJucer to /Applications and now it's great.  

I use it to prototype modules that render music fonts which depend on spacing each character a few pixels apart.  Once i figured out that it absolutely HATES having to deal with an incomplete class, it works great.  If the class is incomplete, the JIT compiler will crash or stop responding.  

That actually brings up a feature request.  Whenever the JIT compiler crashes, focus changes from the code editor to the JIT messages window.  If we could get a visual indicator of the window changing focus, that woudl be awesome.  it's like how in Logic you have that blue line surrounding an active editor window (Arrange, Event List, Piano roll..).  Right now i'll be typing and then i'll hear a bunch of system pings suddenly because the Compiler Messages window doesn't respond to keystrokes. 

  the workflow is: turn off Continuous Build, edit code such that class is complete in XCode and save, Cmd-Tab over to ProJucer and turn on Continuous Build, Instantiate testbed component, then develop class methods in xcode further until required functionality is achieved and cmd-tab between XCode/ProJucer to edit-save/test   It's exceptionally good at getting very close to where I need my class modules to get very quickly.

We unfortunately lost the developer who was focusing on the Projucer so have fallen behind on it recently.  Will hopefully recruit extra team members soon and get back on track with it!

And yes, the whole two-way GUI editor from my original demo turned out to be unrealistic in all but the simplest cases. It's a complicated topic and I don't have time to explain here, but we're brainstorming ideas for future GUI design tools this year.

I appreciate you taking the time to answer me.

I feel for you with respect to the loss of a key developer.  It recently happened to me and now I am doing my best to get up to speed on the Linux kernel and wifi drivers.  My Juce gui stuff will happen a bit later than planned.  Now I am a one man band, just like I was starting over.