Posts made by Christoph Hart

@ustk said in Scriptnode graph new feature, am I dreaming...:

I try to compile on mac almost at every commit you've made since I've seen some mac compile fixes lately but with no luck

Oh OK, I'll check it on macOS then. It compiled last week so the changes I made since then shouldn't be to hard to fix.

No, it involves allocation and object creation and is undoable, so it's not safe to use in a slider callback that might be automated...

100% alpha, but it compiles (at least on Windows and macOS, but Linux should be fine too) and you can play around with it.

Will be in a short time when I commit the changes from the weekend...

Alright, here's my go at it:

1. Click on the "probe" icon
2. Select all parameters (it will show the icon next to all enabled parameters).
3. Click on the icon again, it will open a JSON object with all selected parameters
4. Modify the values (or paste in a precomputed list). It allows JS expressions, so you can use variables & function calls (it's plain Javascript though, no HiseScript)
5. Press F5 in order to apply this.

The function is also available as scripting call DspNetwork.setParameterDataFromJSON() so it can be used to create an internal preset system.

There's no artificial limit (it throws an assertion for impulses > 20 seconds, but that's just in debug mode), so the limit is your CPU.

Yes, that's a reasonable request. It's actually pretty easy to do, so maybe someone else can implement it:

1. fetch a reference to the main controller and dynamic_cast it to AudioProcessorDriver
2. call driver->setGlobalScaleFactor(scaleFactor, sendNotification); (the last parameter is important to that it sends a message to the UI to resize).
3. Add a API call Engine.setZoomLevel(double scaleFactor) (it's a bit inconsistent to the C++ naming, but it matches the Engine.getZoomLevel() call).

EDIT: Oh and if you want to disable the 85% scaling, just remove the condition here:

https://github.com/christophhart/HISE/blob/8ef678ec2fcae0973cc269163404b1f9df967733/hi_frontend/frontend/FrontendProcessorEditor.cpp#L156

If the user's screen is smaller than the UI height at 100% (minus the OS toolbar) it defaults to 85% so that the interface is not capped.

You‘ll notice as soon as you look on the CPU meter...

Nope, impossible. You need to recalculate the impulse response and feed the new impulse to the engine, that's why it's muted.

No it's actually a good idea. I would implement it through a "learn mode" that once you enable it it will add all parameters that you touch to that list.

Setting values programatically (like precomputed values) is best achieved through the scripting layer - it's called scriptnode for a reason

builder.create<ModulatorSynthChain>(parent, raw::IDs::Chains::Direct);

FFTW is only an option if you publish your work under the GPL3 license (also if you have IPP available you won't see any performance benefit).

1 - value

Just use a timevariant modulator in the macro chain and connect it to the lfo in the global container

Most of the time you can just use one LFO as Global Modulator and connect this to your UI.

Yes, definitely Open GL. The black screen happens with a few old graphic cards (or if people use a slave PC without a monitor attached).

The fix is to edit the GeneralSettings.xml file manually to disable OpenGL.

Whats the problem with ryzen? I can imagine that the ipp routines will be a bit slower but apart from that everything should run just fine...

I think you can go as low as you want with the core.fix_delay node, however the problem is that the delay time is in milliseconds and not samples.