Roadmap to HISE 5

[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.

[d.healey]

@Orvillain said in Roadmap to HISE 5:

This code was working fine before upgrading to Hise 5

In which commit does it work?

[Orvillain]

@d-healey said in Roadmap to HISE 5:

@Orvillain said in Roadmap to HISE 5:

This code was working fine before upgrading to Hise 5

In which commit does it work?

May 30th. Hence my original question to Chris as to whether something changed in this HISE 5 round of updates.

[d.healey]

@Orvillain said in Roadmap to HISE 5:

May 30th.

Just tried your snippet with that commit and I'm getting the function not found error.

There's an Object.toString() function in Javascript, but not in HISE script.

[Orvillain]

@d-healey Was definitely working.

[d.healey]

@Orvillain said in Roadmap to HISE 5:

Was definitely working.

Can you show me a video?

[Orvillain]

@d-healey said in Roadmap to HISE 5:

@Orvillain said in Roadmap to HISE 5:

Was definitely working.

Can you show me a video?

Will do. But I'm very sure this was working at some point. I wrote the code and even sent a video to the client showing them this feature area working.

(updating graph index so that it looks at a different exposed filter graph from a custom filter node)

[Orvillain]

@d-healey OK, apparently I can't show you a video, because now I also cannot get my demo snippet to work!! How strange.

This is so weird. I was sure it was working. Can't explain it, because I wasn't getting an error or anything previously, and my graph data WAS definitely updating, because in the video I sent to my client you can see the graph switching indexes - which is the whole goal of this.

I wonder if it was actually an older commit? I can't really remember now, But as recent as July 2nd, I was updating the Data array for a FloatingTile, using .parseAsJSON() and then setting the index to a value, and then performing a .toString() call on it, to shove the modified data back into the FloatingTile.

Anyway... trace() does work.... but this baffles me tbh. Maybe Chris can say if something changed. The only reason I posted in here was because he was asking for feedback.

local filter1Graph = Content.getComponent("ft_Filter1Graph"); // gets a component on screen
local filter1GraphData = filter1Graph.get("Data").parseAsJSON(); // parses the Data array for the component
filter1GraphData.Index = graphMap[filterType][0]; // this just returns an integer from an array, and sets the index property to that integer
filter1Graph.set("Data", filter1GraphData.toString()); // this shoves the Data back in as a string

In the full code, this was literally the code that was working until very recently.