[bug] SlotFX.setBypassed no worky

[d.healey]

Bump Bump

[Orvillain]

@d-healey Did this ever get resolved?

[d.healey]

@Orvillain said in [bug] SlotFX.setBypassed no worky:

@d-healey Did this ever get resolved?

Nope, but here's a workaround

HiseSnippet 893.3oc2V0saaaCElzIpnVaqXEnXWqkqTFJBrSbs8Pwv5hi8lwVRMlyJ5cAzTGESDJROJprYLz61avdf1qzdC1NTTtVtIHK0X8loKDHOmyGOe57G0DilC44ZCgFd9xE.g9wASWpryGLmITjwmPnOJ3TVtELQdQGubAKOGRHT5NeqS.s4tjxm+5qOlIYJNrVDg7JsfC+fHSXWKcxK9dgTNhk.mKxpYcmWLlqUCzRcAxmcBZQVv3WwtDNi4LqQ.46X4yIzuH3ndcYoG1qG.oca8k85k1sGmcH.cNpSmYIrYG1uOu+y50mPevvDgUalZYVHGOzi0IKmNW+KJuCdkHWLSBtMsISQO6ESFLWHSlrJ3jSHzcmrNTsiOT8jfSEIh2JecH6SKUDsFQ8fFswcQo1uGThViR65oziClxMhE10Zb74iBFqvLXJCyM0oh2VRi+jFLPiVnrGjwtBFYvMuEQb2VsdZD9Z+mGFh4mbaz0LSzvzTfamJ011QeUTYMyAWBkBF85387piJ0umCYnPIEJHJsPwsBsJRqNtvZ0p1NWazxXtNagVgj3onCjEv9g+VXSolyjQ.5hZNz4nAEFCZqWZL5glvA4fc0mW7m6OimG9Fz4q95b3V4k38p7+d66.VwhALobFV0E+tzCOoZT+LsEdoJtjhguIL5cUkldq5pNKIXtU0t1AycALVUjMCL0CPNCwz+l0TO39USw8gkZFpUiUB6KW.U6GokItZE25aVARphq3peZ7ILKyUTVICsaAXrBGcnm.WiiA7knMCNAxuxpWTZaUxfPCrkZeTUArO3SDIN.UYBxuhlQ+czaKcK9CbQN6ZXrZhAvLnqhlbyVBrYTmTHY1M6PcytpTfg3MZKbk9pbgcY8YauGsssty116KEebvDgkO+14XiagiXv+CAGqF18IA9Vs0Db2fQudamr059OYqx+OLvOZo5No5yW1jD67gX7ZvpZWbry0vvetjEe1Fr3hUppylyJxFIj3jzbWEqKGMZz4CULjA+2xVxOpKrB0kmxrFgqOA87T7dTNfILkBjkDngqm0uu0JBMETIka9a7oRYa2dZkx1qT9+Fejw3F8Eb+LUWp9gkRvXqp7OMZh+xCtOpMobNa8VrL7h8K37MOpa.7vsE3QaKvNaKvmss.6ts.6ss.6+uCz8eWeSgUm4mXRHmNYX4ESTZstNx+7zfVH.

[Orvillain]

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain said in [bug] SlotFX.setBypassed no worky:

@d-healey Did this ever get resolved?

Nope, but here's a workaround

Oh crikey. I see what you're doing there. Yeahhh that shouldn't really be necessary if you already have a reference to the slotFX object in question. But okay... yeah, it works here.

@Christoph-Hart - minor thing I guess, but it just seems a bit non-standard compared to the rest of HISE ??

[d.healey]

@Orvillain You can also grab a reference to the slot effect as an Effect rather than as a SlotFX

[Orvillain]

@d-healey slotFX works for me right now, so I'll just stick with that, but yeah cheers!!

[d.healey]

@Orvillain You can have both

[HISEnberg]

@d-healey I believe this is how the HardcodedMaster Fx is meant to be used, referencing it both as a SlotFx and as an Effect, then using whichever API is necessary for your use case. I typically try to do this and stick to a particular naming convention (ex. SlotDelay, EffectDelay)....

[d.healey]

@HISEnberg It might be useful to have an .asEffect() function like we have for samplers

[HISEnberg]

@d-healey Nice that is good suggestion and I agree. Or the inverse .asSlot ?

[Orvillain]

