@d-healey Ah, apologies, I meant spectral morphing with Loris in HISE realtime, not realtime spectral morphing in general!

This plugin really caught my attention when it came out, though I am not sure it is completely spectral morphing or some other way of interpolating between samples:

Visco – Forever 89

(forever89.studio)

Also great meeting and many applause to @Christoph-Hart for his work on the new sampler engine and profiling tools, both of which look extremely promising.

@d-healey I somewhat take back what I said. I don't think you could do spectral morphing in realtime. Loris can definitely do spectral morphing and very well at that, but I think you would have to render your samples offline then bring those into HISE.

@Allen oh true, the GOT book is a really good recommendation for navigating wavetables in max, and you can bring a lot of this into RNBO and Hise

@Straticah I think it should but I really know little to nothing about SNEX..

With RNBO you can import buffers and possibly use a sliderpack or table to edit them, so this seems like the lowest resistance option for you.

@Straticah Sounds like you would need a custom C++ node to do this.

@Oli-Ullmann I have this working without firing issues, and it worked well with the fadeComponent. I think I am having general issues with the fadeComponent on other systems so I am actively removing, but it did work on the compiled plugin (at least on my systems)

const var lbl_Tooltip = Content.getComponent("lbl_Tooltip");


// Broadcaster definition
const var Bc_Tooltip = Engine.createBroadcaster({
  "id": "Bc_Tooltip",
  "args": ["component", "event"],
  "tags": [],
  "colour": 2432630784
});

// attach to event Type
Bc_Tooltip.attachToComponentMouseEvents(Components, "Clicks & Hover", "");


// add listeners
var lastTooltipText = "";
Bc_Tooltip.addListener("Tooltip Listenet", "Set tooltip", function(component, event)
{
    if (event.hover)
    {
        var tooltipText = component.get("tooltip");

        lbl_Tooltip.set("text", tooltipText);
        lbl_Tooltip.fadeComponent(true, 200);
        lastTooltipText = tooltipText;
    }
    else
    {
        lbl_Tooltip.fadeComponent(false, 200);
    }
});

@Lindon Simple example for you

HiseSnippet 1144.3ocsV0sSiaDEdLfWswsKpH0GfQzaBHB3PRXoAUUVBj1nEXQanq5cqlXONdDSlwZ73MDUsuC8UouT85deufdFONwI.hcIR0QIJm++l47muRICnooRExw65IITjy251ehPG2IlvDndmhbV28BRplpvVVmLIgjlRCQNNq9KFFNUVCk+7O+7IDNQDPKYgPePxBnmyFwzkbu532x37tjP50rQyocyi6EHEcjbYFfmUc8QIjfaHCoWRLpshK5WIowHmscOH3Ga4Of52p0gMabXylGz7fV9Q9MhFb3AMGz30MaD1rU8fFHmWbVHSKU80DMMEb5IxvI8ikiE1.7AVJa.mZHpi5CQ1xF0IlwCuZ5kSJB4r1UkWUqZup9d2KXgrY7Kux9tbA3RKl+RyYkmBR0eFPxYNHslERa31OPwRzkRL34ab6IfLXDAxMyCEqtnU96Uc6HAMD5cGQtg1UADyrn59996fa4u0QddP5IUi+DQgOmLfxqi+I7TCGR0cjiRjBfn5lVwatnM7A7NooyYSfhB2AmKCH7ykxadiHrKkxqZrx5fcSofyzza0atCdyN86aiate81aO7YiHL9dukNwxG9MxyFEik8Dblf1WOgS6GSMdxaau+vqBmpgyVsTn5hIF1FuexsG4UIB.UswT1vXcarhNLiSTG48YHNauM98TQHzBnio3PZDIiqwjjDJQYp22Eu8ddbC.Lde.TyNTIyDg0Bfrmps4rWsVsACsU1.1qrf.ywapnJf8REDpZJRHKKsMtUN3RHgg.VqwoQ.5Z4u.SkEy6a4ZbWszXRnbb9QK+K3ErZ3.RU+cx+raislc15EgmHyvTnpL+.ZbvNXfXLzkhyRANwrTbJkSCf517SKSjjogSaQ3Hb1PQarAcygKsLoM1e2m8IHfnn5oWdiiYZ58SOCj7vY3OOAOC4E3jIE.90wOB1a2dlJKluZi+gV9cyeJyQEw+ydatXY4CpZs0cfRQYBa7khKkZ56DU2xDGvE36KJJ5QkY5OTRNmpdTwlolpmxvphrQCnpcfBLdFclhvThEG87hutQOA1104TTJ5IX52kPKn6B4CyHEy+e3fJTQ+N7ueq2oDMwL6pfGnWBUoYF33bJ8Sv1B6jrJtmRSuAJgx0sXvBLJSmK8UEy4xyGHFD5W5ZyMname8yj4IFyB0wkLXGGmWNUxo2wlJHy7xYiZPSaaAsdwedM5tbK0zQkbWe8+5db22vdiM13eMrKauMbAF2YWB9fY2vVCYHL0Qu3pDyR1BAPRdg42lYzhTldx7KgeF6W7ex8KesPbC2qX5f3GGiq7HXDR++efwhsxux8rnHn8tDfq4182W1Uvegv+dYlFFfcAQqXPgm6kYi5CY5.JDcgfxAm65rhoEvR6anM2.8gEJ4D2AOEBqancJDVepPzHRfR9w.aqsYu+Ky4.XRj+dQUfWPCnw0Q4s6yeOOBdMjOFDrnqdfg6urF1XYMr4xZXqk0vCVVCe8xZ3geYCMuk3axzxQ11FD5hqNKe9niyYBBTAlWsh9O.TjCSqC

