@ustk have you attached a lambda? I forgot the exact syntax but you can add a void f(double) lambda that reacts on simple value changes

@ustk Haha I am launching HISE with the cli most of the time and there it worked so I never bothered…

hise-cli -hise launch

just fyi at this point the hise-cli contains the functionality of the mcp server and the lsp server so it's the all in one solution going forward.

@Kalliopei if you just want to show the gain reduction on your UI, use a global cable with the mod output of the compressor and register an async callback on your UI script:

HiseSnippet 2207.3oc0Yzzaaibkz1icrcRrSZZSA5EhE8fRapfjchcRWTXYYKG6lHaUKsZ28T1QjCkHD4LrjCcrZwBrnm5gdnW2a4XOzCE8Vuk+Bs8X6g9SH+B5tuYFRKRIYaIEGuaT.B37l488adeLtV.yjDFxBzzWpQOehl9MQ06Q4c1oC1gpcvtZ52FUEGxIAFJPk64iCCIVZ55y9LA.8EmSS96saUF6holj9fzzZxbLIuvwyg2Gpeom635tG1hzvwK0oeToCLYzcXtrHPdlEUPyGa1E2lbHVbrYPZ6iC6no+yPqisZs4SJRZQdp0lX75a9302rXKyMe5FjMd7SWG+nBaV3I3mTPSe9JVNbVPcNlSBAhVlY0qdG1qnJFzzIzokKQrnnVcfyJvZ6zww0pVhwITSSGUquoZVko5dnpNVNmAuuIaU4FF8wHsQSelKRjJNAhzLoDo4ThzcP0MCb7482QHOKiNfBdPaL3aRKJpypMyeUGsCCNAkm2C2krW.r3LLxsQgBOz.9uG7wKsD3eB4FmfCLB7L9UFUnscnj7sI7m4xZgcOlEwcnsqhofWKHGfQeDZCVmWZhAUCPLvSfzNhU49H4NADqHStCi9QB9z+v4CHscDwe6fccaAwC4rinxCl6DraD4AK86WZQP5CYvY8Cbn7b8kpcIlNsHtg6wBDwp6gMACeth4KX7KLTXCL6Kenw1g8nlGx3N1NlXAsevGmvECFE1fbDMmjSK8kKYL3V11ibOgIMf45JLDiXaQrevEgXNZjWKRvCM5qmhCB95rAPyOdAPlJObpCxnGPc3G4ShWuGy0RDXH9d3vMs3PD3qO4fcwbLDApGCCNmOIf6HDG8cIm.24UwiKh1kD1ky70zF99ysPaG3SZ21AyiCTyBIyslYuht0zWMz+AwFZ3nbo.c63aOki3bFUywR.RIEwfjthz42zFCZbKzwjPBOKIP5WH50ccrHARzWAcXjWcNwOF1YDXtwj.KiDXKkgIPARQfUkDndWmgDA8wzD.TfEveNo2jaHypH9Dh0yorV8EgkGExqFi7NLuVrxrSkneWTcxuMh.UnNC73oHoDgagNxjiOgbLl1lL49xEQ06DYa6RltHokQUnhjhMbHmmnOmB46lg20f7lRBbOvD34zfQIo13LJ8MvOKwMa8eBp3F4G8uIfWMItLSGduwhW1+7xamO+Se9t4yudTM05wlW2E8BBsMuy3wotBN07WCb5yX0TqGyPn6ffp7TJwsNwkHJlbIQPijH2GcTD2OheEPp6fpVqBjSLHgX8IxLiMQVQPjJTqgHwpiYX47n8gRGiHjd3FTfViXVQth76o6WRTcNdCnFXlL+hFQngPTT5NMmflnJbwkCFSQ7NnZNbyNiVFmYDxnn+r2Cx3YkNqXaCQM8Ev4P68YSaelWL600G1FsTbP.vSUClpkFCHCwMXp+GQ86uwOf3iCHMX0bw8xEh87cgrobxCMZAYK5V242QFtoHekDTVbhblp3zvoo2o4upZi3rVc4ANmBWVD0ng4VfZKwRWxcv30ERJSTmPsJjjWJdyhI25EaVLYyTcbcHg+JVPWo2H9aM8anL8gRi7KsOUaaWW1qfq19NwwnfKPBqFysmeGF0wT.RchDAcaOVDviXose.d4DuQhfCCe0.63Jh2qGEBcMZcDsNPG4De5y1jDDJ44BnB4g+Aw+GxrfslW01cuZXdGwEIQinPTKIHu4YQuo0hzAPpI+RuqflIiHhhST54IrRhAD0mMUqnpHWwJ3d4LB1bSzAgME6Zhc0ZpRWApsflxAphEXwQmGjSOesLx9JHqdTrmiYXd4lCKowXcIB4boExTl7F3.Xnkv3FqoDSkSTJVGHaFssbLK0jQZ0vA.SgQiD6s.RoOBNA2nNMoC8ccB8gKZkgtNHpayYfHLLTKxoIwbUfqMVvT.RzShCOiQpAgSVAoAp5PalMq+m+lp3SaNXk.Y+ixXIIrW+0e8+Xq5cIuRYdig9l1+seXIkapQm.RXmNhpJMHmxavjTDLJm.lMAmECVHmsCDt1pGGndTqmEvh7kKRIAe0uw1tva1kXiib4MGtF0EpNf6YP0oDqzXoNewi9y+msDpyMPay4hVRFspLOR9LHWpd7WlS60GWZz5wAktFziEg4XbI3Px6nhn4Ya+KmVE4saMb7UowSQd8+9++ujJxBniE22NG0XYzm.2HrgLTViQvUWa6e74nKucqI2o.Jy.5hjPCoKRnwkdgVdUYRuBzG0uy8xRpDjCjLJShxeDJPUdLelyLb9xAHR57lKN+9+8+z2LwI3Sk3LV7WEk8AlFYF2r43zS42Vd77afOZH+Fj26b8aI4quh7YucqyKFb6HNyC51Q1nZF0TqLi00CKaq3c9MctuZykQeJLcr7IjkE1umbsMKvy3YDnl+POry682PVMudi.LMzmERJlw8DOLbXFnCfwZiDi0xdegGQyRZEnLmRXI1CrDoN2MJk.bsz.qgoYHFrNCkpJZ4LY4+aK0iBTm.Zt0QglfgAOPDWsH2Pxm5Xw6TLMh8AuVZv6iCr.WnYloYF3A3la75bN6fcoN+HlyX92WOw9bi2nOWx6e98+gYyLo1JJYbAz16ua8iiEM42FUf7Ltvs6LhVUFkkLiPe29wDX9l1sIYyeMJsP0iyNQAmLPoDSbugfF2PzPPdAAjrzfkOrfZ8W8Os+okjjK4.+2E9CkfQQ3YRg74uIoKkTIEpXxpJKcMUV8I3OMzEEYbq39.Mjorl3vhq0n3amHqJOx2uE1ahjgEeHXWWAEGv9Agg81Ic7+gfo8BehtYGqmn6JWdm9mq6ZtlEzQgw6RMqqUw89HnKm0Ljtaiu682WGOE30AO7vlArWZpdAUQgsaHg.5MUNr1hnph0FEG9k98flwdooYVRMDhqMsHt9zh3ilVDe7zh3FSKhaNsH9jKGQQuxwyAJG.VqZsJpW3SWM6f7Ji12BT.R7RI

@ustk yeah there's currently nothing in scriptnode that allows a reordering (except for actually reordering the nodes). Usually the dynamic chaining takes place on the module level, where you can pass in an array with the processing order and it takes care of everything.

Can you rearrange the DSP to individual nodes, then use the module-level reordering with one hardcoded FX module per block?

Alright, I've performed a bunch of fixes:

• there was in fact an issue where the macro restoring used the parameter index as raw macro control value which could have created some restore issues (although that was only in the HISE backend path and shouldn't affect compiled plugins.
• a few other low risk fixes that might cause other glitches

Lindon can you check if that still persists or if we're chasing ghosts? There have been a few fixes to this system this year so I'd like to know whether this still applies.

The analysis from Dan looks like a good redesign plan but it's a bit overly aggressive and I don't trust it to not yield any side effects that we'll chase a few months later down the line.

I've let the robot loose on it. "Read this topic and propose a fix. Make no mistake."

@Kaih looks like a permission issue, if the app data folder was created from another user (or from a user with admin privileges), you cannot write to it. thanks for nothing macOS...

@combamusic haha let me know how that goes, but the setup routine should be able to run without hand holding from the robot, just launch it and type in /setup, then it will do it without wasting tokens.

@ustk ah OK I could reproduce that. The fix is actually not in the HISE code (yet), but the codegen is missing a property of the C++ node so that it knows to add the glue code to connect the internal cables. The solution requires two steps from you:

1. If you want to use a global cable inside a nested C++ node (a C++ node that is compiled and then loaded into a DSP network that is then again compiled, you will need to add the IsFixRuntimeTarget property to the node_properties.json file. This tells the code generator that the node wants to be notified of global cable assignments (this information is otherwise lost on the layer of the C++ node).

{
  "internal_cpp_node": [
    "IsPolyphonic",
    "IsFixRuntimeTarget",
    "AllowPolyphonic"
  ]
}

2. However this is only part one of the solution as the code generator will then assume that the C++ node has a second template argument (like any other native HISE node that requires a runtime connection). So in order to compile the generated C++ code of the DSP network you will have to add a second dummy template argument to your external node:

// Use this enum to refer to the cables, eg. this->setGlobalCableValue<GlobalCables::internal_cable>(0.4)
enum class GlobalCables
{
	internal_cable = 0
};
// Subclass your node from this
using cable_manager_t = routing::global_cable_cpp_manager<SN_GLOBAL_CABLE(776606779)>;

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

// instead of just this:
//template <int NV> struct internal_cpp_node: public data_base

// add this template argument
template <int NV, typename UnusedHash=runtime_target::indexers::none>
 struct internal_cpp_node: public data::base,
                           public cable_manager_t

With these two steps, the global cable connections survives the nested C++ / DSP network structure, so please try if that also solves your actual project. If that's the case, I'll update the documentation accordingly.

https://github.com/christophhart/hise-cli

Install this, then use the /setup function this should install & compile the latest versions. Going forward you can then use the /update command whenever you need the latest state.

Changing the function signature is a breaking change too, but I think a preprocessor is weird for that, just add another function. The hard thing is to come with a non-weird name for it, my best attempt is getDirectChildComponents()

@ustk I need a dumbed down representation of the issue so I can reproduce it. My theory is that if you use a C++ node that connects to a global cable internally then this will not survive being wrapped into a network and then recompiled and loaded into a hardcoded FX?

@ustk can you rearrange your setup so that the global cables are in the outermost network that you compile?

I haven‘t checked / tested the global cable initialisation in C++ nodes to be recursive so it might fail if you try to wrap another node that uses a global cable. Can you check with a simple two level nest test if that‘s the case?

@Orvillain you can sign AAX with a self signed bullshit certificate no need to give the mafia any money…

@David-Healey nope, I'll need to work on the details with Tobias when I'm back from vacation.

@ustk the fillPath thing on the profiler isn't the time it takes to encode and decode the path to base64 then do all the overhead in C++ in the CSS engine (that's probably all tucked away under the paintRoutine graph, that's just the function passing on the path data to the GPU which is just a memcpy operation and should be very fast.

but drawDropShadowFromPath isn't using melatonin yet, no?

@ustk you can try if the overhead of passing a dynamic path exceeds the blur render performance but my guess would be that its faster.

@musicayciencia globals are used when you need to share data between script processors - although David correctly suggests that this should be the last tool you pick for that as there are way better ways for cross-module communication by now. The callback of a single script processor share all the variables declared in the onInit callback.

Now about the non-deterministic issue: if you compile that script it won't cause an error, as the JS compiler cannot know whether the variable setGlobalVariable is a function that can be called - it might get assigned to something callable at some point so it stays put and doesn't complain. However when you play a note, then it's time to call this variable and that's where HISE realises that you can't execute the (empty) variable.

var callableAtSecondTime = undefined;

function onNoteOn()
{
	callableAtSecondTime();
}
 
function onNoteOff()
{
	callableAtSecondTime = function()
	{
		Console.print("Now I work");
	};
}

This script will throw an error when you press the first note, but the first note off will then assign a function to the variable so subsequent notes will not raise the error but call the function. That example looks weird, but it's one of the more powerful features of JS (and HiseScript) to be able to reassign function slots to different functions like this so you can implement dynamic logic more easily.

Yes webview for adding shadows is definitely the wrong direction, it basically replaces your entire interface (or at least a rectangle of it) by a web browser.

The problem why melatonin blur hasn't been integrated into the Graphics API calls yet is because there were some inconsistencies with the API parameters with what melatonin expects and before breaking the API call surface I just decided to use it in CSS where there is no issue with backwards compatibility, but maybe now it's time to rethink that and (at least) put it behind a preprocessor like we always do when deprecating stuff.

The melatonin blur is a marvelous piece of engineering, but it still renders the shadows on the CPU so it still is super slow compared to a solution that just gives the GPU the instruction to blur something with its millions of shader units. Unfortunately this is the one hard restriction that comes with using JUCE as underlying GUI framework.

I would also recommend starting to play around with the CSS LAF stuff to get a feel for the performance of melatonin - start with buttons, these are best suited for CSS LAF. Sliders / Knobs are a bit quirky because you need to abuse the pseudo element classes to render different parts of the knob (eg. the track, the arc, the thumb).

const var laf = Content.createLocalLookAndFeel();

laf.setInlineStyleSheet("

button
{
	background: #666;
	color: white;
	margin: 5px;
	border-radius: 3px;
	box-shadow: 0px 2px 3px black;
}

button:hover
{
	background: #999;
	transition: background-color 0.1s;
}

button:active
{
	transform: translate(0px, 2px);
}

");

Content.getComponent("Button1").setLocalLookAndFeel(laf);