Integrating Adobe AIR with JUCE


#1

Hello,

We are working on an Flash AIR project. We created a Juce dll project in visual studio. And we used Adobe native extensions. Adobe gives us a C library that we integrated into JUCE which allowed us to use JUCE through ADOBE AIR. I think this is a powerful combination, because AIR allows us to rapidly prototype an application, combined with the Audio features of JUCE has given us what we want. That is working fine.

Now we want to port this to the IPAD. Not sure how to approach this. We are attempting to build a static library in XCode 4.3 and use that to integrate to ADOBE AIR. First we need to find a static library project that actually builds. The Introjucer doesn’t seem to help in setting anything for XCode because we are not building a Juce Application but rather a static library that uses Juce, there appears to be problems with Juce’s platform-specific macros not being set.

The closest was TheVinn’s project(http://rawmaterialsoftware.com/viewtopic.php?f=4&t=7737), but it appears to be out of date. I am looking for advice, a starting place to begin experimenting. TheVinn’s project seems to build but doesn’t seem to succeed at creating a static Library, because the products appear in red, which means to me that something has failed.

What I need is a simple project as a starting point to transfer the code we have developed from the dll project.

thanks for any help.


#2

With the new modules structure you should just be able to add the 13 or some odd number of Juce sources. juce_core.cpp, juce_audio_basics.cpp, juce_graphics.cpp, etc…

You don’t necessarily need to have a static library project. In fact the new Juce modules structure makes doing so quite unfriendly. If you already have an existing static library just add the Juce module source files to it.

Are you saying that the latest DSP Filters Demo on Github doesn’t compile on XCode for you?


#3

Hi thanks for your reply.

It builds successfully but doesn’t produce the library. Both products of the build are red. I am not that familiar with the XCOde compiler. I don’t understand how it can say that the build was successful and the products are not.

Adobe Flash requires a dll on Windows, and it appears to require a static library on the mac. This is because Adobe accesses the library we build. It does not work with an executable. So we are forced to build a static library that AIR can access.


#4

It’s easy to make a static library from scratch in XCode. Just create a new project, set it to produce a static library, and add the 13 or so Juce modules to it.


#5

I got this message:
Check dependencies

File /Users/Dovid/Library/Developer/Xcode/DerivedData/DSPFilters-apaksrwycqnmdycsurkzgtkndvoh/Build/Products/Debug-iphoneos/libDSPFiltersiOS.a depends on itself. This target might include its own product.

Then upon building the project, everything seemed to have gone fine, except for no products were produced: See screenshot.


#6

I believe that’s a bug in XCode. The same thing happens to me. If you’re able to run the DSP Filters Demo, then obviously the libraries got built! You will have to dig around in the directory where XCode produces its output to find the .a files.

I still don’t understand why you dont just make a new empty static library project, and toss the Juce module sources into it…


#7

Hi,

DSP Filters runs…Finally found the libDSPFiltersiOS.a file, in the tmp directory. Then not sure where it needs to be for the Demo to use it. Also the JuceAmalgam project won’t build…I think I might be missing the iOS 4.3 SDK…


#8

Alright, so DSP Filters runs on Macintosh, but fails to build on iOS? Is this related to this commit: https://github.com/julianstorer/JUCE/commit/3b431954ecef57e570105b46103c07ec4b2a6220 ?

I’m working on revising the Juce amalgmation to bring it up to date, and get it down in size too.


#9

I recreated the entire Juce amalgamation from scratch in an empty repository:

https://github.com/vinniefalco/JuceAmalgam

Put the amalgamated files in Include into a new static library project, and it should compile for you. I incorporated the fix from Jules for iOS. This amalgamation is also considerably smaller! It should work without a hitch - let me know.


#10

Thank you very much…I will give it a shot and let you know what happens.


#11

We have been able to compile a static library. The problem is when we integrate JUCE with ADOBE AIR we get an error. We created a non JUCE static library and it works. Something in the JUCE Headers may be affecting the final linking. Does anyone have any experience with Adobe AIR and JUCE? The error we get is this:
ld warning: unexpected srelocation type 9
Undefined symbols:
"_finalizer", referenced from:
_g_com_adobe_air_fre_fmap in extensioglue.o
"_initializer", referenced from:
_g_com_adobe_air_fre_fmap in extensioglue.o


#12

This looks like something having more to do with the C runtime or linkage than anything JUCE specific.

I believe that _initializer and _finalizer are exported functions that are used when loading a shared library. they are called when the shared library is loaded and unloaded respectively. Typically the C/C++ runtime needs to have certain code execute on startup and exit (for example, constructors and destructors of objects with static storage duration).

For a shared library each development platform uses its own techniques for implementing this. Try asking in the Adobe AIR forum.

You can also just try making your own functions:

extern "C" {
void initializer () { }
void finalizer () { }
}

Keep in mind, this is all guesswork.

Are you SURE that Adobe AIR expects a static library and not a dynamic library?


#13

There’s talk here about implementing a “native extensions” library, which seems to me what you’re doing:

http://help.adobe.com/en_US/air/extensions/WS901d38e593cd1bac-3004221412afa24c001-8000.html#WS901d38e593cd1bac14557ab012afe6a6fb0-7ffd

Are you using the Adobe AIR C API? I think you need to provide the initializer() and finalizer() functions, according to those docs. Use the code example in my previous post.


#14

Actually, we are using our own initializer and finalizer functions: MainClass.h

#import "FlashRuntimeExtensions.h"

#ifdef __cplusplus__
extern "C"
{
#endif
	
    void initializer (void** extData, FREContextInitializer* ctxInitializer, FREContextFinalizer* ctxFinalizer);
	void finalizer(void* extData);
    
#ifdef __cplusplus__
}
#endif

And MainClass.cpp (or MainClass.m, doesn’t seem to matter about the extension cpp or m):

#import "MainClass.h"

//--FRE stuff
FREContext pContext;
FREResult pFREResult;

#ifdef __cplusplus__
extern "C"
{
#endif
    
	FREObject setContext (FREContext ctx, void* funcData, uint32_t argc, FREObject argv[])
	{
		pContext = ctx;
		return NULL;
	}
    
    FREObject getFive (FREContext ctx, void* funcData, uint32_t argc, FREObject argv[])
	{
		int32_t x = 5;
        FREObject freX;
        FRENewObjectFromInt32 (x, &freX);
        return freX;
	}
	
	void contextInitializer (void* extData, const uint8_t* ctxType, FREContext ctx, uint32_t* numFunctions, const FRENamedFunction** functions)
	{
		*numFunctions = 2;
        
		FRENamedFunction* func = (FRENamedFunction*) malloc(sizeof(FRENamedFunction) * (*numFunctions));
        
		func[0].name = (const uint8_t*) "setContext";
		func[0].functionData = NULL;
		func[0].function = &setContext;
        
		func[1].name = (const uint8_t*) "getFive";
		func[1].functionData = NULL;
		func[1].function = &getFive;
        
		*functions = func;
	}
    
	void contextFinalizer (FREContext ctx)
	{
		return;
	}
    
	void initializer (void** extData, FREContextInitializer* ctxInitializer, FREContextFinalizer* ctxFinalizer)
	{
		*ctxInitializer = &contextInitializer;
		*ctxFinalizer = &contextFinalizer;
	}
    
	void finalizer (void* extData)
	{
		return;
	}
    
#ifdef __cplusplus__
}
#endif

This works perfectly. I can create an IPA and push it on to the iPad.

This is just from creating a Cocao Static Touch library, with the two files above and adding in the “FlashRuntimeExtensions.h” via the “Add Files to” context menu item in XCode. I don’t need to touch any XCode settings at all.

Now, if I could only figure out how to add the simplest bit of Juce into this, I would be set…Just a simple function that returns a Juce String and requires only the juce_core module. I have tried exhaustively to accomplish this but the library just won’t build this way.

Coming at it the other way, I have tried to use the introjucer in Windows (it won’t build on my Mac) to set up an iOS static library project with just the core module included. Then I add in the adobe stuff and it builds just fine (except for the disconcerting fact that the .a file shows in red and I have to hunt for it, which I believe you said was a bug in another post). I can even create a native extension with it. It is when I try to create an IPA using Adobe’s adt tool, that we get the error:

[quote]ld warning: unexpected srelocation type 9
Undefined symbols:
"_finalizer", referenced from:
_g_com_adobe_air_fre_fmap in extensioglue.o
"_initializer", referenced from:
_g_com_adobe_air_fre_fmap in extensioglue.o[/quote]

Now, for my experience level there are just too many unknown variables and places where things could be going wrong. It could be some adobe argument or something in XCode. It could be a major oversight or a tiny little bug or maybe it is not even possible to combine adbobe’s native extensions with Juce on the iPad. I have spent about 40 hours now trying to figure this all out.

So in short, if I could just get a complete noob breakdown of just how to add the juce core module to a Cocoa Static Touch project, I would be very grateful. This would really help me narrow it down.

Thanks,
Josh


#15

Well, I have finally managed to add a Juce module to the Cocoa Static Touch project referred to above, manually and it builds fine in XCode. I just can’t get rid of the srelocation warnings when I build the ipa, no matter what I do and I have tried just about everything. As long as I don’t include the JuceHeader.h in my MainClass.h file and don’t use any Juce symbols, I can get it to build an IPA which just then opens and promptly closes on the iPad. If I just even include the JuceHeader.h, then I also get the _g_com_adobe_air_fre_fmap in extensioglue.o error and the IPA doesn’t even build. I pretty much get to the same place whether I am working from a pure Adobe Native Extensions project (that actually works!) and add the Juce core module or whether I am working from an Introjucer project with the Juce core module and try to add in the Adobe stuff.

I really wonder if what we want to do is even possible. In fact, the only reference I have found to “extensioglue.o” via google search is this very thread, LOL! And there is no reference via google for “_g_com_adobe_air_fre_fmap” or even “_g_com_adobe”.

Here are links for the two projects, they both build without error in XCode but perhaps there is something really obvious that I am missing in some XCode setting somewhere that will make the difference…


This project is the pure Adobe project, to which I have added the Juce core module and,


This project is the pure juce project, created by the introjucer, to which I have added the Adobe code.

Maybe someone can see something that stands out as not being properly linked in…

Thanks,
Josh


#16

Hey there,
I am completely new with this post and even topic. I read all the discussion but still didn’t get any satisfied answers so can anybody give me some brief idea about this ?

Thank you in advance.