@HISEnberg said in [bug] SlotFX.setBypassed no worky:

@d-healey I believe this is how the HardcodedMaster Fx is meant to be used, referencing it both as a SlotFx and as an Effect, then using whichever API is necessary for your use case. I typically try to do this and stick to a particular naming convention (ex. SlotDelay, EffectDelay)....

I have a namespace called ModuleManager. At instantiation of the plugin, it collects all references to all required modules, and stores them in a SharedData namespace reg variable. The reason I do that is because I noticed early on that a lot of Synth.xxxx calls would complain about being run outside of the init function. Okay. Cool. Fair enough. That all works, and I get my references and the plugin works.

It just seems really kooky that I'd have to do a getCurrentEffect() on a slotFX reference that already exists. The documentation does state that setBypassed can be run on a slotFX object. So I spent quite a bit of time trying to solve this before coming to the forum and being shown Dave's snippet.

Is all just a bit inconsistent is all.

[d.healey]

@Orvillain said in [bug] SlotFX.setBypassed no worky:

reg variable

Use const

[Orvillain]

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain said in [bug] SlotFX.setBypassed no worky:

reg variable

Use const

As I understand it, regs are more performant and are mutable. Perfect for tracking modes or current effects or effect orders, etc etc.

[d.healey]

@Orvillain
reg should be used for variables declared in onInit whose data needs to be editable.

const should be used for all fixed data - arrays, objects, component references, module references, etc.

reg is more performant in real time callbacks than var but you should avoid using var anyway.

[Orvillain]

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain
reg should be used for variables declared in onInit whose data needs to be editable.

const should be used for all fixed data - arrays, objects, component references, module references, etc.

reg is more performant in real time callbacks than var but you should avoid using var any way.

All of the data inside my custom SharedData namespace needs to be editable.

I don't use var anywhere.

[d.healey]

@Orvillain said in [bug] SlotFX.setBypassed no worky:

All of the data inside my custom SharedData namespace needs to be editable.

If you're using Synth.getEffect() or similar they should be const and shouldn't change.

Checkout this post by Christoph - https://forum.hise.audio/topic/79/scripting-best-practices/2

[Orvillain]

This post is deleted!

[d.healey]

@Orvillain said in [bug] SlotFX.setBypassed no worky:

Inside that is reg engines = {blahblahblah}

It's an object so should be const engines = {}

You can still add to the object and change the data within it, you just can't change the variable itself.

For example this would give an error

const engines = {};

engines = 10;

[Orvillain]

@d-healey said in [bug] SlotFX.setBypassed no worky:

@Orvillain said in [bug] SlotFX.setBypassed no worky:

Inside that is reg engines = {blahblahblah}

It's an object so should be const engines = {}

You can still add to the object and change the data within it, you just can't change the variable itself.

Yes I'm aware of that.

For example this would give an error

const engines = {};

engines = 10;

I'm aware of that too.

What is the benefit of using const, in my situation? The only thing I can come up with is it gives me a guard against overwriting engines. But nothing is attempting to do that anyway. Nor will it.

To my mind, reg gives me access performance benefits. Maybe that is wrong.

[d.healey]

@Orvillain said in [bug] SlotFX.setBypassed no worky:

What is the benefit of using const, in my situation?

I think the best answer is from Christoph

it yields a huge performance boost (because it can resolve the function call on compile time).
There is absolutely no reason to not declare UI widgets, references to modules (via Synth.getModulator() etc.) not as const

reg is good for accessing script level variables in midi callbacks and anywhere else where you would have had to use a script level var. But the more reg you have (and you only get 32 per namespace) the worse the performance gets. Internally reg is like a predefined array that HISE is keeping track of. So the more values you add the more data it needs to go through each time to you access it.

Another addition to Javascript: Use reg instead of var when declaring temporary variables which are accessed in the MIDI (or audio) callbacks. It tells the interpreter to store this in a fixed size container with faster access times:
If you have a script with lots of variables, the interpreter must search the entire array for every variable access (so the 23 - 40 ms are depending on how many other variables are defined in the script while the access time to reg slots stay the same).

It's also possible since you're storing them in an object rather than as direct references that const gives no performance benefit. But it's still good practice to use a const here. It makes it clear to other developers who might see your code (or your future self) that this variable is not meant to be reassigned, and it also prevents it being reassigned accidentality.