Content.makeFrontInterface(200, 50);

const var Label1 = Content.getComponent("Label1");

const var lblCss = Content.createLocalLookAndFeel();

Label1.set("text", "CSS Label");


// Email/Key Label Laf
lblCss.setInlineStyleSheet("
*
{
	letter-spacing: 2px;
	font-weight: regular;
}

/** Render the default appearance. */
label
{
	background-color: var(--bgColour);
	color: var(--textColour);	
	border-radius: 5px;
	padding-left: 50px;
	padding-right: 20px;
	text-shadow: 2px 2px 5px rgba(0,0,0,0.3);
}

/** If you edit the text, it will use this selector. */
input
{

	text-align: left;
	padding-top: 0.5px;
	padding-left: 50px;
	padding-right: 20px;
	caret-color: white;
	font-weight: bold;
}

/** Style the text selection with this selector. */
::selection
{
	background: #50FFFFFF;
	color: white;
}
");

Label1.setLocalLookAndFeel(lblCss);

@Lindon CSS works on the label, and quite nicely I might add!

@elemen8t Thanks for sharing.

Perhaps you could leverage Settings.isOpenGLEnabled() to broadcast whether it is "enabled" or not:
https://docs.hise.dev/scripting/scripting-api/settings/index.html#isopenglenabled

I would like to hear @Christoph-Hart 's opinion on this as I wonder myself sometimes. What is the proper procedure for setting OpenGL up?

I searched the docs for what's available but I don't see a clear way for enabling it and allowing users to enable/disable.

HISE | Docs

(docs.hise.dev)

First off great discussion and thanks for all your input, it’s giving me a better sense on how I might debug this issue and future challenges. In answer to your questions:

1. @orange Yes I have Synth.deferCallbacks(true); set already.
2. No blur’s or drop shadows (I've learned my lesson). Most of the graphics (background, buttons) are done in png, but the sliders are simple LAF and the animations use panels drawing paths. I do use gradients for filling some of these so that may be room for concern (I will try removing these next)
3. @aaronventure thanks for all of your input. I have run Perfetto a few times on Windows and on Mac. The bulk of any CPU or GPU consumption are from the UI timer callback. Individually they seem negligible but I suppose it’s the frequency they are called and causing repaints which must be the issue. Are you suggesting to just create 1 panel to host all repaints and divide it into separate sections "put all your fancy plots onto one panel and draw it there".

4. @Christoph-Hart pray tell what Threads.startProfiling() is! I've used Perfetto as well as the VIsual Studio debugging tools but I haven't seen any abnormal behaviour.

5. @clevername27 you said you have numerous timers, animations, shadrs, etc. Does the performance transfer across different OS?

6. DAWs generally: It seems like a majority of reports are Ableton and Logic. I am generally an Albeotn user and I haven't had many issues on my M2 with it, but I do recall serious UI lags in the past on my Windows (pre-2024). There are a couple of posts on the JUCE forum regarding this: https://forum.juce.com/t/plug-in-ui-doesnt-work-on-certain-versions-of-ableton-live-12-windows/62563 & https://forum.juce.com/t/juce-plugins-cause-poor-daw-ui-performance-on-windows/55034
   However, in this particular case it doesn't seem to be DAW specific.

I've done everything I could to account for reports of lag on my UI. The reports are very inconsistent, a majority come from Windows users and it happens in various DAWs (Ableton, Logic, Cubase). However I am getting enough reports that I can't overlook the issue.

The Project

• The main things to know about this project is its a sidechain/saturator based FX unit.
• It is basically just one really massive scriptnode network.
• It contains about 10 saturation algorithms as custom C++ nodes (generally quite low CPU expense).

The User Interface

• It contains numerous animations/visualizers (~13) that are using buffers within the scriptnode network to display on the front UI. These include a few FFTs, 2 oscilloscopes, a few peak nodes (for sidechain display), 1 VU Meter, and 2 global cables for modulating a knob. Only a little over half of these animations are ever active at one time.
• OpenGL: I tried with it both disabled and enabled. I also set it to be a user specified option, but this doesn't seem to help (as far as I can tell).

The Scripts

• The scripts are compartmentalized and in namespaces.
• The majority of the animations are done with some type of combination of buffers and panel paint routines
• Almost all of them run on the same timer. I tested a few different methods here like using different timers at different time intervals, as well as dynamically adjusting the framrate based on CPU load. None of these were optimal.
• Broadcasters: I may have abused the broadcasters a bit since I am using one to fire off a custom tooltip, and another to display slider values.
• fadeComponent: I use this in a few places, is this a known source of UI lag? It actually seems to work well in the compiled plugin though it is a bit buggy still within HISE.

My attempted solutions

• My recent efforts included adding a "graphics panel" which would allow users to disable animations until none were active. This also stops their processing within the hardcoded module as well as stopping their repaints and visibilities. It should stop the callbacks from firing based on the timer as well but I need to double check this still.
• I have reduced the buffer sizes.

So I am struggling figuring out the root of the issue, particularly as I have not been able to reproduce the issue on either my Windows or Mac OS'. Now I am starting to think the issue might not even be within the graphics processing. The audio thread doesn't seem to be under a lot of stress from what I have seen in Perfetto. I still need to update to the new HISE to really benefit from the new profiling tools, but if anyone has ideas I am all ears at this point.

P.S. just a side note which has me suspicious. My scriptnode is truly huge and bogs down the HISE UI a lot. This doesn't get processed in the compiled plugin however correct? It's possible that all the nodes I use are adding up to a lot of CPU consumption, but this shouldn't be reflected in the UI in anyway?

@Gab You need to refernce the Hardcoded Master Fx as an effect slot (Right click and select "Create SlotFX reference")

const var Fx1 = Synth.getSlotFX("HardcodedMasterFX1");
Fx1.setEffect("MyDspNetwork"); // Name of your DspNetwork.xml file

@clevername27

Thanks, just a few things I noticed to get it working:

1. Set the HISE_USE_OPENGL_FOR_PLUGIN=1 in the Extra Preprocessor Definitions of JUCE, rebuild HISE.
2. Set the HISE_USE_OPENGL_FOR_PLUGIN=1 in the Project Settings of HISE.
3. Set Settings.setEnableOpenGL(true) in the script and set Enable OpenGL in the Project Settings
4. Then you can use the Custom Settings Floating Tile within the plugin dynamically to set OpenGL.

This was my process though I wish I did opt for my own button/panel as I hate the custom settings LAF. Definitely some redundancy here but at least this works!

@aaronventure Thanks for the feedback it is appreciated!

I ran a test with a sidechain saturator/compressor I am working on. It is not wrapped in any fix or frame block. I noticed a 32 sample delay at the output. I think other nodes might introduce latency other than just delay nodes (perhaps the limiter and the send and receive nodes)

A general inquiry on how best to optimize a Scriptnode network. Perhaps a more seasoned user can answer some of these questions. My hope is this could lead into a discussion around "Scriptnode: Best Practices" but my primary focus is on latency here.

• What is the default block size in Scriptnode if I do not wrap my network in a container_fix_block or other container type (frame, oversampling)? My gut feeling is it is processed in chunks of 32 or 64 samples. Does anyone know where in the HISE source code this is set?

• How to measure the latency introduced by my Scriptnode network? I imagine driving an impulse through the plugin and recording the output should reveal this (for a DAW specific context). Is this something Plugin Doctor can measure, or does someone have a better methodology?

• How to compensate for latency introduced by the Scriptnode network? I see in the API Engine.setLatencySamples, but it is unclear to me what it does. Are we meant to measure the latency of the scriptnode network (for example 32 samples) and this function will broadcast to the host the latency introduced by the plugin (i.e. "this plugin introduces 32 samples of latency, so compensate for that")? What does the host actually do with this information?

• Dynamic block size. If I want the user to be able to set a dynamic blocksize (using the dynamic_blocksize container, I imagine I want to dynamically set the Engine.setLatencySamples as well.

@aaronventure Hmm also the plugin needs to be restarted according to the documentation, so it wouldn't be possible for a user to do this on their end:

HISE | Docs

(docs.hise.dev)

@clevername27 Yea I am super confused where to set this flag. It exists in Projucer, then in the HISE settings. There is the Custom Settings FloatingTile which allows you to dynamically set OpenGL, but this doesn't work, and there is the script callback as well. What is the proper procedure here, just use a script callback and communicate directly to the AppData folder?

@aaronventure Thanks for the tip. I learned several months ago to avoid using blur in HISE when I can, so no my project doesn't make use of them.

I never did a deep dive into Perfetto before but I am seeing the huge advantages of it now! I am seeing that if I disable the OpenGL flag that the performance is actually improving significantly. Basically I am drawing these FFTs with a path and a timer. I am seeing OpenGL adding some extra overhead on my paint/repaint operations (almost double on average duration).

I wish I had Ventura to test on but I am hopeful this will solve my issues!

I am getting reports from some users on Ventura that the UI of my plugin has a lot of lag. I realized I forgot to disable the OpenGL flag when compiling, but other than that is this a known issue? I have three FFTs displays running at the same time (5 in total in the project, though I made sure to disable 2 of them when they are not used). I suspect these are the culprit but has anyone experienced this issue and have advice?