Roadmap to HISE 5
-
@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
-
@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.
-
@aaronventure still not GPL compatible
-
@d-healey how so? aren't you just loading it from the computer in that case?
EDIT: Ah, the IPP license clarifies this.
-
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). - Adding
-
@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 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.
-
@Christoph-Hart yes that's a good compromise, I'll sort it out in a little while and send you the file
-
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!
-
@Orvillain I think the function you need there
trace(filter1GraphData);
- rather than toString -
@d-healey Yep that works. Just odd that the old call stopped working.
-
@Orvillain
toString()
was never a function for objects, it's always beentrace
-
@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.
-
@Orvillain said in Roadmap to HISE 5:
This code was working fine before upgrading to Hise 5
In which commit does it work?
-
@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.
-
@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.
-
@d-healey Was definitely working.
-
-
@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)