@Lindon so can we finally get back to discussing whether Claude was better 1 month ago please?

anyways, back to the original problem. I'd say you have two options:

1. Use a script voice start modulator if all the parameters have a corresponding mod chain (gain, pitch & filter all have that). The logic of selecting the next value from your array can be calculated in the onVoiceStart callback and if the mod target is rendered polyphonically (which is the case for pitch, gain & filter), then everything should be click free as the rendering pipeline is reset before starting the voice.
2. Make a custom FX with either an extra mod chain, then go back to 1 for other modulation targets.

I wouldn't touch event data here if you get by with scripted voice start.

@ustk upcoming as in the base is implemented but there's no real world usage yet which hardens the feature set.

The docs of the current website is nonexistent, but the new website has this covered thoroughly, you can take a sneak peek at the GitHub repo that hosts the new website content:

https://github.com/christoph-hart/hise_api_generator/blob/main/ui_enrichment/pages/components/ScriptDynamicContainer.md

Let me know if you run into problems (which you definitely will as first user)...

@ustk multipagedialog is deprecated but dynamic container is the upcoming solution.

Haha at this point it‘s a meme - whenever Lindon asks something we all share our experience with random LLMs…

@dannytaurus HISE based revenue. I think the real contract has updated this but the preview still uses the old rule.

The HISE 5 agreement definitely has the HISE based revenue as rule.

Sorry guys I‘m currently completely submersed in a theatre project, so this month will still be slow but then I‘ll pick up the work and review / merge all the PRs - just keep them coming they are not ignored but sit around waiting to be reviewed.

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