PresetBrowser
Christoph Hart
@Christoph Hart
Best posts made by Christoph Hart
-
New Feature: SuspendOnSilence
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 theAllowCompilation
andHasTail
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...
-
Who is back? The master branch is back.
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...
-
Faust is here...
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:
https://resonant-bytes.de/blog/gsoc-final-submission/
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.
- add the
-
RE: Ability to move sampler / synth / container modules around
Alright guys, here we go:
https://github.com/christophhart/HISE/commit/888851ed2353eec4684cd94ea0d5db5d2dae84ff
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...
-
The definitive feature request & bug fix roadmap
Hi everybody,
this thread is the next attempt of organizing bug reports & feature requests. In order to keep it clean, I would suggest a few rules:
- Every post must be a distinctive bug report / feature request. If you want to emphasize a request / feature, upvote it or downvote it if you think it's a bad idea (but please do not downvote other stuff in order to bump your personal favorite). Any discussion about a certain bug / feature should be a dedicated thread (you can add a link to the discussion thread in the post).
- When I find the time to implement it, I'll sort the list in my head based on the number of upvotes and feasibility. If it's implemented, I'll edit the post with a link to the commit and strike it through.
- A feature request that is not feasible or not popular enough (number of upvotes less than ~5) will be removed after a grace period of a few days, so anything that survives this process can be considered to be implemented at some point. If you find your post to be deleted, please do not repost it.
Normally I don't to any redacting / moderating, but in this thread I try to keep it clean, so don't take it personally if I delete any post in here that violates the rules above.
-
Updated Build instructions
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.
- Download and install Faust to the default path (
-
RE: Feature Request: bind save xml to ctrl + s
OK everybody, vote is out: upvote this if you want ctrl+S to save the XML, downvote to leave it like that.
-
RE: Scriptnode is fun!
Alright, I'm currently trying to improve the user friendliness of the export process to make it even more fun. Let's be honest, HISE will never win the "Most easiest app to use"-award, but this is ridiculous even for my low standards :)
So this is what I've done so far:
- You don't need the snex_workbench anymore to compile the networks - there's a item in the Export menu in HISE that opens the same dialogue. It requires you to have at least one DSP network in your signal chain when exporting, but there's an error message that will tell you this.
- There's a command-line option to do that process, so you can call
HISE.exe compile_networks -c:Debug
and it should do everything for you. - It will show which nodes are about to be compiled in the export dialog. After the compilation, you can query the state of the loaded DLL with Tools -> Show DSP Network DLL Info.
- You should not rely on the workbench like @dustbro suggested anymore - if you choose "Create a network file" in the scriptnode welcome screen, it should create a file-based network that you can export as DLL (just remember to save the network using the save button before hitting the DLL export).
- I am currently writing unit tests for scriptnode in this repository. This includes also a few test nodes that are compiled and tested against the interpreted node. All the nodes here are supposed to be compileable on macOS and Windows (at least with my setup). If you encounter a DspNetwork that throws a compilation error (or crashes on loading), please post it as issue in this repo, then I will create a test file from it and make sure that it works.
Latest posts made by Christoph Hart
-
RE: Do I need to install xcpretty to work with HISE on MacOS?
xcpretty is just used to pipe the super verbose build output into something more readable and provides no further functionality at all.
This being said I don‘t care too much about those security warnings - if I was writing a software that does online banking I would make sure that there are no issues like this but a potential buffer overflow in a console text processor will not cause any harm and I can see no scenario where this could become even remotely concerning.
-
RE: Juce 8 questions
@Dan-Korneff actually it will create a problem for Maize Sampler and Romplur as they are JUCE based and produce binaries. HISE is fine because anyone who sells proprietary HISE plugins needs a JUCE license anyway, so from a legal standpoint HISE is just a glorified build script here.
But I'm almost 100% positive that they will backroll the announcement to some degrees, too bad they don't have a Unity CEO they can fire for this...
-
RE: Juce 8 questions
@Christoph-Hart Hmm I keep reading about the license changes - they can come with a significant increase in cost depending on the company structure (if you have multiple people working on non-code related parts of the project like UI design or preset building, all of them need a separate JUCE license which might stack up pretty quick). I have absolutely no problem paying the 10-20% more for the actual license price increase, but I know of project team setups where you would need 5 - 10 licenses where before one or two licenses were fine and this is way to steep for the upgrade.
Let's wait a bit until the dust has settled here as I can imagine this will cause some discussions and the JUCE team was always pretty open to feedback and changing their terms).
-
RE: Juce 8 questions
@bendurso yup, usually I'm 1-2 years behind with the JUCE version and you can expect JUCE 9 to not drop before 2026 (my ETA).
Also there are discounts for upgrading the perpetual license (I think 30%, so that also favors the perpetual license).
-
RE: Juce 8 questions
@bendurso yes I'm actually waiting for the official JUCE 8 release - there are some nice things in there (vsynced animation timers, Direct2D renderer etc).
-
RE: Github Actions CLI builds?
@d-healey Oops I overread that it was about compiling the DSP networks. Back to bashing the docs then I guess :)
On the other hand you might get away without compiling the networks in the build process - when it loads a project and can't find the project DLL (like it would in the command line build process of the actual plugin), it will still create a placeholder and then export it correctly (assuming that you've checked in the C++ node for the codes in the AdditionalSourceCode repository).
-
RE: Github Actions CLI builds?
@oskarsh I know we all love a good bashing of the docs but there‘s a section in the glossary about it:
-
RE: HISE Changes and additions...
@clevername27 sure just click on the peak meter on the top right.
-
RE: Panel Animation Lag on Intel Mac
@aaronventure yup making a blurry modal dialog background was also my intention but the performance is in fact so bad that I ditched the usage of the blur.
At the current state it‘s completely worthless for anything bigger than 100x100px.
The melatonin blur is also on the CPU so while it’s much better optimises it will still not come anywhere close what you can expect when utilizing the GPU and there is currently no way to do a GPU based blur within the JUCE graphics.
-
RE: Panel Animation Lag on Intel Mac
@obolig are you using the blur function for the „glass effect“?