DSP Robotics Support

Nubeat7 wrote:]isn`t it what you wanted? and it checks the bypass signal for zero not the stream so it depends what you do to generate the bypass signal.

Glad you're here, now we can get some practical results!
I guess this could be the answer I'll give it a try.

OK this is what I've got so far:

Much better but still loosing some attack; And that's because of Blue to green transition.
In order to save some CPU, I need a stream selector that disables the unused signal, like a green selector would.

the thing is that KG`s methode is the only proper way to do it - from the moment you read a value from stream to green you loose...

if you would use a 'code' selector you wouldn`t deactivate the wet path it would still be processed, there are only this 2 ways - selector with green input or KG`s assembler methode if you want a proper solution

Nubeat7 wrote:there are only this 2 ways - selector with green input or KG`s assembler methode if you want a proper solution

I see. That's disappointing
I think In KG's method we have to do it for individual modules, well if they have codes.
why isn't there a selector to work with stream Boolean? I don't understand.

yes you need to do it on each code (specially the cpu intensive ones - normally they are written in code and are not cables and prims) if its fs streamcode (the blue one) just change it to asm code using the little 'S' on the right upper corner and connect a textbox to it and you get the asm code which you can modify..

if you want good performance vst`s you should be a friend with asm anyway

Nubeat7 wrote:if you want good performance vst`s you should be a friend with asm anyway

You're right about that but not a good answer for lazy people like me Still this is so easy to apply and works really good, except that tiny attack point!
Couldn't they just extend the selector to work with blue? I don't see what could be the big problem.
Btw i just checked your Repeat X. Very nice plugin indeed.

Father wrote:why isn't there a selector to work with stream Boolean? I don't understand.

It is because blue and green codes are executed separately. When your plugin processes the blue signal, your green code is frozen and vice versa. Also during the blue execution the code must be fixed.
The selector changes (recompiles) the blue code while the plugin is in green-mode (not executing the blue code). Recompiling while blue code is running would create enormous spikes in CPU and also the processor would have to switch between multiple tasks to do so.

When writing the plugin in most programing languages (like C++) you have direct access to the full buffer that comes to the plugin, so you can check to bypass the plugin before anything else happens. Unfortunately we do not have such luxury in FS - we can only edit the code that processes the data on sample-by-sample basis. It is one of the many limitations the FS brings and only way around is to write the plugins in C++.

KG_is_back wrote:It is one of the many limitations the FS brings and only way around is to write the plugins in C++.

Thanks for the depressing information! hehe
I tried to use your advise and create a bypass for the simple reverb. I converted most parts to assembly code. when the code bypass is switched on, it goes from 5% to 3% cpu. However using the default green on/off switch it comes down to 2% or 1%. so i guess we have to do every connection,wiring and calculation in code in order to achieve a true bypass.

Father wrote:

KG_is_back wrote:It is one of the many limitations the FS brings and only way around is to write the plugins in C++.

Thanks for the depressing information! hehe
I tried to use your advise and create a bypass for the simple reverb. I converted most parts to assembly code. when the code bypass is switched on, it goes from 5% to 3% cpu. However using the default green on/off switch it comes down to 2% or 1%. so i guess we have to do every connection,wiring and calculation in code in order to achieve a true bypass.

Yes... the bypass only bypasses the calculations inside the code component. The passing of values between the components are not affected.

This is better than nothing. But i wish there were a solution in FS itself to deal with this. Maybe in the future?
Thanks for your help on bypassing codes KG. very useful tip.
How about pack/unpack components? Can we replace them with some code?!