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
preset manager limitations
preset manager limitations
I'm starting to wonder where is the borderline of performance for preset manager.
Just did a little test with preset params to common string conversion and here are some thoughts.
at 2400 parameters to store: 40 seconds loading time
at 1400 parameters to store: 10 seconds loading time
sound offline.
*
Under test:
1) It is better to do more smaller "preset string" modules than less and larger ones. I mean it. When preset string deals with 40-80 switches, then arrays update start to play signifficant role. I suspect a good thing is around 10 switches per array->string. Then you can resign from manual retriggering for "store and load preset values"; just need to use "changed" to limit amount of updates (array, value reload).
2) It's good to use "preset string" routine/conversion only for static values and switches only. They change only on user interaction, and it means - the array change, not only the single value.
Now it's time to push inside some streamy guts to add blue load on preset routines.
//edit: works under load too.
Ehm.... in a few days back to the old project again
Just did a little test with preset params to common string conversion and here are some thoughts.
at 2400 parameters to store: 40 seconds loading time
at 1400 parameters to store: 10 seconds loading time
sound offline.
*
Under test:
1) It is better to do more smaller "preset string" modules than less and larger ones. I mean it. When preset string deals with 40-80 switches, then arrays update start to play signifficant role. I suspect a good thing is around 10 switches per array->string. Then you can resign from manual retriggering for "store and load preset values"; just need to use "changed" to limit amount of updates (array, value reload).
2) It's good to use "preset string" routine/conversion only for static values and switches only. They change only on user interaction, and it means - the array change, not only the single value.
Now it's time to push inside some streamy guts to add blue load on preset routines.
//edit: works under load too.
Ehm.... in a few days back to the old project again
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.