Page 2 of 2
Re: Bad idle CPU consuption
Posted: Thu Apr 10, 2014 7:50 pm
by Nubeat7
i think its meant like watching the input and if it is less than -96db for more then 5 seconds a selector at the end is set to off (maybe some modules needed to be set off extra)
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 9:59 am
by KG_is_back
Nubeat7 wrote:i think its meant like watching the input and if it is less than -96db for more then 5 seconds a selector at the end is set to off (maybe some modules needed to be set off extra)
Turning off is easy... problem is turning the stuff back on at the right time. Green calculations happen between the asio buffer streams. Even when you use ruby to detect when the stuff should turn on precisely, the selector will have an effect in the next buffer. You may loose a small chunk of samples (depending on your buffersize) when your plugin reverts from idle state. I do not know how this behaves in rendering mode though...
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 12:51 pm
by Nubeat7
ha now i can ask a question which i wanted to ask since ages,
if i write a selector in FS dsp code does it also turn off the not used input? like this you could do all the detection in stream...
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 1:10 pm
by Nubeat7
or would it be required to use some kind of bypass code then?
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 1:54 pm
by KG_is_back
Nubeat7 wrote:ha now i can ask a question which i wanted to ask since ages, if i write a selector in FS dsp code does it also turn off the not used input? like this you could do all the detection in stream...
When selector primitive changes the index, it sort of recompiles the plugin DSP code, so it contains only parts that lead to that selector input. That means that if you select empty input (one that has nothing connected to it) only code after the selector will actually be executed.
So the answer to your question is no, you cannot write selector in FS DSP code nor assembly primitive. however you can write "smart disabling" code blocks in assembly, that will skip code execution if given conditions are met. However they work properly only in mono (and mono4) because they skip all 4 channels code execution (all 4 channels in packed mono, groups of voices of 4 in poly).
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 7:35 pm
by tester
In other words - you can stop the parts of code (blue'ish modules) to get back some CPU like the selectors do, but without recompiling the code (like the selectors enforce) which makes glitches or sound buffers disappear?
I'd like to see that solution if I may.
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 8:22 pm
by KG_is_back
simple pick a code block from any of your schematic (I recommend to pick really cpu heavy one). Connect it to a text primitive (there's a string output on every code component) to extract assembly code and copy that code to assembler primitive. At this point you have code and assembler modules that are totally identical code-wise and will behave completely the same (except the assembler code is a lot harder to understand and edit).
Now add this to your assembler code:
Code: Select all
//add new input parameter - this should be no problem as declaring inputs and outputs is identical in assembler and code component
streamboolin bypass; //Creates new input that will toggle code bypass
//add this before the start of your code, just after variables declaration or "stage2;" if your code uses stages
mov eax,bypass[0]; //copies value of first channel of "bypass" to eax register
cmp eax,0; //compares eax to integer zero (boolean false equals zero both in int and float form)
jz bypasscode; //if result is "equal" jump to bypasscode:
///////
//now here will be the original assembly code
// It will be bypassed if the bypass is false
// if you want to invert the reaction to bypass ("bypass code if true") simply replace jz with jnz
///////
//at the very end of the code add this
bypasscode: //this is a label that the code will jump to - basically skipping all code that would be executed
also note that when you bypass the code, the output values freeze - they will stay the same until you un-bypass the code again
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 8:45 pm
by tester
Thanks, this is what I was recently looking for.
I have a section with multiple filters (c.a. 30), that are switchable, but switching them during other operations - may interfere with other ongoing stuff in the schematic. Bypassing blue'ish modules individually would offer a good jump on analytical tools that are in front of me.
Re: Bad idle CPU consuption
Posted: Fri Apr 11, 2014 9:11 pm
by KG_is_back
even more then that... jump instructions are a way the computer implements if/else/case code branching and loops (both conditional and unconditional) and hops. It gives you ability to write algorithms that are not possible within normal code component (although making it poly incompatible, which is usually not big deal). I'm actually surprised in a bad way that DSP robotics didn't add a "mono-only" version of code component that implements them.
Re: Bad idle CPU consuption
Posted: Sat Apr 12, 2014 7:50 am
by Nubeat7
thank you KG for the clarification and the example, finally because of this i understand 'jz' and 'jnz', how easy it is to use jump instructions and how to do loops in ASM, this was some black area till now, new worlds are open now