@ustk the fillPath thing on the profiler isn't the time it takes to encode and decode the path to base64 then do all the overhead in C++ in the CSS engine (that's probably all tucked away under the paintRoutine graph, that's just the function passing on the path data to the GPU which is just a memcpy operation and should be very fast.
but drawDropShadowFromPath isn't using melatonin yet, no?
@ustk you can try if the overhead of passing a dynamic path exceeds the blur render performance but my guess would be that its faster.
@musicayciencia globals are used when you need to share data between script processors - although David correctly suggests that this should be the last tool you pick for that as there are way better ways for cross-module communication by now. The callback of a single script processor share all the variables declared in the onInit callback.
Now about the non-deterministic issue: if you compile that script it won't cause an error, as the JS compiler cannot know whether the variable setGlobalVariable is a function that can be called - it might get assigned to something callable at some point so it stays put and doesn't complain. However when you play a note, then it's time to call this variable and that's where HISE realises that you can't execute the (empty) variable.
var callableAtSecondTime = undefined;
function onNoteOn()
{
callableAtSecondTime();
}
function onNoteOff()
{
callableAtSecondTime = function()
{
Console.print("Now I work");
};
}
This script will throw an error when you press the first note, but the first note off will then assign a function to the variable so subsequent notes will not raise the error but call the function. That example looks weird, but it's one of the more powerful features of JS (and HiseScript) to be able to reassign function slots to different functions like this so you can implement dynamic logic more easily.
Yes webview for adding shadows is definitely the wrong direction, it basically replaces your entire interface (or at least a rectangle of it) by a web browser.
The problem why melatonin blur hasn't been integrated into the Graphics API calls yet is because there were some inconsistencies with the API parameters with what melatonin expects and before breaking the API call surface I just decided to use it in CSS where there is no issue with backwards compatibility, but maybe now it's time to rethink that and (at least) put it behind a preprocessor like we always do when deprecating stuff.
The melatonin blur is a marvelous piece of engineering, but it still renders the shadows on the CPU so it still is super slow compared to a solution that just gives the GPU the instruction to blur something with its millions of shader units. Unfortunately this is the one hard restriction that comes with using JUCE as underlying GUI framework.
I would also recommend starting to play around with the CSS LAF stuff to get a feel for the performance of melatonin - start with buttons, these are best suited for CSS LAF. Sliders / Knobs are a bit quirky because you need to abuse the pseudo element classes to render different parts of the knob (eg. the track, the arc, the thumb).
const var laf = Content.createLocalLookAndFeel();
laf.setInlineStyleSheet("
button
{
background: #666;
color: white;
margin: 5px;
border-radius: 3px;
box-shadow: 0px 2px 3px black;
}
button:hover
{
background: #999;
transition: background-color 0.1s;
}
button:active
{
transform: translate(0px, 2px);
}
");
Content.getComponent("Button1").setLocalLookAndFeel(laf);
Powershell, paste this:
irm https://github.com/christophhart/hise-cli/releases/latest/download/hise-cli-setup.exe -OutFile $env:TEMP\hise-cli-setup.exe
& $env:TEMP\hise-cli-setup.exe /VERYSILENT /NORESTART
then start the hise-cli and type in /setup, wait 20 minutes and everything is setup. It will install MSVC, IPP, Faust and clone the HISE repo and all its submodules completely automated.
You're trying to build the Faust build without having installed Faust. Select another Scheme to build that doesn't include Faust (or use the hise-cli for setting this all up).
With the mod matrix system each connection can have a intensity and you should also be able to set it programmatically without the matrix floating tile using the API.
For targets that dont expose a mod chain you can just define a UI knob and give it a matrixTargetId. You‘ll loose the precision of the real mods but if it‘s acceptable then fine.
The modwheel could also be a global source modulator using a control modulator.
@observantsound Use the matrix, you can add / remove connections with API calls that you can hook to combobox callbacks, the matrix / drag stuff is just a readymade solution for the most common synth UX stuff.
https://docs.hise.audio/scripting/scripting-api/scriptmodulationmatrix/index.html#connect
@David-Healey That's fixed now, it now respects the scope of anonymous functions within a namespace like this.
@David-Healey ah yes that's a bit more complicated - the resolver for the first namespace doesn't work so it basically ignores the namespace qualifier and resolves the function call to itself so it creates a recursive loop.
In order to reproduce the faulty behavior without the crash you can do this:
namespace FirstNameSpace
{
const var myFunc2 = 90;
}
namespace SecondNameSpace
{
inline function myFunc()
{
if (isDefined(FirstNameSpace.myFunc))
{
Console.print("exists");
}
else
{
Console.print("doesn't exist");
}
}
}
SecondNameSpace.myFunc();
The suggested fix of passing in the current namespace is not a real fix, it might solve your immediate problem, but the correct option would be to return an undefined expression like this:
match(TokenTypes::identifier);
return parseSuffixes(new Expression(location));
then this code would work as expected (returning "doesn't exist"). However this might silently break existing code that used this construct to falsely refer to non-namespaces data through a namespace qualifier so I'm a bit hesitant to push this.
@HISEnberg why? just use JUCE 6 the reason to switch to JUCE 8 are almost non existent
@David-Healey ah so basically Namespace.nonexistingProperty crashes?
@HISEnberg fftw isn‘t supported yet but the hise-cli should be able to one shot the entire dev setup including faust on macOS and Windows.
@David-Healey normal functions are var declarations in disguise and previously leaked to the global namespace without warning - that‘s one of the reasons why I added the yellow warning stuff
@David-Healey hmm a namespace can contain only const regs or inline functions…
@David-Healey you can specify the file in the onInit callback so for rhapsody it should work if the developer keeps it tidy
Worked on this today:
https://github.com/christophhart/HISE/commit/528ccf712722db6bb213470e40a0b4cb47f9775b
I didn't use any preprocessors but a dynamic API call - there's no need for this to be a compile-time setting.
You can define for each of macros, midi & mpe assignments whether they should be stored externally, in the user preset or in the plugin state.
Docs:
@slayabouts rebuild the scriptnode dll then it should work
Each heavyweight function (loading presets, samples, etc) gracefully fades out the audio, suspends the processing and then resumes audio processing. This is a core engine behaviour and you can't do anything about it. Changing this will create audio glitches, incontinuities and crashes.
@dannytaurus said in Saving MIDI CC assignments in user presets?:
Personally, I don't need to distinguish between a DAW session reload and a preset load. I just want no MIDI CC data saved to, or loaded from, user presets.
Of course you need to distinguish between a DAW session and a user preset, you want the CC assignments to be retained when loading a DAW project, no?
It's pretty simple: the data model that drives the plugin state MUST include the CC assignments. If you want you can strip it out of the user preset system with the script callbacks (or you can hack around in your local source code but there's no chance of this making it upstream).