Roadmap to HISE 5

[Christoph Hart]

OK, time for a matrix:

Task	Projucer Compile Flag	UseIppSetting	Works
Compile HISE	USE_IPP=0	n.a.	OK
Compile HISE	USE_IPP=1	n.a.	OK
Compile FX DLL	USE_IPP=0	UseIpp=Yes	nope
Compile FX DLL	USE_IPP=1	UseIpp=Yes	OK
Compile FX DLL	USE_IPP=0	UseIpp=No	OK
Compile FX DLL	USE_IPP=1	UseIpp=No	OK

Is that the case over there?

both in the preprocessor definitions, and in the hi_lac module.

I think you must not touch the preprocessor definition in the source code, as this will override the UseIpp setting. Just change it in the Projucer project for HISE, then resave & compile. Whether the project compilation (both plugin export & FX compilation is using Ipp is solely depending on the UseIpp flag (as this will properly set the OneAPI setting to work).

But as first step you should be able to compile HISE with IPP.

[d.healey]

@Christoph-Hart The USE_IPP setting has moved from hi_core to hi_lac - any particular reason?

Exporting as VST3 working here on Linux

[Chazrox]

@d-healey

via GIPHY

[Orvillain]

@Christoph-Hart Here are my results:

Task	Projucer Compile Flag	Projucer hi_lac IPP Setting	UseIppSetting	Drew Results
Compile HISE	USE_IPP=0	Disabled	n.a.	OK
Compile HISE	USE_IPP=0	Enabled	n.a.	OK
Compile HISE	USE_IPP=1	Disabled	n.a.	OK
Compile HISE	USE_IPP=1	Enabled	n.a.	OK
Compile FX DLL	USE_IPP=0	Enabled	UseIpp=Yes	YES NETWORKS COMPILE
Compile FX DLL	USE_IPP=0	Enabled	UseIpp=No	NO NETWORKS DO NOT COMPILE !H:\development\HISE\HISE\hi_tools\hi_tools\IppFFT.h(35,10): error C1083: Cannot open include file: 'ipp.h': No such file or directory
Compile FX DLL	USE_IPP=1	Enabled	UseIpp=Yes	YES NETWORKS COMPILE
Compile FX DLL	USE_IPP=1	Enabled	UseIpp=No	NO NETWORKS DO NOT COMPILE !H:\development\HISE\HISE\hi_tools\hi_tools\IppFFT.h(35,10): error C1083: Cannot open include file: 'ipp.h': No such file or directory

Now what I can't quite explain is that I've always had useIpp enabled inside the project compiler settings. So I don't even know how I started getting this issue.

My result from this post:
https://forum.hise.audio/post/105984

Were with the settings prior to updating from the latest develop branch and rebuilding - and IPP would've been enabled for everything.

The new network I created today, that compiles according to the chart above... doesn't seem to instantiate correctly. I'm still investigating this one though, so ignore for now.

[Orvillain]

@Christoph-Hart said in Roadmap to HISE 5:

I think you must not touch the preprocessor definition in the source code

Just to clarify, I didn't edit any code. I'm talking about the setting here:

[Chazrox]

@d-healey modes?? Please share!

[d.healey]

@Chazrox said in Roadmap to HISE 5:

modes?? Please share!

What you talkin bout Willis?

[Chazrox]

@d-healey lol

[d.healey]

@Chazrox Trigger, Note, Loop

[clevername27]

@Christoph-Hart Meanwhile, I was fired by all three clients because of HISE bugs and secret ScriptNode documentation. sigh

[Lindon]

@d-healey said in Roadmap to HISE 5:

@Chazrox Trigger, Note, Loop

yeah but how do they work?

[Christoph Hart]

@Lindon just like the ableton one which I completely stole the feature list from.

[Lindon]

@Christoph-Hart LOL damn! I don't use Ableton I will have to go look it up...

[Lindon]

@Christoph-Hart

damn it again. A quick cursory look and this doesnt seem to resolve the "Note Generator sends Global envelope data to non listening voices" problem....

[Lindon]

@Lindon maybe I should go away and state this problem clearly - there may be another solution...

[Christoph Hart]

@Lindon The note generation must happen one level below the global modulator container. You have to make sure that every voice that receives the global envelope data is started by the same event ID as this is the most robust way of assigning voice indexes.

So if you have this setup:

master chain
   global modulator container
      AHDSR
   sine generator
      Arpeggiator
      GlobalEnvelope / MatrixModulator

it will not work because the arpeggiator will produce new events where the global modulator has no idea how to assign that to voices. But if you either move the global container and the sine wave into a new container or move the arpeggiator to the root level it should work correctly.

[Lindon]

@Christoph-Hart yeah but sadly no _ want the arp to be shared(able) between voices...see my post:

Global Envelopes - The "filtered" voices problem.

So I have a problem with Global envelopes...I'd really like to use them, but..in a multi-voice system they are problematic....here's why (perhaps someone kno...

Forum (forum.hise.audio)

[Orvillain]

I'm getting a crash when using .setEffect() on a hardcoded polyphonic fx module. I'm doing something like this:

                modeData["polyRMSlot"] = Synth.getSlotFX(modePath + "_polyRM");
                modeData["polyRMSlot"].setEffect("polyRingMod");

This is in the context of a loop, and modePath is the prefix of the name string.

But interestingly, the crash only happens whenever I call Builder.clear()

IE: On the first run, it doesn't crash. But if I try to rebuild the module tree, then it crashes.

Going to try to reproduce this in a new project.

[Orvillain]

@Orvillain @Christoph-Hart

Right, I've confirmed this. Here is a demo project. Created on Windows. Not sure if you need to recompile the networks or not.

BuilderClearTest.zip

Shared with Dropbox

Dropbox (www.dropbox.com)

If you load this, the first time all will be fine. If you then press F5 to recompile the project, it will crash. If you remove the call to setEffect() then it doesn't crash.

I get a read access violation on:

if(auto pitchChain = dynamic_cast<ModulatorChain*>(getParentProcessor(true)->getChildProcessor(ModulatorSynth::InternalChains::PitchModulation)))

Details:

Exception thrown: read access violation.
hise::Processor::getParentProcessor**(...) returned nullptr.

In this function:

void HardcodedPolyphonicFX::connectToRuntimeTargets(scriptnode::OpaqueNode& on, bool shouldAdd)

Hopefully that helps resolve the crash!

[Christoph Hart]

Hopefully that helps resolve the crash!

Nice one, it should be fixed now. I mean the builder docs says that you have to expect crashes but this is in fact a reproducable one :)

IPP

I made another attempt at this subject:

• IPP on macOS and Linux is completely gonzo. You can use FFTW on Linux and VDSP on macOS (and ARM doesn't even support IPP so that was not very useful anyways).
• The USE_IPP flag is now an internal flag and must not be set explicitely in any setting (in fact it will deliberately fail the compilation if it detects it being set from the outside). There are now only two things that determine whether IPP is used (on Windows only):

1. In order to compile HISE with IPP support, the projucer setting Exporters -> VS2022 -> Use IPP (One API) must be set to "Static Library". This is the default now so people who want to build HISE without IPP on Windows must turn this off explicitely (readme is updated to reflect this).
2. In order to compile your project with IPP, you must have compiled HISE with IPP following step 1 and then set the HISE setting Compiler Settings -> UseIpp to true. If you set this to true without HISE being compiled with IPP, it will throw an error (this is not really required but I think anything that boils down the ridiculous amount of scenarios is a good thing here). If the HISE setting UseIpp is true, it will automatically set the OneAPI setting in the autogenerated project file and subsequently set the internally used USE_IPP flag for the project compilation.