PresetBrowser

Bear with me, I somehow got mixed at multiple places and now I had to commit everything to the dev branch, but todays commit history gives serial killer vibes.

There are a few gems in there that will be documented over the span of the next days:

• complete rewrite of the profiling suite (basically a extended version of Perfetto with much tighter integration into HISE). Profile your scripts down to each line of code, quickly check the DSP tree for the worst runtime & see event dependencies across different threads (broadcaster events etc).
• complex sample group manager (the UX is still all over the place and some functions are missing but the basics are there)
• WebSocket server communication for fast data transfer between web view and HISE. Oh and the Webview should now work on Linux too - David let me know if that is the case and what needs to be done to make it REALLY work.

I tried to focus on it not breaking stuff (most of the profiling tools can be completely removed with a preprocessor flag which is disabled by default), but if something behaves nasty let me know. When it's dusted off and documented, we'll call this bad boy HISE 4.5.0...

I suggest we make these things the topics of the next HISE meetup :)

Alright everybody,

it was time to finally bump the version and upload new installers. Enjoy

Hi everybody,

I'm currently profiling a project I'm working on and noticed a rather significant optimization possibility: when there is no signal input, some FX can be suspended until a signal is detected and save some CPU. This might highly improve the idle performance of your plugin, which is important for big DAW sessions.

This is not a new idea (some DAWs implement this already) and in certain parts of the HISE codebase this is already implemented, but now I refactored it to a general system and also allow DSP networks to set the flag.

HiseSnippet 1427.3oc2X0raabCDlqrobkSbRSQP+AnG1C8fCfqgTRZZAxAKaYqTgFYK3UwMsWLn2kxhP6RtkKkrUK58donmys9Zza8Qn25w9J32f1gbWIsqzZAaE2DzJCXHNbH42Ly2LbnZIEtznHgDYUp8vPJx51XmgbU2ZcILNpwtHq6faRhTTocrncFFRhhndHKqkdlVfUokQlOWr0NDeB2kNQDBcjf4ReNKfolHsU0uh46Wm3QayBRo8iq1vUvqI7E8A7rDtLJj31ibJcehVsBXjUw87XJgzQQTzHPmcDdCc5JNiGq+QrH1I9T8fJHGXihEip0k460ZjsFgPV3VSr7khs76iax7XikOwC7tlIrmrhz9.qByCRUtFPxJEjVNFR2C63JYgpIynwysvM3P.oCAb0ogRrtHqeGWS.JvUaFP5QqKgAiWv5Oob4Mrg+8fm1oO2UwDbaAeeghd.e8Gr5OrZoU+wUsmdpNcxcN8wHE99TYtSqitx4sv048CNgJ2vd.wuOcrhf4m0mV7p4Scis5TJJ3M3L0Agzjw0E9dZek96yFAPItM3aunwtDEQGTRjA5ERkJlFNV6RG.r53PTI7tzndJQHvqmI9ALGgWeehJKcRm2jLA3OxDC0AJdDSMLcd00fiUdtbrqJDuGtES41MeLVHGLBdp+MvXRl4Z385zg5pl.vkw0e4hlFV9ZmFtZRZHbl5C+1ICsq+xJ4l.9S3Ij8PIMjHosEs7ICWOhDD5SODv3F1m3Kb64v9d5rYHgwPXGsFq61kv4T+nEIQp3MTwIzgh9JF+zlDkjcNT9b+9ANPYZWZsDzAxrJnyghGWVOVyKbnbOyf+F9jLYE8XqjIqLZxToe6SUmIj8LgijuirVI12GYbxG247Jns88EmUSDDxRXoPLvHqkveXXWAm4pEEqwHjtcfnObHIv8KIQsILeMs1oeDTnv6.tCnr4ZLqBGQkQlMdEb4Mg+.Z99BOXph0ItficXKhpqNeQW6AHmT4ltiIoYvZZdhdKFcMWrWBfXf1z0WxoiOsHR3NOnlstbSAqkRU9IlgpGA4eEhOmFQGom0k3iNRy.zKBoOkXOnAwXspqg6vN+QO7XC2CkwF9fT1PZkt5.+0ClERAy6iiBDBUWp2wgi7DYQ6GaPKP82LGMuwfbQcwQ5HvtF94f2gHsODxhQnIUGaSjmRUQIWWvotwjQiE0vSuMJBuKZbPUKaEb7thREp0vYrQXsRSFO4jmTlsI47ojcwVNJZntNRZ8b5QOK1gkVSsMM5fmYq2tuRD.0IL03Qo.Rwo.xu9pW8aaMCPp9KUmBHF8tbfbWriIzAkUL8ANEf9lpyCCWCmwEyACkv6wIPEPOzLaDJEe7tXw.H.YJdW4ImmkJ9QoRbxp1apTmzY3IbsLH7VXHt1cSyDWCLUHMlxxSslOO8hYoGnpUuQ3oWr0kvSmFiWNfKFu86JYCnna9jrwK8a8d5ecvO+maktpvkWjH2Zd4WxXGgnW.wb+3qcmp2Idxagc.Br4oel6tdeyX6ulLfZ+LJPs0MHVYNu96Otpu9K7J+5uCbUvw2VR3QghnrddZ.qsfqswIBeQD7XG52cntlbZ40DDYtScwV0AiL203PT8klh6i5WHUqtKksqpkuZcUksq+T5mSSnK+V34o2LOc3s3qaxz5doQXzgoKGuGe.0GRLLX78fLgNj99pQRyRraJ3hQcONIpeHEZ88zSoYKTkmAssRQfFmFK49UOj5SIoYveR03VILsWrX9hq+ulPtwqODGCWac1n8+ceU5R+u9UouQd+0ahyHf3JEGmz6tlm9NFIfcyM+HekvM0isqfFDeMJV+vKT.Tg6XWWsK9SgBl4ulGt.q4QKvZd7BrlOaAVySVf074KvZ9h4tF8kKIsboS4.As1yzxgk0ndmAlN5eLgWzyA

