If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
Bad idle CPU consuption
20 posts
• Page 2 of 2 • 1, 2
Re: Bad idle CPU consuption
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)
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Bad idle CPU consuption
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...
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: Bad idle CPU consuption
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...
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...
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Bad idle CPU consuption
or would it be required to use some kind of bypass code then?
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
Re: Bad idle CPU consuption
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).
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: Bad idle CPU consuption
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.
I'd like to see that solution if I may.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: Bad idle CPU consuption
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:
also note that when you bypass the code, the output values freeze - they will stay the same until you un-bypass the code again
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
- Attachments
-
- bypass example.fsm
- (1.34 KiB) Downloaded 823 times
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: Bad idle CPU consuption
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.
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.
Need to take a break? I have something right for you.
Feel free to donate. Thank you for your contribution.
Feel free to donate. Thank you for your contribution.
- tester
- Posts: 1786
- Joined: Wed Jan 18, 2012 10:52 pm
- Location: Poland, internet
Re: Bad idle CPU consuption
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.
- KG_is_back
- Posts: 1196
- Joined: Tue Oct 22, 2013 5:43 pm
- Location: Slovakia
Re: Bad idle CPU consuption
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
-
Nubeat7 - Posts: 1347
- Joined: Sat Apr 14, 2012 9:59 am
- Location: Vienna
20 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 64 guests