[bug] SlotFX.setBypassed no worky

[d.healey]

This function is shown in the API browser but when I try it I get a function not found error.

[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.