Unknown type name 'Float32'; did you mean 'juce::AudioData::Float32'?

I updated JUCE and now every instance of Float32 in my project has the error “Unknown type name ‘Float32’; did you mean ‘juce::AudioData::Float32’?”. I made sure that the global search paths are correct in the Projucer. Any idea why this is happening?

This < JUCE 6: why is a new default plugin project requiring "juce::" in front of everything? > ?

Thanks for the resource. This is definitely related to the issue, but I checked in the Projucer and using namespace juce is still set to enabled in my case. Therefore, I am not sure why I would be having this issue. I am able to get rid of errors for the Float32 instances by replacing them with “juce::AudioData::Float32”, but this creates all kinds of issues in other parts of the code. For example, I can’t call std::to_string on these values, conversions to doubles are now broken, and it even breaks the read() function on one of my AudioFormatReaders.

What kind of type is Float32 generally? Working a few years with JUCE now and never saw it, is it a simple alias for a 32 bit float or is it some struct/class with fancy functionality?

I could be totally wrong, but maybe it was something that was never meant to be part of the public API?

juce::AudioData::Float32 is a class, not a data type. I don’t know how you managed to use it for calling std::to_string() in the first place.

I wasn’t previously using juce::AudioData::Float32. I had audio buffers filled with Float32s (something like AudioBuffer< Float32 >* myBuffer). The std::to_string calls were on the data within the buffer. For example, std::to_string(myBuffer->getSample(0, i)). The only reason I have started changing my code is because when I updated JUCE, all of these previous Float32 declarations are suddenly broken.

Okay, so it‘s basically a 32 bit floating point type. As a plain float is exactly that on every architecture a juce application or plugin is usually built for I wonder why you don’t use that? What was your reason for chosing this Float32 type instead of float in the first place?

You missed my point. I was asking why you were using Float32 in the first place, and how that ever worked with std::to_string()? Float32 is a class, and is not convertible directly to “float”. Did they change the class? Remove an operator in that class? Simply removing the “using” statements that allow you to not put juce::AudioData:: in front of the name cannoot possibly change whether you can pass that value to std::to_string(). Something else changed, or you had a Float32 type defined someplace previously.

1 Like

Checking older (v5.3.2) JUCE code, in case it changed, I still see that the Float32 class has a public member “float* data” which you could pass as needed, and a couple of getters like GetAsFloatLE (LittleEndian), but no operator that would automatically convert a Float32 to a float. I just don’t see any way you could have passed a Float32 directly to std::to_string().

1 Like

My (too fast) response added more confusion than help since IMHO your problem is more related to what @HowardAntares suggested, that is: you probably had a Float32 defined elsewhere in a header (CoreAudio?) that is no more included.

Ah I see what you are saying. Unfortunately, my answer at the moment is that I am not sure why this previously worked. I am more confused than ever now. The code ran perfectly fine and I was able to define AudioBuffers with “Float32” throughout the entire year that I was working on this project. std::to_string always worked just fine on ->getSample() calls to the buffers, so I never realized there was an issue. In response to @nicolasdanet, I don’t remember ever defining Float32 in any header file.

But it could have been defined in a header file of another C/C++ library you have included (such as CoreAudio or whatever)… or headers included by the library you have included!

Nicolas is correct. CoreAudio has the type Float32, as described here: https://developer.apple.com/documentation/swift/float32. It’s an alias for float. That’s what you were using, apparently.

Interesting, that must be it. I am still not sure why updating JUCE changed this definition though. I haven’t changed any of the files that are included with my project or settings in the Projucer. The only change I made was updating JUCE, so the change must have been in JUCE code, right? I can’t find anything in my project files making this declaration or references to CoreAudio anywhere. I am not very familiar with CoreAudio, is there an easy way to restore whatever link was made that allowed me to use the Float32 alias for float as I was before?

Just a guess… have you tried simply not adding juce::AudioData:: in front of Float32 for your buffer definition? Do you get an undefined symbol error if you just use Float32?

Yes, I only added the “juce::AudioData::” in front of Float32 because that is what Xcode suggests to fix the error. Based on the information you and @nicolasdanet have found, Xcode is must be confusing my use of the CoreAudio float alias with the JUCE class Float32, so I have changed the code back to my original version. This is why I am wondering if I need to find some way to link CoreAudio or define Float32 somewhere myself (I never knowingly did this before though). I’ve also been looking through Projucer settings and cannot find anything that seems to be related to the issue.

So have you tested building without that? If it doesn’t give you an undefined symbol for Float32, then you don’t need to do anything special to define it.

1 Like

Use float or your own type alias (with typedef/using) to avoid that mess?

1 Like

@HowardAntares Yes, I’ve tried without the “juce::audioData::”. That’s where the whole issue began. When I updated JUCE I suddenly had errors in every place where I used Float32 and a few other errors related to use of Float32. I just replaced every Float32 with float as suggested by @nicolasdanet and I’ve got things running again! For now, its a mystery as to how I got the CoreAudio Float32 to work in the first place. Thanks to both of you for your help!

1 Like

TBH, it has been already suggested far above in the thread! :smile: