@Christoph-Hart I asked GPT a while ago, so I just did it again with Claude:

Trustability: 92%
JUCE 6 (and prior)

• Default renderer is purely CPU-based (software rasterizer). Vector-based drawing means significant CPU math per frame.
• OpenGL was optionally available via OpenGLContext::attachTo(), but it was opt-in and not the default.

JUCE 8

• Introduced a Direct2D renderer on Windows as the new default — this is GPU-accelerated via native Windows APIs with GPU-backed images.
• macOS uses Metal (also GPU-accelerated via native API).
• The software (CPU) renderer still exists as a fallback.

Performance delta

• The Direct2D renderer is built on modern native platform APIs, taking advantage of hardware acceleration and GPU-backed images, bringing significant rendering and performance improvements — including better and faster font rendering. JUCE
• Component transforms and tiled image fills show the biggest wins. On some older machines with integrated GPUs only (no dedicated VRAM), the software renderer can actually outperform Direct2D. JUCE

I didn't know Direct2D could in some cases not bring better performances. Do you think it is the same for Metal?
But still, using Win's Direct2D or mac's Metal is deporting the weight to the GPU so this should (perhaps for more usual plugin cases that don't have the complexity of Hise) be faster, am I not right?

But following Juce:

On some older machines with integrated GPUs only (no dedicated VRAM), the software renderer can actually outperform Direct2D

So yeah, might or might not be better on everything...

@David-Healey I reckon some people reported a black square with some DAWs...

@Oli-Ullmann
Yeah so to confirm this, Juce6 uses CPU instead of GPU, one of the main reason I am waiting for the full Juce8 implementation.
Shaders are shady... That OpenGL dependency is quite bad too, I got issues on mac that made me effectively drop them (for now?)
Until then, you can make 8bit retro audio plugins that require less UI precision... There's still a market for those squary bast****...

@David-Healey Oh... Didn't see you opened a thread precisely for that matter...
https://forum.hise.audio/topic/14770/compiled-network-fixed-channel-count

@David-Healey Just tried by curiosity but it's still half dynamic, because you still have to hard code the number of channel (getFixChannelAmount) and recompile the DLL...

Weird there's no way to get the hardcoded FX to actually fix the number of channel in the function parameter, @Christoph-Hart?

// ==================================| Third Party Node Template |==================================

#pragma once
#include <JuceHeader.h>

namespace project
{
using namespace juce;
using namespace hise;
using namespace scriptnode;

// ==========================| The node class with all required callbacks |==========================

template <int NV> struct MultiChannelThirdPartyGain_custom_node: public data::base
{
	// Metadata Definitions ------------------------------------------------------------------------
	
	SNEX_NODE(MultiChannelThirdPartyGain_custom_node);
	
	struct MetadataClass
	{
		SN_NODE_ID("MultiChannelThirdPartyGain_custom_node");
	};
	
	// set to true if you want this node to have a modulation dragger
	static constexpr bool isModNode() { return false; };
	static constexpr bool isPolyphonic() { return NV > 1; };
	// set to true if your node produces a tail
	static constexpr bool hasTail() { return false; };
	// set to true if your doesn't generate sound from silence and can be suspended when the input signal is silent
	static constexpr bool isSuspendedOnSilence() { return false; };
	// Undefine this method if you want a dynamic channel count
	static constexpr int getFixChannelAmount() { return 6; };
	
	// Define the amount and types of external data slots you want to use
	static constexpr int NumTables = 0;
	static constexpr int NumSliderPacks = 0;
	static constexpr int NumAudioFiles = 0;
	static constexpr int NumFilters = 0;
	static constexpr int NumDisplayBuffers = 0;
	
	// Scriptnode Callbacks ------------------------------------------------------------------------
	
	void prepare(PrepareSpecs specs)
	{
		
	}
	
	void reset()
	{
		
	}
	
	void handleHiseEvent(HiseEvent& e)
	{
		
	}
	
	template <typename T> void process(T& data)
	{
		auto gainFactor = Decibels::decibelsToGain(gain);

		for (auto ch : data)
		{
			auto block = data.toChannelData(ch);
			for (auto& s : block)
				s *= gainFactor;
		}
	}

	template <typename T> void processFrame(T& data)
	{
		auto gainFactor = Decibels::decibelsToGain(gain);

		for (auto& s : data)
			s *= gainFactor;
	}
	
	int handleModulation(double& value)
	{
		
		return 0;
		
	}
	
	void setExternalData(const ExternalData& data, int index)
	{
		
	}
	// Parameter Functions -------------------------------------------------------------------------
	
	template <int P> void setParameter(double v)
	{
		if (P == 0)
		{
			gain = (float)v;
		}
		
	}
	
	void createParameters(ParameterDataList& data)
	{
		{
			parameter::data p("Gain", { -100.0, 0.0, 0.1 });
			registerCallback<0>(p);
			p.setDefaultValue(0.0);
			p.setSkewForCentre(-12.0);
			data.add(std::move(p));
		}
	}

	float gain = 0.0f;
};
}

@David-Healey A compilable third party node should be able to do it when loaded into an hardcoded FX. This is theory though, I've never done this...
this way you could do it in C++

@David-Healey Afaik JUCE8 is more oriented toward GPU acceleration for faster UI response and better resolution as well for smoother design.
I often hit a limitation regarding how fast (or how slow I should say) my UIs are reacting.

I'd also like to be able to finally use shaders, which might be better handled in JUCE8. That being said, I don't know if this fixes platform related issues we have (Win/Mac being picky with openGL/shaders)

Yeah I hope we’ll get this soin too so heavy vector UI can react with a lesser lag…

@PabloCaparros To be honest, I think Hise is now suitable for any task, especially for a bachelor thesis where you need to do things quite fast, like UI mockup implementation and audio processing that might not be 100% efficient but working anyway.
As for the pitch detection goes, Hise does not really have one (except a very basic pitch detection of a pre-recorded buffer) so what you'll need is either to make yourself or use an existing library (if the license is compatible with your project). Hise allows you to implement/create/import algorithms like FAUST, RNBO, C++, all implemented around the DSP network (create a network -> implement anything inside)
The MIDI conversion capability will reside in your algorithm, so in the end, Hise is not the limit.
As I see it for your project, Hise can just be the container where you connect everything, audio/midi processing and UI. But the pitch detect -> MIDI will be your job using any external language and/or library

@Christoph-Hart Any news on this? Could it just be an OS issue? Unfortunately I can't test on windows before next month...

@dannytaurus Nice! Checking this asap

As in the title. The max peak is showing, but is there a way to distinguish when the peak actually peaked 0dB?

I did it in the past from a custom panel but it's a shame if the dedicated floating tile can't do this...

Solved, HISE_BACKEND_AS_FX was disabled by default in the plugin version of the Jucer. Shouldn't be...

I was using Hise as plugin successfully a while ago, but I can't seem to make it work anymore.

It's compiling fine and loading in plugin doctor, but no signal is passing through.

I tried enabling FORCE_INPUT_CHANNELS and the hardened runtime with audio inputs and microphone access. In definitive, all that I ca see that is related to audio in...
But silence is the only answer I can get...

Note that I also tried as Instrument (default jucer setting) and FX

@Christoph-Hart Yes it an embedded network, very simple, in the scriptFX

What about your snippet that I can test on my side?
And are you on windows or mac? I wonder if the difference can lie there... Especially since I have a straight crash with VST3 while AU, at least, can load

@David-Healey said in Matrix modulation connection is broken in exported plugin:

@ustk Why is xcode referencing 8.0.3

After analysing everything, AI confirmed Hise is built and running on Juce 6, and it says:

The assertion you hit is most likely thrown by the JUCE-8 plugin's code (in the v8.0.3 message thread), not by HISE's JUCE 6.

Since I am debugging using pluginval which is built on Juce8, that's 99% the origin of XCode reporting Juce8 message thread

why those platforms if the Hise Unlocker combined with a PHP script on the server side and something like Woocommerce Plugin License Manager does the job?

@David-Healey yes, always had (custom branches but one folder/repo)
Also I just re-aligned develop origin onto upstream to be sure (I had some merge commits because of past manual fork syncing) but no changes regarding the issue and the VST3 crash.

@David-Healey To this day I have no answer for this...

@David-Healey Perhaps... But I am JUCE 6... Or schizophrenic...