Adding Juce to iOS project


#1

I’m new to Juce although not to iOS development. I’m trying to add Juce to an existing iOS project in order to use the audio stuff. XCode 4.2.
Linking to the Juce.h file produces a handful of Symbol(s) not found errors. Including the amalgamated files gives a huge number of ARC related errors.
I have the Juce Demo project running on the iPad just fine.
Please can anyone give some advice on how to link to Juce in an existing project. Thanks in advance.


#2

OK well…! I had to manually convert some of the classes to ARC, but going the amalgamated route has made my project compile.


#3

Maybe I’m naive, but I have no idea what ARC is? (And google isn’t much help for such a common word)


#4

Automatic Reference Counting:
http://longweekendmobile.com/2011/09/07/objc-automatic-reference-counting-in-xcode-explained/
I had to remove all the retain, release and autorelease calls, and insert bridge qualifiers where objects were being cast to void pointers.


#5

While I am here Jules, hello by the way!
Is it possible to run the audio stuff without the GUI stuff? Because I get stuck on the assertion in ChangeBroadcaster:

// are you trying to create this object before or after juce has been intialised??
jassert (MessageManager::instance != nullptr);

But from a quick reading of some other forum posts, “broadcasting” is only for GUI.


#6

Oh, automatic reference counting… I’ve not really looked into the details of how that works (but it sounds like an awful hack!)

If you’re using the new modules branch, then yes, you can just use the audio modules, and not the GUI ones. That’s one of the reasons I’ve restructured it all like that.


#7

Actually, ARC removes a lot of the hassle, now you just think in terms of weak (simply a pointer to something that safely turns to nil if the memory has been deallocated) or strong (ownership, what has up until now been achieved with retain.) You have to use bridge to cast between C and Obj-C and the other way, but in the end it’s no more ugly than the relationship between C and Obj-C types in the language anyway (which is pretty eccentric in my opinion.)

Anyway, forgive my ignorance but what do you mean by the new modules branch? I downloaded the latest git and in the src folder there are separated bunches of code, is this what you mean? So I can just include whatever bits are relevant? I’ll try it now but if my assumption is incorrect please improve my understanding.


#8

ARC may remove a lot of hassle, but the fact that there are compiler-generated release statements getting inserted into the code sounds extremely dodgy to me.

Modules:
http://www.rawmaterialsoftware.com/viewtopic.php?f=12&t=7660


#9

shrug
It works for me so far, and according to Apple’s best engineering folk, it actually makes the code run better than with manual reference counting. They must have been over it with a fine toothcomb, since one little F-up would kill the whole thing dead. Try it?


#10

About the modules: are the files missing a whole load of #includes? It seems so.


#11

Nope… Can you be more specific?


#12

OK, forgive me if I’m being ultrastupid. I thought that all .cpp files should #include the corresponding .h, yet (to pluck a file at random) juce_ReverbAudioSource.cpp does not have any #include statements at all.


#13

Most of the files are not written to be compiled on their own, they’re included inside a master .cpp file for the module, which has already included all the headers.


#14

So if I want to include a module, I don’t drag the entire folder in, just each master .cpp file?
Is it possible to use the modules without using the Introjucer?


#15

Yes, you’d just add the module’s .h and .cpp file. Have a look at what the introjucer produces when you add a module, and copy that.

I’m actually going to change the structure shortly, so that you’ll be able to use the introjucer to create module “collections”, which would make it easier to do what you’re doing. Too hard to explain here, will elaborate elsewhere when I do it.


#16

Hi,
I have an ARC-enabled project which uses Juce. Recently I attempted transitioning to use the Introjucer, and I’ve enabled ARC by writing “CLANG_ENABLE_OBJC_ARC=YES” in the “Custom Xcode flags” in the Introjucer. But there are two remaining ARC-related issues -

  1. The Juce modules themselves aren’t marked as -fno-objc-arc in the “Compile Sources” build phase, so this produces errors.
  2. In my original project, some files are 3rd party and not ARC-enabled, so originally I marked them as -fno-objc-arc - Something I can’t do through the Introjucer since it doesn’t allow setting compilation flags for specific files.

Any ideas?

Thanks,
Dan


#17

Well, we could tweak the introjucer to add that -fno-objc-arc flag to the files… TBH it’s the first time I’ve heard of the flag, I don’t know much about how the ARC stuff works.


#18

Adding support for ARC to the Introjucer would be great, since it’s now the default for iOS projects, and is Apple’s de-facto standard.

Automated Retain Count is like garbage collection, only better since there’s nothing indeterministic about it. It just synthesizes retain/releases into your obj-c code where appropriate.

Since llvm’s static analyzer is already smart enough to catch wherever you are calling retain/release too many/few times, it can just synthesize these calls for you. That’s what happens in ARC. Since it just synthesizes these calls it is also compatible with running on iOS 4 (only some new features such as weak properties are compatible with iOS 5 only).

Since ARC basically just synthesizes these retain/release it’s also possible for some files to be ARC-enabled and some not in the same project. You just have less manual memory management code to write in the ARC-enabled ones.


#19

Hi Jules!

Have you got any plans to move Juce over to ARC; ARC really does rock as a language feature, the Juce-based code I use is the last Mac/iOS code in my source tree that still relies on retain/release calls. :slight_smile:

Best wishes,

Pete


#20

It’s a nice feature, but I was avoiding it as there are still people using the pre-ARC compilers.

But I don’t think it matters whether I use it inside the library, as you can still use non-ARC code in an ARC project, right?