Roadmap to HISE 5

[d.healey]

@Christoph-Hart

I'm just finalising the implementation. I'm using an environment variable for IPP on Linux as discussed, and the USE_IPP flag.

I'm also using an environment variable for FFTW3 on both Linux and Windows. On Windows I also need to pass a path for the fftw header and library which is annoying. I can go into more detail if needed.

Anyway I'll clean up and test and update my PR then we can discuss.

Btw, should that quotation mark in the middle be at the end?

prebuildCommand="%PREBUILD_COMMAND%"%STRIP_SYMBOLS_WIN%/>

[Christoph Hart]

@d-healey yes, but you need to use a delimiter so that it's escaped correctly.

prebuildCommand=\"%PREBUILD_COMMAND%"%STRIP_SYMBOLS_WIN%\"/>

[d.healey]

@Christoph-Hart I thought it should be like this?

prebuildCommand="%PREBUILD_COMMAND%;%STRIP_SYMBOLS_WIN%"/>

I'm looking at this line in the develop branch.

[Christoph Hart]

@d-healey ah yes you're right, sorry, this string is using the Raw literal format so you don't need the escape characters (the DLL template is still using the old style but I forgot that I've updated the other ones).

[d.healey]

For the last few hours I've been trying to statically link fftw on Windows and mostly failing. Then I realised the libraries provided by fftw are just stubs for the dlls! So I have to compile the static version myself.

Now I think this is a bit much for a HISE user to do because it involves installing cmake and messing around with some simd configuration options and stuff.

I think it would be better to include the static library I have already compiled in tools/fftw/windows, along with fftw.h. It's about 6mb in total. This would also avoid the need for setting an environment variable on Windows because the path would be fixed.

What say ye?

[Christoph Hart]

@d-healey what's the rationale for FFTW on Windows? You can just use IPP here, even with GPL software, no?

[d.healey]

@Christoph-Hart IPP uses the Intel Simplified Software licence which is not GPL compatible - it prevents modifying the code, reverse engineering, and isn't copy left.

vDSP on Mac can be used because the GPL includes an exception for linking against system libraries https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException

[aaronventure]

@d-healey if hise resorts to using the Ipp that's gettable via nuget or any of the ones that can be be found with direct links on the Intel website, then you could add it to the installer? There would then have to be an option that it's not included in the plug in, but found in the pc.

Kind of like video games of old used to pack C++ resists and direct X versions.

[d.healey]

@aaronventure still not GPL compatible

[aaronventure]

@d-healey how so? aren't you just loading it from the computer in that case?

EDIT: Ah, the IPP license clarifies this.

[d.healey]

PR is ready for review I think this is as simple as it can be made, I've tested on Windows 10 and 11, and two Linux systems, with IPP, with FFTW, and with neither. I also tested exporting standalone and plugins from HISE. I didn't test or do anything about building scriptnode networks though - not sure if I need to...

I also noticed AVX is now a requirement for building HISE. Probably won't affect anyone on real modern hardware but my VM needed a small adjustment.

Windows
Building HISE on Windows with IPP is exactly as you set it up, I haven't made any changes that affect this.

Building HISE on Windows with FFTW requires:

• Adding AUDIOFFT_FFTW3=1 to the Extra Preprocessor Definitions
• Adding fftw3f.lib to the Extra Linker Flags
• Enabling the static FFTW option in JUCE_DSP.

To export a project with FFTW on Windows you just need to add AUDIOFFT_FFTW3=1 to the preprocessor definitions in HISE preferences. If you also leave the Use IPP box checked then that will take precedence and FFTW won't be used.

Linux
To build with IPP on Linux you need to add some environment variables to ~/.bashrc

export IPPROOT=/home/dave/.local/share/intel/oneapi/ipp/latest # Set this to the correct path on your system
export CPATH=$IPPROOT/include:$CPATH
export LIBRARY_PATH=$IPPROOT/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=$IPPROOT/lib:$LD_LIBRARY_PATH

Then in a terminal run source ~/.bashrc

In Projucer you need to:

• Add USE_IPP=1 to the Extra Preprocessor Definitions
• Add these linker flags -lippcore -lippvm -lipps -lippi -lippcv

To export with IPP you just need to enable the Use IPP checkbox in Project preferences (same as Windows).

To build with fftw on Linux you need to add these environment variables

export FFTWROOT=/usr/lib/x86_64-linux-gnu # Set to the correct path for your distro, I'm using Debian
export CPATH=$FFTWROOT/include:$CPATH
export LIBRARY_PATH=$FFTWROOT/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=$FFTWROOT/lib:$LD_LIBRARY_PATH

And run source ~/.bashrc in a terminal.

In Projucer:

• Add AUDIOFFT_FFTW3=1 to Extra Preprocessor Definitions
• Add -lfftw3f to Extra Linker Flags
• Enable the static FFTW option in JUCE_DSP

To export a project with FFTW just add AUDIOFFT_FFTW3=1 to Extra Definitions in Project preferences (same as Windows).

[Lindon]

@d-healey said in Roadmap to HISE 5:

Windows
Building HISE on Windows with IPP is exactly as you set it up, I haven't made any changes that affect this.

what about building without IPP on Windows???

[d.healey]

@Lindon said in Roadmap to HISE 5:

what about building without IPP on Windows???

Set this to No

[Christoph Hart]

@d-healey nice work Dave! The only thing I'm not sure is whether we should include the static FFTW library on Windows in the repo - it will bloat the repository size for all users but there is only a limited amount of users who will use it, as IPP is the most popular option on Windows.

But I agree that compiling this manually is a PITA that nobody should go through ever again. I could just host the library on the HISE webserver and we'll add a readme at the location with the download URL so people can just put it there if required.

Can you modify the pull request and send me the static library per email (lol), I'm a bit scared that if I accept the pull request the binary will be entangled in the Git history and all our efforts to keep this lean are moot.

[d.healey]

@Christoph-Hart yes that's a good compromise, I'll sort it out in a little while and send you the file

[Orvillain]

@Christoph-Hart

Did anything change in the parseAsJSON stuff for a floating tile?

This is what I was doing prior to this update, and it worked:

local filter1Graph = Content.getComponent("ft_Filter1Graph");
							local filter1GraphData = filter1Graph.get("Data").parseAsJSON();
							Console.print(trace(filter1GraphData));
							filter1GraphData.Index = graphMap[filterType][0];
							filter1Graph.set("Data", filter1GraphData.toString());

But now the toString() call on filter1GraphData returns an unknown function error.

But when I print out the trace of filter1GraphData, I can definitely see data showing up.

Here's a simplified snippet:

HiseSnippet 1038.3oc0V0saiSDEdbalJhAVXQHDbmUtJAUEk+2VVgHaSZfrPSSIkEta0T6wIi53YL1i2tQqpfGEdA3cgmCth2fkyX6D6zVkMMqPh0WDkyOed9747MmYFGHsoggx.jg44y8oHiO.OYtPMq2LBSfF1GY7.7IjPEMvJw0Qy8IggTGjgwteq1gQwBn3m+4aNhvIBaZlKD5YRlM8GXdLUl2wc+dFmOf3POm4kK6VcGZKE8jbYDvmcw0P9D6KISoiH5z1Ai9NR3LjwWha2nocKmG4znQ6C6XS5POzk35VuoSqVcN3v5MOjz5fNzZsQF6crCSIClnHJZH7ROR5LexL4UhjE3YrP1Ebp1nNZBrxItQ8lw3NiWTbBQHiBiyJU6lTp9T7ILG1R+YkrONNfUFh7EMicVGkpeOnjQNJUHgRODOwNf4qxhn4y6iGJfNnKA5M4oRRtnc9SCbOIjgPU0ibIcP.XrDQ4N0psuE7SkGaZZBMnPk0KHAVCXbHi5VesUrfo5Tp5XWWpspbozPk.D4xmKIJlX54LNUiZwJB35I87kBv.flOqR2XIcU8IJBfckrzugxkzQJUopOIHj9jvmN4zQk0nSfTcnvg9R.XavUJ6pFtD19ou4pJ4DU.7dKWoxiciD1JlTXIEijJ5ohxULekYQyqMstYHW26Ll9KLPx4zf6LrV7GrNfkEQdWPC1G914QzkIBM6UUP6sYJH6jBdtDkhgBl5TeZp8.I2QqLz++15MTZGC92OMTWtzRvTePd9z.ESSGi9zW.a5SDjEw8ogWpj9w4l1lAEoJcGThDLe+Dw.F7Q3UZwnWlMkne24YFi5lRfjUCfE2b6yB84j4nKltXZRw8Z1r4q0PXJpWl2WCOq5sQp6eOdwzelFOE+JSKqRKKFCcJ8UVKU46qiEKv.u0hsfBIWd0OKCtLDFgQA+tDdH07ZzULGELBCa72FHzLJa5Lk1pigdt3s1NCCRjNQbhZ0oK54toA.AyJao0aaEgL077ykuGibps1QNaJEeHdLSYO6t43N2AGAoz+EbLcP8GhSlLkQvB3A+x1NUt1lOUtXx5+I3wR9b+YRAyNQ0DShhop05q4PUDZP.8WinB6EUq+35e6u5dV91KTlycJ5m28rHB+FU2iX9RNI3ssxeONibcxiOCu7ix5sQGWXyZRugwZarlV2Yd2gueANsoaoK1u6v6GfO6+Aj8GkQ5SeNg.2G.N7AOJxaBb3fMEHpPP4g5o16nOTLwtl1VSnITgSrg9jkzf001FoAquHHxiXGHetcxg858OuWrGfSh3K7VDt4MXaUGEeAf76Y8f6W9ba6UeU2BXisEXysEXqsEX6sEXmsE3i1VfG7lApu9+ShTRuDMLBcx3iStJgwwBBnFikyn+EvirgaQ

I swear this used to work!

[d.healey]

@Orvillain I think the function you need there trace(filter1GraphData); - rather than toString

[Orvillain]

@d-healey Yep that works. Just odd that the old call stopped working.

[d.healey]

@Orvillain toString() was never a function for objects, it's always been trace

[Orvillain]

@d-healey I don't think that is correct. This code was working fine before upgrading to Hise 5. toString() did exactly what you'd expect, it converted the JSON data object to a string.

Trace is fine, but I regard trace as a logging/debugging command, which is why I wasn't using it.