[bug] SlotFX.setBypassed no worky
-
@d-healey slotFX works for me right now, so I'll just stick with that, but yeah cheers!!
-
@Orvillain You can have both
-
@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)....
-
@HISEnberg It might be useful to have an
.asEffect()function like we have for samplers -
@d-healey Nice that is good suggestion and I agree. Or the inverse
.asSlot? -
@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 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.
-
@Orvillain
regshould be used for variables declared inonInitwhose data needs to be editable.constshould be used for all fixed data - arrays, objects, component references, module references, etc.regis more performant in real time callbacks thanvarbut you should avoid usingvaranyway. -
@d-healey said in [bug] SlotFX.setBypassed no worky:
@Orvillain
regshould be used for variables declared inonInitwhose data needs to be editable.constshould be used for all fixed data - arrays, objects, component references, module references, etc.regis more performant in real time callbacks thanvarbut you should avoid usingvarany way.All of the data inside my custom SharedData namespace needs to be editable.
I don't use var anywhere.
-
@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 beconstand shouldn't change.Checkout this post by Christoph - https://forum.hise.audio/topic/79/scripting-best-practices/2
-
This post is deleted! -
@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; -
@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.
-
@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 constregis 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 moreregyou have (and you only get 32 per namespace) the worse the performance gets. Internallyregis 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
constgives no performance benefit. But it's still good practice to use aconsthere. 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.