This is a simple overdrive going into a 16x oversample node. With the new SuspendOnSilence flag enabled, the CPU usage goes down to literally 0% if there is no signal present. You can try to disable the flag to check the effect (it's in the DspNetwork properties, next to the AllowCompilation and HasTail properties. The flag will be passed to the node compilation, so the HardcodedFX will inherit the behaviour of the network.

Be aware that this flag should not be used if your algorithm produces any sound from silence (eg. a test tone generator or a background noise player), because it will obviously mute the output when the input is silent.

You can also see the suspend state in the Module Tree, if a FX is suspended, it will show a S over the peak meters like this:

I've tested it rather thorougly and tried to cater in all use cases (polyphonic FX will also be suspended if the voice is not producing any sound), but please let me know if you find any issues.

There's also a preprocessor macro in the hi_dsp module (HISE_SUSPENSION_TAIL_MS) which defines the time that the processing stays active after the first silence detection (the silence detection is pretty sensitive, so it looks for a -90dB threshhold), if you prefer a different default value, let me know.

In my project it yields a ~40% CPU improvement in idle mode and ~10% CPU improvement when in usage (because some channels of the plugin are not always busy). I also improved the performance of reading the peak values of routing matrixes, so this might also be a contributing factor though...

Hi everybody,

I'm very thrilled to announce that the Faust integration is merged into the develop branch and ready to test.

The implementation of the Faust integration was a Google Summer of Code project that I was mentoring together with Stéphane Letz, @sletz from the GRAME Research Lab. The project was carried out by @etXzat which I would like to introduce with a warm welcome and I'm sure he's happy to answer some questions about the process or anything Faust related as he knows much more about the actual language than I do.

The Faust language allows you to write DSP algorithms using a very concise language. It's been around for quite some time and has a lively community of developers and a vast library of existing DSP algorithms that I know all of you are dying to play around with.

The current state of the Faust integration allows the full production cycle of using Faust within a HISE project:

• add the core.faust node
• write / import Faust code using the LLVM Jit compiler. Parameters will be parsed automatically and show up as node parameters that can be connected / modulated like any other parameter
• export faust code as C++ nodes (a DSP network with a faust node will create a C++ class from the faust node and use the C++ class instead when you export the network to the DLL)
• reload them as HardcodedFX modules or nodes in scriptnode

@etXzat has written a extensive blog post about the integration process as well as the build instructions and a quick getting started guide:

By default Faust is disabled in HISE because it requires a few non-trivial configuration steps and let's be honest, HISE isn't the most easiest software to get started with so there's no need to make it even harder...

So if you want to dive into Faust development in HISE, make sure to read the build instructions on the blog post and let us know if there are any roadblocks (we've been testing it on all three platforms the last week but I wouldn't be too surprised if we missed some build issues).

Also we would like to start the discussion on what steps should be next as there are quite a few features that we couldn't realize within the projects timeframe but hopefully will be added over the next months:

• support for MIDI and polyphony (at the moment it's only possible to use Faust for audio effects)
• enhanced IDE features (editing within HISE, SVG path diagram preview, etc).
• support for complex data communication (tables / slider packs / audio files in Faust)

I've also added a new category in the HISE forum for anything faust related, so that this topic will not explode with all kinds of different questions.

After what might be the single most offensive violation of the git flow branching model in the history of software development, I finally found the motivation to merge the develop branch back into the master branch, which had a pre-pandemic state.

Also from now on, I vow to respect the traditions of software development:

• keep the master branch stable and build at all times so it can be a valid entry point for HISE newbies.
• use the develop branch for testing new features / daily development work.
• whenever I merge the develop branch into the master branch, I'll run a CI test that ensures that it builds HISE and exports a test project on macOS / windows so that @ulrik can stop being my human build bot for macOS and notify my that I broke macOS again... I will also try to bump the version numbers with each merge to master.

I'll expect the frequency of master releases to be a few weeks to months so the general advice that David healey gave in all videos since 2019 to use the develop branch for actual development stays valid.

Oh and I've thrown in VS2022 support so you don't need to crawl the web for an ancient version of 2017 anymore...

So time went on and I simplified the build process for Faust a bit so I thought I'll post the build instructions (or the link to the instructions) here and update the post once it changes:

Windows

No Projucer modifications necessary!

• Download and install Faust to the default path (C:\Program Files\Faust). The latest version is available here: https://github.com/grame-cncm/faust/releases
• Open projects/standalone/HISE Standalone.jucer and click on Save and Open in IDE
• Change the build configuration in Visual Studio to either Debug with Faust or Release with Faust. This can be done with a drop down menu in the toolbar (which initially says Debug).
• Compile this configuration. HISE will have a text label in the top bar indicating that Faust is enabled.

macOS

See here: https://github.com/christophhart/HISE/tree/develop/tools/faust

Linux

See here:
https://resonant-bytes.de/blog/gsoc-final-submission/

Then you just need to add the directory of the Faust installation to your HISE settings under FaustPath so that it can find the Faust libraries and you're good to go.

I'll lock this topic and pin it to the top now.

What's the best way to return to coding after a vacation break? Yes, adding a fun feature that is easy on the brain cells. So here I present to you:

Code snippet templates

These extend the autocomplete items with templates of commonly used code snippets. Check out how it creates a CSS definition for a button LAF within seconds:

These are the features:

• use the stock templates that come with HISE or add your own templates in a JSON file for the ultimate customization
• use the preselect range feature to create multiple selections after inserting the template

Docs:

Have fun! Also I'm happy to accept snippets to be added to the default list, so post them if you find them useful!

Alright guys, here we go:

I tried to cover a few common edge cases, but I'm sure there's lots to discover when doing monkey testing, so let me know if you find glitches...

Hi everybody,

not sure if that feature made it to anybody's radar, but there is a quick connection mode that let's you connect parameters to your script controls with a single click and I've seen a lot of videos / screencasts which are missing out on that simple function so I'm trying to raise awareness for this awesome helper tool...

I've updated the UX to make it a bit more approachable, so now you just need to right click a component - either in the interface editor or in the script component list and choose Enable Connection Learn. Then you need to click on any parameter (either on the module editor interface or a macro parameter in a scriptnode network and it will automatically assign the UI element to control this parameter. It does this by setting all relevant properties (processorId / parameterId as well as the parameter range) so this will heavily speed up the process if you have to connect multiple elements.

@DanH long time since I touched this, but the difference is that addModulatorTarget will actually create GlobalModulator targets in the modulation slots (and for the filter frequency it will put them in either the bipolar chain or the normal one based on the properties of the matrix).

The parameter target just wiggles the knob as fast as it can do but there's no sample accurate modulation.

@ustk said in Cable broadcaster and callback not updating above 1.0:

Side question (and very basic question), why writing AsyncNotification in the CB doesn't throw an error since it is just parameter name that isn't "declared"? I am instead directly writing either false or true directly, thinking it would be better... I don't see where AsyncNotification is seen as a bool

Console.print(AsyncNotification); // 912

It's a magic number that is hardcoded in the engine and converted to the proper bool value for all functions that expect a parameter that indicates asynchronous execution. The rationale for this is code clarity - what is true in the context of synchronosity? Synchronous or asynchronous? You would always have to lookup the API call docs but with this it's super clear what is happening).

Yes the cable is supposed to send normalised signals from 0.0 to 1.0. You need to attenuate the signal before you send it through there.

On the scripting side you can then use setRange() to convert the value back to your original gain value:

const var gm = Engine.getGlobalRoutingManager();
const var gc = gm.getCable("gain");

gc.setRange(0.0, 4.0); // 4.0 = +12dB overhead
gc.registerCallback(v => Console.print(v), AsyncNotification);

@aaronventure the table is updated to show the new logic layers that you define.

The real change is in the complex group manager tab (which is part of the updated UI layout once you reset your workspace).

@d-healey ah yeah that one was bugging me too. Fixed now.

Yeah, that should cause an error / warning or hint - same with SNEX as you imagined.

Alright, this is implemented. I went for a check at initialisation and a autofix button that automatically sets the compilation flag and removes the error, this should be the best of both worlds.

@d-healey In general, yes it's good advice and recommended - if you don't need the scriptnodes to be dynamic / interpreted for reasons, then there's absolutely nothing that should hold you back from compiling them to C++.

The performance benefits range from completely neglible (eg. if you just load a convolution reverb node into a network) to complete and utter game changer (frame-based modulation).

I thought about adding some more data points to the new profiling toolkit that allows you to analyse the actual overhead that the scriptnode interpreter introduces, this way you can quantify how much performance you'll use.

Alright, then I'll just remove the entire "Replace ScriptFX with hardcoded modules" option from both the DLL compiler and the plugin export. If you want this function, it will be under Tools -> DSP tools (or whatever).

Compiling an instrument plugin with a ScriptNode Synthesiser with a network which has a Faust node

There is currently no hardcoded version of the Scriptnode Synthesiser - for a polyphonic synthesiser you can use the Silent Synth in combination with a polyphonic hardcoded FX module that loads your faust patch - this should work:

HiseSnippet 1595.3oc6X80SiaDDecfM.4350S8jtp9jEOEpno1I4.hNU0CBvUTKbQWnn6Mzh8FxJb100dCPZUeuer5Gg9QoeCZmwqShcHGjKkd8kZDgryL6NyNyu4OF9MZtzm6eVrTDFx0Dh0BshTd73XUDwpzICB4DqUosGH0ca1kIjjC2iX8IziXwZdjsgztCBYwwbehk0BuFIXsxhjjm+7a2kEvjd7wjHjSUBO9OH5Izio15UeuHH3.lO+DQuLRW+UG5ojMUAp9f8r.0gDx7tjcA+XFJVAJ46XwcIVeIsZmy8p1YqZa61vswV0a359hsOutSUO+WznVsMq42o51rM2F1Tw88EZUTaMSyigCcWk+f1cUWKMJ3TQr37.NtvkzFzrgLoYWQf+HmSL3pnYbUKXbUOidjvWLh9XW1mlvvd7Nx5zrJbWlj6GfIYkwjVzXROk11KRDpGyAsmGQOTBQvNLH1j0TLxRr9cZSEHfTWoG6R9AQvhQan7lNNaXCer9K6zW5oEJosRdrRyeir75k9kRqT5WKYOIqNclJOTMQpf.dzTYivgn6Zikk86cNOZC6qXA84iDDt948oEmMepm4VmQPk7PoP+lPd55CTA9nuB+9si.jT2F7se7v8XZFFTRoAxExizBzbr1ieEjFXBQqP2iGeoVEBIB2J9AHGke+.lNObBSzRY.9ibwPLPIiE5AYSD+.vXN2IFaVMwmRaIzdcmtMVXJ1H3o92vFSyLeLc+Nc3d5wF3hzCd27lFN6pe4gpusH.AVXkzD0+jTJ1Ijbuipn+wrVEMblqhZsvCUEmE+OnH3CC.8txgJ7uaNTt5zEM13ySqSKU97jfKFK4lp0eQFd1ILsMbyCaNRIUgcURgWVjxa45HwEW.GUFh+Suet+eMhGPHPpOpTZXFzIp7USWZev6bmZS5eiNtgXXDOjEwOQ0JfMnbLqWX.+sfMtg84AJuKaK9Y9s6hFZLgcQIJ60kIk7f34oYawGJfyaU80B4EGw.L6MvHVG2uWanpkGuYp0AzrJf8YMqcv0HtnMLHaxh+BdRY5hqsRY5NjYlVzGy0WqhtLIbj9ch0Rnu+4zPUv.SxzYwI96y5biKYmf.00MU8BEo.1jqTB0Vi1P5klGEmHwRTmJvODy1FdS1ompOXDoWGXL1SXh.D12teLLrg+ajI8Gvp9Hr6XH0G7yGv7.+7fVLnKBj9fiq.XUdTEuQX12moOFAg9dy.zuOYQsMregw+BFeOzogybas.xG8ZKjZVndWh1g0OVSxYhqBlXDuhgyzrfg659zXlgm.JoqfJCEPUuBsY.bxG5SNEAlvIPUwdIo3YE6IHbpEKBTLLJa7PgSfhYHi4lCWA2siDxTAKRqhwwiX2jRXEf.7.zZq4gXNF18yohqi4wsdCGW2McShKEoch3+zPktDsZxgsGGt+A5InRZeMVX7DVzEbMlWjwO+HZr.ytOiEk2W+LJWdEO.txUFKwz74YOg6wuSy42slMGpARO4c.P1YHjNWrjmThIdBwuE2rKIlrAHZCFvUX2vy5wjLrC2HaAYtJEaRZ5Wlbsfq7MCmIeOQbHTob29PEeSLOGE7BBuY7MXKfuxkrOT1yGF6OY2niIOdYwL3kkFiWnz7vkkotyDZo8k7qMQVi.0bbcpABznw10arkiANsLcGsFdY3gN8Oit41UpmbNNtMpVqQ8ZS.tJBpuRVn9GOicE5a4AbVLmj2VtWCr362.oT2bVmYsIS60PeHRt8kWSFZYUD89TDdvON0m2rezUyx4OdvlolIOI5MW17mONaNuTSKidxS5dxpKLKU6lc+ctDsIcDnP6zWq5Agjjw5HYKojKOhbmEaVkdX7oHWOVvPeObZ6pTW1ikzDe9dk6OFib7wPG8XdQpy7LSpgNvkSn.vDYBFYE5Q3ZaWxUocuFMTcO30xNyyK+QcqMVcd2Xs4ci0m2M9h4ciaNuabq4ciae+aDeq4zTHr8GTWo09lNQV6KYvf0IuU.gm1jx75AX9vHJR9MG.SSljV0QfShW.+iLs3QxHXeMLxTE+3vg+OvHVRJLlfJRWdsXsehLUBDmu15urTIbTF6uwtabfvmGUdMb8ZaXCSu.ej7qC9OID5W.Rm9ZFf7p3JfVJiRu9F4V8xRDxeCHTXu3C

If Allow Compilation was not enabled, the plugin with a Faust node will compile fine but won't work

Yeah, that should cause an error / warning or hint - same with SNEX as you imagined. I'm not 100% sure what the best UX would be - the most friction-less option would be to just set the flag automatically as soon as you add a SNEX or faust node to a network, but then people will complain about this just as they do with the automatic FX replacement function.

@d-healey that's right, envelopes and other modulators are not processed on the channel level so you get a single modulation signal for every voice so even with polyphonic channel routing you would still be limited by this design.

You'll probably need to look for another way to achieve this, but usually once you apply different modulation sources to voices it's time to duplicate the samplers.

Let's also please not forget that Networks with Clones can't compile.

Just checked, works here, however the compilation with clones is a bit more delicate than usual as it performs a few additional sanity checks and the results of those were not being displayed as error message when they fail (which I've fixed now).

In my test case there was a mismatch between the parameter range of the clone_cable's NumVoices and the clone container's NumVoices parameter and apparently this makes HISE go boom.

After fixing the error manually in the network the compilation goes through and I can load in the cloned network in a master FX.