What is the projucer excellent for? And what is it horrible at?!?!


#1

I made a simple video showing what the ProJucer is excellent for. hopefully some beginners will find it useful!


#2

Very nice intro. And good use of the searchable API docs (still not available from Roli :head_bandage:)

Also maybe worth noting, that a Button has already this active flag:

Button::::setClickingTogglesState (true) does what the mouseDown in 7:20 does, and instead isActive you may call Button::getToggleState().

But it serves well as example :slight_smile:


#3

I think accessing a private member is faster/more efficient than a function
call.


#4

Is this opinion or fact? Just curious if there are benchmarks on this type of stuff you have available.

IMHO calling something 1 time per couple seconds or more would seem trivial. If that method call was in a draw call, it then becomes non trivial. (but it’s in a mouse handler)


#5

opinion. But using members skips the function prologue in the assembly that’s added every time you make a function call. not that the prologue is very many cycles, but it all adds up…


#6

In this case it’s likely to be exactly the same speed - simple getters and setters are almost always inlined by the compiler. An advantage of using getter and setter functions is that in future you have the ability to change their behaviour, and then all the places you use it get the new behaviour for free.


#7

Agreed and a lot of the time it has to do with public API. In some JIT languages(that I have experience with) it’s faster to cache or use member fields for speed internally. Which sometimes seems to defeat the purpose of designing nice APIs. :slight_smile:


#8

Also, if you notice, my video was aimed for beginners who don’t know their way around the API. Which, as @daniel pointed out, isn’t even searchable online yet. So, I’m just “Keeping It Simple, Stupid” for the sake of the newb viewers so they don’t get pwned by the l337 Juce API. All of you advanced commenters can watch it with a grain of salt. :slight_smile:


#9

I wasn’t taking anything away from your video! I watched the whole thing. :slight_smile: Please don’t take me the wrong way, I was asking a serious question, that is all. (see my last comment, it was about thinking in terms of JIT in my head)


#10

Can we actually talk about what the ProJucer is NOT excellent for?!?!

Creating JUCE modules!! And how do you go about creating them/debugging them in XCode so the autoComplete actually works! Because it sure doesn’t work when the files you’re editing are not in the project source folder!! :rage:

(this could be an xcode deficiency, not a projucer deficiency #disclaimer)


#11

Well, as soon as I have the module header containing the magic BEGIN_JUCE_MODULE_DECLARATION, I simply do touch for the files I need in the folder, and when I click “Save and open in IDE” in Projucer, they show up in “JUCE Modules” and I can start typing there.

The auto complete works here, as soon as I added the module in any CPP file in the project, otherwise they are not compiled and hence there is no context for autocomplete, I think. Sometimes it takes a moment or a recompile, until the “Processing files” progress bar in XCode starts.

But a GUI in Projucer to just add empty template files would be a start…