@Christoph-Hart That it, thanks.

@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

https://github.com/juce-framework/JUCE/commit/19175ff698923b2536c25ad32674958f73448e55#commitcomment-85270460

@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.)

@Christoph-Hart

Gotcha. Maybe I'm thinking about this all the wrong way, and the best approach for me is to use the classic method of handling all my RR logic inside a midi processor script.

I haven't got to implementing any of this yet. I'm still just thinking about it. But as I see it, and from experience, a hihat needs the following:

Ability to trigger multiple articulations, with round robin functionality. Ability to fade out or "choke" earlier voices when a new voice of a different articulation is triggered (Open to closed) Ability to crossfade from one articulation to another, based on incoming midi CC (usually CC4) Some way to trigger the 'tail' of a 'more open' articulation when going quickly from closed to open. Instantly choke all voices when a pedal articulation is triggered.

I was hoping the complex group functionality would do a good chunk of this. But I suppose it is the wrong tool?

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).