@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 is it?

That if NOPE was just replacing the hardcoded effects in the project, no?

I just think that:

If it plays in HISE, hitting Export should mean that it will play in the plugin; there should not be any hidden steps using Faust or SNEX in a network shouldn't deprive us of functionality that doesn't play with AllowCompilation

AllowCompilation is a performance boost for "lots-of-scriptnode-stuff" networks, right? For faust I measured little to no gain, but right now faust seems to need compilation because of the way it's implemented.

So if that could be done for the raw faust nodes when hitting export, then they get replaced with compiled in the process which should, if I got it right, have it work when exported and leave the networks available for global cables, direct access etc.

@aaronventure appeared for me too today, good to know :)

@aaronventure It shouldn't be limited to 16, but there's still a bug with the number of sliders an ExternalSliderPack can handle.
This might be of interest to you: https://forum.hise.audio/topic/11411/externaldata-sliderpack-seems-to-be-limited-to-128/13?_=1743103883757