HISE iOS: No viable overloaded '='

MacOSX and iOS
1

I am trying to compile my iOS HISE project and I am getting the error “No viable overloaded ‘=’” concerning this line of code, I wrote THIS on the line that Xcode says is an issue.

#if HISE_IOS
    if(!HiseDeviceSimulator::isAUv3())
    {
        const String portName = FrontendHandler::getProjectName() + " Virtual MIDI";
        
     THIS   if(virtualMidiPort = MidiInput::createNewDevice(portName, callback)) THIS
        {
            virtualMidiPort->start();
2

The interesting part is the second of the error message: “No viable overloaded ‘=’ from type X to type Y” so we know what the compiler tried to implicitly cast.
Type X is the return type of MidiInput::openDevice() which is a std::unique_ptr<MidiInput>.
I am guessing now that your virtualMidiPort is a MidiInput*.

If that doesn’t help, please tell us the declaration of virtualMidiPort.

3

I was able to fix that thankfully.

Now I have a new problem which is the last error I am getting in Xcode:

glGetIntegerv(GL_BLEND_SRC, &blendSrc);

Use of undeclared identifier ‘GL_BLEND_SRC’

glGetIntegerv(GL_BLEND_DST, &blendDst);

Use of undeclared identifier ‘GL_BLEND_DST’

4

The previous issue is symptomatic of trying to take code written against JUCE 5 and update it to build with JUCE 6, after the std::unique_ptr transition.

So something to check is whether HISE is somehow trying to build against a newer version of JUCE on your system, say for example if “Use Global Paths” were checked in the project’s module section, and those global paths were pointing to that newer JUCE on your system rather than the older modules that accompany HISE.

5

I work with Daryl btw, thats why you are seeing me reply so much.

The issue I think I faced is that simply copying and pasting JUCE 6 to my HISE folders give me MORE errors as the HISE projects I guess use JUCE 5 perhaps, and those folders are modified for HISE. Just can’t use the standard JUCE files.

So what do you suggest I do?

6

That’s not the best approach, as there are reasons why Christopher modifies his version of JUCE, so you unfortunately can’t go back to stock JUCE either.

I’ve just taken a look, and it seems the develop branch includes a binary of the Projucer that’s at 5.4.3, so in case you are using that binary, there will be a mismatch between the Projucer version and JUCE modules version. You will need to build the Projucer again using the exact version of JUCE that is on the develop branch.

1 Like
7

I gave it a shot and was able to build the Projucer on the develop branch. I noticed the diff here and applied it first, though I don’t think it affects any files that contribute to building the Projucer itself:

I ran this from terminal:

git apply working608_patch.diff

This should hopefully sort you out (there are no iOS templates to try and build).

I pushed a few changes to my fork which allowed me to build the plug-in template but not the standalone.

With the latter many errors converge on hi_core.h but XCode is of no help tracking down the real locations of the issues. I think with certain project structures, some IDEs aren’t able to trace errors correctly (and this project has a very complex structure).

8

I’m getting errors trying to build HISE on both the Standalone and plugin with your fork.

Can I just use my existing standalone of HISE and export my project again using your fork as the HISE source folder?

9

You’ll need to work through the errors, my fork seems a lot closer to being buildable than what I pulled from the upstream’s develop branch.

You should probably try and step through a checklist of steps needed to build:

  • Did you switch to the develop branch of this fork?
  • Did you rebuild the Projucer?
  • Did you apply the patch?
  • Did you install Intel IPP via the new OneAPI installers?

I know nothing about HISE but found it interesting when I saw your posts, so wanted to get it working for myself to have a look at how it works. I am not sure as to the answer to your question, but it seems it might work, however, it’s probably best to work completely in a single environment’s build products.

10

Yes to question one. No because I’m not entirely sure what you mean by that. The Projucer application is something you download to my knowledge. Apply the patch to your fork? No, I will try that. I don’t like to install IPP and there is clear instruction on how not to. Just got to disable IPP in the Modules - hi_core, and then remove all IPP references in the Release and Debug macOS builds in the Projucer.

I will Google how to build the Projucer as you said.

11

I’m getting a bunch of patch does not apply errors. I will keep trying.

12

I’ll have to wait until you respond.

Can’t apply the patch and there is no working through the errors, if I delete a problematic line of code it’s unless errors.

Can you perhaps send me your completed build please? I can work with the plugin you compiled.

13

If the patch doesn’t apply it means the code already contains the needed changes or the patch is out of date wrt the code it’s applying to. When I ran it I got no output, so I was unsure if it had an effect, but maybe not. But it’s good to learn about this stuff - a pre-built Projucer for example will be perpetually out of date so it’s best to learn to build it yourself.

14

Tried things with your plugin and develop fork, still the same issue.

I am moving on from HISE, trying out audio kit.