@d-healey Yeah you're right, I updated it with a simple gain knob.

@aaronventure

<script> // Define a fallback for development mode if (typeof window.DOMContentLoaded === 'undefined') { window.DOMContentLoaded = function() { console.log('DOMContentLoaded called (development fallback)'); }; } document.addEventListener('DOMContentLoaded', function() { // Call the function that will be defined in the HISE app DOMContentLoaded(); }); </script>

in index.html seems to do the trick.

@d-healey Right, see it.

From macOS docs:

OpenGL is not color managed. As a consequence, it might require additional effort to devise solutions to specific color problems you may encounter when using it. The fundamental problem is OpenGL has one set of assumptions, and the display buffer has another.

JUCE has now apparently fixed it, here's the commit

Link Preview Image OpenGL: Ensure that macOS uses the same (sRGB) colour space everywhere · juce-framework/JUCE@19175ff

JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins. - OpenGL: Ensure that macOS uses the same (sRGB) colour space everywhere · juce-framework/JUCE@19175ff

favicon

GitHub (github.com)

@aaronventure Help me with the ScriptNode, and I'll help you with this? (And thanks.)

Selected units on the timeline should persist... even through crashes

@clevername27 i tried it with the stock sliders without any LAF. they don't have the opaque flag. If there was an entire opaque panel covering it, I'm pretty sure it wouldn't be redrawing.

@aaronventure I requested a proper bug tracker a couple of times, something like Mantis. It would prevent bugs being lost in the ether of the forum, or being lonely on github.

@aaronventure the only thing that could happen is that a timer callback is being dropped because Cubase's UI thread is very prone to being overloaded, but it obviously does not have access to any variables so what you are experiencing seems to be a very odd glitch.

If you want you can send me the project, then I'll take a look at it, I'm currently debugging stuff in Cubase anyways.

@Christoph-Hart not sure I follow

9cce4a7f-9ebc-44a8-be68-9835d0325fc3-image.png

I changed the range on the Value parameter to 0-0.1, it still outputs the raw value to minmax value.

Even so, it's still not dynamic.

I think it's just a missing node, what are the odds of using it in a signal path instead of using it to cable things around? Dynamic range adjustment, that's it? It's much more likely to be used in the context of pma, cabletable, inputToggle which are the workhorse nodes for value manipulation when creating modulators.

Overall there's a workaround, so it just depends on how much time this takes you to do. This is just a QoL request.

@aaronventure yeah the examples look clean, i stumbled across this library a week ago

@Christoph-Hart +1 for Rive :)

A lot of these elements would be possible (or way better) using Rive at least everything thats state of the art GUI + interaction design...

(Rive cant do accurate audio representation tho: external path data like visualizers wavetables etc.)

@d-healey Alright that's fixed - that logic is a bit convoluted because as soon as something is not zero based (like the old RR group values were) it breaks my brain, but you can thank that deficiency of mine for not having to write Lua all day.

All control nodes which are stateless (eg. the cable_expr node) are automatically polyphonic, but the others should have dedicated support for polyphonic states.

I just checked in the source code and the input_toggle does in fact only have a monophonic state, but the compare node should be polyphonic. However I just realized that the wrapper code doesn't propagate that info to the UI to show the [poly] suffix like with the other nodes.

So:

input_toggle is polyphonic now all control nodes properly show the [poly] suffix (it shouldn't have affected functionality though, was just an UI glitch).

@d-healey Nice this documentation is great to have.

The HISE GPT is a bit better these days, especially for navigating the HISE docs. If you prompt it to check the HISE API on a specific subject, it will access it and give you a description of the what you are asking about. It is still quite prone to error and quite imperfect for generating code. For LAF it's okay.

@Christoph-Hart Haha that's not at all what that requirement says.

The requirement says that if I input MIDI or audio into HISE and it spits something out, then pressing export should result in that same plugin.

Faust nodes need the compilation step before they can work? Alright ,throw a warning and tell me to enable Allow Compilation. If I didn't ask again on export. But then it should compile to a plugin that works. Because it works in the HISE IDE.

I can, in HISE, have a single .dsp file that I use in 10 different networks at 30 different places in Fasut nodes and it'll work in the IDE. I can make changes and it'll work. But just pressing export wont.

So what, I should now first compile that faust dsp file in a lone network that exists just for compiling lone faust files, replace all existing faust nodes that are used for development because I cannot just branch, as the nodes cannot be in there when exporting, connect all the cables for 30 instances across 10 networks and then compile? And then when I have to make a change, what then? Git discard all the changes to the networks, make changes, and then replace and reconnect 30 nodes again just to run pluginval?

Come on, man 😄