Hi All,

Just an informational post here. I got the following error when trying to build the HISE standalone for release:

LLVM ERROR: SmallVector unable to grow. Requested capacity (4294967296) is larger than maximum value for size type (4294967295)
clang: error: unable to execute command: Abort trap: 6
clang: error: linker command failed due to signal (use -v to see invocation)
Command Ld failed with a nonzero exit code

Did some digging and found that a user on the JUCE forum had the same error, which was fixed by an updated to the JUCE DSP module on the develop branch.

Replacing the DSP module packaged with HISE created all sorts of other issues, so I ended up just making the fix linked in the commit from the JUCE forum above manually and it solved the issue and I was able to build.

It looks like some other HISE users might have had this issue too and solved it by changing XCode versions, but this just offers a solution without needing to downgrade XCode.

Figure @Christoph-Hart or any others admin-ing the HISE repo might want to be aware of this.

(Tagging @Casey-Kolb for reference)

@d-healey There was a Debug one and a Release one

Hi There,

I am trying to debug a custom C++ node that I created. When I open the custom node in the Release build of HISE by using HardcodedMasterFX it opens, but when I try to debug by building from XCode with the HISE Debug as an executable, I get the following error when I try to open the custom effect:

Looks like a double-free, but I'm not sure why this would happen in Debug and not Release. Any thoughts @Christoph-Hart ?

@Casey-Kolb for reference

Hi everyone. I've been trying to get the rubberband time stretching library working within a HISE project to create a custom Scriptnode node which involves some time stretching.

I created a new node template using "Create C++ third party node template",
cloned the rubberband library (github link) into ProjectFolder/DspNetworks/ThirdParty/src. Then I built the rubberband libraries using meson, as instructed in the README included in the rubberband repository.

However when I try to either 1) Build the new node inside XCode (after exporting from the AutoGeneratedProjucerFile)
or
2) choose to "Compile DSP networks as dll" I get a bunch of "undefined symbol" linker errors from such as

 Undefined symbols for architecture x86_64
> Symbol: RubberBand::RubberBandStretcher::setTimeRatio(double)

I know that typically this happens when a function in a .cpp file isn't scoped correctly, but both the node file and the rubberband functionality are all header-only and so I don't think that's the problem here.

Any help appreciated! Spent a lot of time trying to solve this already.

@d-healey There was a Debug one and a Release one

@Christoph-Hart To test this I just deleted all of the compiled DLLs, re-exported from HISE debug, compiled and built in XCode in the debug configuration, then loaded HISE Debug as an executable and got the double-free in the same location.

Not sure where the memory corruption could be happening here but still hunting

Should add that these are coming from the XCode output

the crux of the issue seems to be that the array of parameters is cleared here before any elements of that array are actually assigned. I think.

Update: this is happening for ANY compiled DLL that I load in HardcodedMasterFX while in DEBUG mode, seemingly when trying to initialize the parameter list

Hey @Christoph-Hart checking again to see if you have any thoughts here about where this might be coming from. Gonna go digging in a moment.

Hi There,

I am trying to debug a custom C++ node that I created. When I open the custom node in the Release build of HISE by using HardcodedMasterFX it opens, but when I try to debug by building from XCode with the HISE Debug as an executable, I get the following error when I try to open the custom effect:

Looks like a double-free, but I'm not sure why this would happen in Debug and not Release. Any thoughts @Christoph-Hart ?

@Casey-Kolb for reference

@Christoph-Hart for this one I don't have rubberband included no. But that's good to know I guess, it's not so far out of range if it's taking me ~5 minutes

Was just able to do a rebuild in a little over 5 minutes. Better but not great

PS I'm on a 2018 Mac Mini with a 6-core 3GHz Intel i5 and 16GB RAM