Some specification/performance-related questions
Posted: Wed Jan 23, 2019 3:11 pm
Having been building a number of "utility" modules, I'd like to understand the optimum way to code given the built-in JVM and its behaviour, so I have some questions which I am sure will be useful to other developers...
(1) Is there a performance difference between using private variables in code (i.e. @Override / public void … / { int WorkingValue; …) vs declaring them within the module, i.e. at the end with my own variables and functions - thinking about any time in creation and destruction of variables
(2) Obviously, if there is a lot of working the ProcessSample section then not doing this when a jack is not connected makes sense. However, what if the processing in this section is really simple, for example: outJack.SetValue( value ) or outJack.SetValue( inJack.GetValue() )?
Would it make sense to have "if( inJack.IsConnected() && outJack.IsConnected() ) { outJack.SetValue( inJack.GetValue(); }" or is the overhead of the test more than the saving of not processing SetValue?
(3) When using state information which have events that can tell you their state (i.e. IsConnected) a lot, does it make sense to use the events to keep state in a variable rather than always querying state - especially relevant when considered with question 2.
(4) For static values (used when internally configuring modules, e.g. for values as discussed in question 5), is there a performance benefit in using Statics and are there any limitations/issues with using Statics in this way?
(5) Is there a minimum time needed for a Trigger to be consistently recognised ... i.e. can we use the PercussionEnvelope with AttackHold 0 and Decay 0, or do we need AttackHold to be more than 0 - in which case, what?
The documentation could do with including some more around the gates, triggers and the other aspects of the library including the Audio Processing section - much of the rest is self-explanatory, but some of the Audio Processing section especially is not that obvious and any constraints like minimum or maximum values need to be documented somewhere.
And a final thought - some indication of processing time (obviously depends on the platform, but something relative might be possible) for major events/actions would be really useful in the documentation.
Maybe having the documentation available as a Wiki that can be easily updated by the team, but which can also have comments and clarifications added to it by developers would be helpful.
(1) Is there a performance difference between using private variables in code (i.e. @Override / public void … / { int WorkingValue; …) vs declaring them within the module, i.e. at the end with my own variables and functions - thinking about any time in creation and destruction of variables
(2) Obviously, if there is a lot of working the ProcessSample section then not doing this when a jack is not connected makes sense. However, what if the processing in this section is really simple, for example: outJack.SetValue( value ) or outJack.SetValue( inJack.GetValue() )?
Would it make sense to have "if( inJack.IsConnected() && outJack.IsConnected() ) { outJack.SetValue( inJack.GetValue(); }" or is the overhead of the test more than the saving of not processing SetValue?
(3) When using state information which have events that can tell you their state (i.e. IsConnected) a lot, does it make sense to use the events to keep state in a variable rather than always querying state - especially relevant when considered with question 2.
(4) For static values (used when internally configuring modules, e.g. for values as discussed in question 5), is there a performance benefit in using Statics and are there any limitations/issues with using Statics in this way?
(5) Is there a minimum time needed for a Trigger to be consistently recognised ... i.e. can we use the PercussionEnvelope with AttackHold 0 and Decay 0, or do we need AttackHold to be more than 0 - in which case, what?
The documentation could do with including some more around the gates, triggers and the other aspects of the library including the Audio Processing section - much of the rest is self-explanatory, but some of the Audio Processing section especially is not that obvious and any constraints like minimum or maximum values need to be documented somewhere.
And a final thought - some indication of processing time (obviously depends on the platform, but something relative might be possible) for major events/actions would be really useful in the documentation.
Maybe having the documentation available as a Wiki that can be easily updated by the team, but which can also have comments and clarifications added to it by developers would be helpful.