@d-healey Hi Dave, thanks for answering. Yes, I have. I don't remember changing anything in my code…but I must have changed something?

Maybe I'm missing something obvious? The images I am loading via scripting are no longer found in the compiled plugin. I'm not sure what I might have changed? It's just…

{PROJECT_FOLDER}inst_ambiguousInstrument.png

Thanks.

RESOLUTION: For anyone having the same issue—in this case, it was because I switched my default file compressor from the macOS native one to Keka. And when Keka decompresses, it resets file permissions. The source code I was working on had been temporarily backed up into an archive while I experimented, and then extracted for me to implement the changes. With some of the file permissions reset, some of the files couldn't be read. And HISE crashed. A lot. Manually reseting the file permissions fixed the issues.

ScriptNode Clone Nodes don't compile. Verified with other developers.

@Orvillain I think @Christoph-Hart is simply being kind in opening it up for people who don't know the bug-reporting system, and also allowing for public commentary here on the forum.

@d-healey Right, I forgot - sorry. Phorsphoricons looks really cool - thanks for the tip.

@Christoph-Hart Things working better > backwards compatibility. Reduce complexity. Don't introduce new API calls to get around other issues.

@Christoph-Hart All caching, that can result in incorrect data, should be disablable with a single flag. (Also, "disablable" is not a word, but also not a HISE issue.)

There is no functional SAVE command in HISE, and the menu items are confusing. (Workflows can have bugs.)

Breakpoints don't work. HISE can crash by enabling them. They don't need to be fixed, but if not, should be removed from the UI.

@aaronventure said in The big bug tier list:

This is annoying for anyone who doesn't read the docs THOROUGHLY or read the forum properly, but the workaround is easy: simply enable the queue. Perhaps it should be enabled by default for mouse broadcasters that aren't realtime?

Not just this, but all the issues in HISE like this. Reliability and API Logic, first. Performance, second. The API should respond as it implies, and be generalised as such. I realise that HISE only works its magic because of many (very clever, and hard-fought) hand-optimisations, and doing the first has implications for the second that I do not know.

@Christoph-Hart

posts that get no upvote are deleted after some time so that we can ensure that it's only the heavy hitters in this topic.

Respectfully, I don't think that's an effective way to improve HISE. Certain issues are simply more important than others, regardless of anyone experiencing them. And self-selection bias reinforces existing issues. Just my $0.02.

@Oli-Ullmann I've experienced similar things—I think that whole system in HISE has serious issues, though I don' know what may or may not be happening in your case.

@HISEnberg said in UI Lag:

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

My plugins only run on one computer, so I don't know. I'm guessing the Windows OS would be a little faster for this.

@aaronventure Interesting. If helpful, here's how I deal with that stuff with low overhead:

I pre-render all shadows—just the shadows, and drawing the HISE components on top. And I can resize them without pixelation (like if the user resizes the interface).

In this interface, I wanted to animate the shadows. So there's a PNG with and without them. When the plugin starts, I fade in second image, and the panels appear to rise out of the interface. By slicing the shadowed PNG into five images, each panel can rise and fall independently.

For gradients, I just use a tiny, pre-made as PNG. I can scale it to any dimension or aspect ratio, and it never bands. And if I still need an alpha, it's an image—so that's easy, too.

@aaronventure That's odd. I have tons of stuff going on in my UI…lots of simultaneous timers, almost a thousand translucent components, animation, shaders…nothing has ever slowed down. I even modified the source code so I can run my timers 20x faster than the default limit. I'm only running on an M2. Are there any DAWs where you consistently have problems?

@aaronventure Can you please explain that a bit more? Cheers.

@d-healey Ace! For more general stuff, check out https://modernpictograms.com. They scale really nicely at small sizes.

@aaronventure said in All About Latency:

I imagine most plugins are like this—depending on what features the user has selected, different DSP is engaged, and the latency may change.
Yes

How am I just learning this? 🫠 (Thank you.)

As I understand, then—it is simply not possible to know your plugin's latency.

Is the idea that if you reported your latency correctly, the scheduler would be sample-accurate? If so, given that it's impossible to measure a plugin's latency, how do we know if the scheduler works?

Do you mean that it could be useful for users with slower computers to have access to higher latency? If so, they already do via increased buffer size in their interface (unless you're on an M-series Mac).

I mean that a if plugin is performing a non-constant-time operation (O1 complexity), then the amount of time the DSP code takes to execute may vary, meaning the audio output may gets written later in the buffer (or the next buffer)?

At the same time, I don't understand the point of scheduling in a real-time thread…because

I don't think it wouldn't work, I just don't know how exactly you would do it in HISE. You need to match/detect the start of your test signal (could be a simple impulse) at the output and measure how many samples have passed.

I'm thinking it won't work, because of some quantum-like paradox. 🤪

1. How do measure the number of delayed samples in a system where you don't know the latency? There is no fixed frame of reference. That's like…a Relativity paradox.

2. How do you measure time in a system where taking the measurement takes time—and that measurement must be incorporated into the result? That's like…a quantum paradox.

@Christoph-Hart, do you please have any thoughts here? The issue isn't, "Are there cases where you can know/measure the latency". It's, "In every case, can you know/measure the latency?") I realise this is probably a plugin format issue, not HISE (or JUCE).

Bill

@ustk said in All About Latency:

Inside my plugin, I am constantly computing the actual latency.

How do you do that? summing pre-guessed value depending on the configuration/state of the different DSPs or actual real measurements? The second is less error prone, hence my question...

Thank you for the question. I'm calculating the latency, because I don't see how it possible to measure it—given what my plugin does, all I could measure would be one of an infinite number of possible states.

I'll talk to the VST team at Steinberg, see if they have any ideas, and report back.