Latest tip build errors


HeapBlock<char> buffer;

can’t cast to WCHAR *

#if ! defined (JUCE_ObjCExtraSuffix)
 #error "To avoid objective-C name clashes with other plugins, you need to define the JUCE_ObjCExtraSuffix value in your JucePluginCharacteristics.h file!"

this does not work on Windows/Linux i had to add && !_MSC_VER and propably something for linux to build it.

and whenever a MemoryBlock is used, it can’t be cast to (void *) getData method has to be added to compile it.

It’s true I get the same error.
getData has to be added two times
and & has to be added here
1081 : data = (void) &chunkMemory;


@djWhite & atom: Thanks a lot for the fixes, works perfect now!

Anyone tried to build latest TIP with RTAS enabled?
I have following linker errors

1>juce_RTAS_Wrapper.obj : error LNK2001: unresolved external symbol “class juce::String const __stdcall juce::operator+(class juce::String,class juce::String const &)” (??Hjuce@@YG?BVString@0@V10@ABV10@@Z)
1>juce_RTAS_Wrapper.obj : error LNK2001: unresolved external symbol “class juce::String const __stdcall juce::operator+(class juce::String,wchar_t const *)” (??Hjuce@@YG?BVString@0@V10@PB_W@Z)

I’m having problems with juce::Strings in my projects after updating with the latest tip. Not unresolved linker errors but an “error C2039: ‘<<’ : is not a member of ‘juce::String’”, it sure was a few days ago?

Maybe you just need to do a clean rebuild? I moved a few binary operators out of classes and made them global operators, but that wouldn’t cause linker errors unless you have some old object files hanging around.

Not a build error, but changing a audio device in the standalone plugin window i get crashes

Program received signal: "EXC_BAD_ACCESS"

and GDB highlights inlined HeapBlock method getData()

There are loads of HeapBlocks used all over the codebase - can you be a bit more specific about which one?

i’ll try to catch it, it happens when you pick a audio device from the combo in the audio settings dialog. i’ll try to give more info asap.

it looks like it’s crashing when you choose “NONE” as the audio input.

looks like it happens in the audioCallback


#0	0x00274ce7 in juce::HeapBlock<float*>::getData at juce_amalgamated.h:1526
#1	0x00274e7b in juce::CoreAudioInternal::audioCallback at juce_mac_CoreAudio.cpp:635
#2	0x00275219 in juce::CoreAudioInternal::audioIOProc at juce_mac_CoreAudio.cpp:809
#3	0x91238177 in HP_IOProc::Call
#4	0x91237e68 in IOA_Device::CallIOProcs
#5	0x91237d44 in HP_IOThread::PerformIO
#6	0x9123611f in HP_IOThread::WorkLoop
#7	0x91235c43 in HP_IOThread::ThreadEntry
#8	0x91226480 in CAPThread::Entry
#9	0x92789155 in _pthread_start
#10	0x92789012 in thread_start

and the dump for the #1 is:

callback->audioDeviceIOCallback (const_cast<const float**> (inputDevice->tempInputBuffers.getData()),
                                                     bufferSize); /* here */

Ah yes, sorry - looks like the cut-and-paste monster struck there… Will check in a fix shortly!

Hi Jules,
I didn’t try with last GIT : CoreAudio Fix but
I think that the following changes have to be made.

juce_PluginHostType.h (line 136)

-         GetModuleFileNameW (0, (WCHAR*) buffer, size / sizeof (WCHAR));
+         GetModuleFileNameW (0, (WCHAR*) buffer.getData(), size / sizeof (WCHAR));

juce_VST_Wrapper.cpp (line 1081)

-         *data = (void*) chunkMemory
+         *data = (void*) &chunkMemory


Thanks, I fixed the host type thing yesterday, will sort out the VST one.

BTW I think you meant

*data = (void*) chunkMemory.getData();

Hi Jules,

yes you right for the VST one.
Did you mean that you fix and create the GIT yesterday?
I ask this because I downloaded the last version this morning (before the last GIT).
I had to put the .getData in the juce_PluginHostType.h file in the line 136.

135 #if JUCE_WINDOWS\r 
136         GetModuleFileNameW (0, (WCHAR*) buffer, size / sizeof (WCHAR));\r
137         return String (reinterpret_cast <const WCHAR*> ((char*) buffer), size);\r

You shouldn’t need a getData() there, the cast should be enough. I’ll check something in shortly, anyway.