trowaSoft trigSeq and voltSeq Performance

Plugins & Modules
1

Hi Rackheads, Since I liked to use trowaSoft trigseq(64) and voltSeq very much but had to get rid of them because they eat up way too much cpu. I took a look at the source these days and did quite a simple hack to reduce CPU usage of them drastically (trigseq64 from > 10% CPU to <1% CPU) when running on external clock which is my standard use case. The main idea is to not fully run on each sample but only each 32 samples but still checking the external clock trigger input to keep exact timing. For those who are interested, here are my code changes:

Module_trigSeq.cpp and /Module_voltSeq.cpp in process():

    if (!initialized)
            return;

    // adapt the lightLambda used to calculate step light fading
    // because the process is executed completely only every 32nd time
    if (inputs[EXT_CLOCK_INPUT].isConnected())
            lightLambda = 0.05 / IDLESKIP;
    else
            lightLambda = 0.05;
    idleCnt = (idleCnt + 1) % IDLESKIP;
    double newExtTrg = inputs[EXT_CLOCK_INPUT].getVoltage();
    // return if not each 32th sample, ext clk is connected and the trigger input did not change
    if (idleCnt != 0 && inputs[EXT_CLOCK_INPUT].isConnected() && newExtTrg == extTrg) {
            return; // return if idle to reduce cpu time
   }
   // save old ext trigger input state to detect change
   extTrg = newExtTrg;

   bool gOn = true;
   bool pulse = false;

in TSSequencerModuleBase.hpp:

    // If this was loaded from a save, what version
    int saveVersion = -1;
    // removed conts to allow changing depending on ext clk connect state
    float lightLambda = 0.05;
    // The number of structured random patterns to actually use. 
    // Should be <= TROWA_SEQ_NUM_RANDOM_PATTERNS.
    int numStructuredRandomPatterns = TROWA_SEQ_BOOLEAN_NUM_RANDOM_PATTERNS;

    // defines and global variables used by my hack 
    #define IDLESKIP 32
    int idleCnt = -1;
    double extTrg = 0;

    //-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
1 Like
2

It’s a shame there are so many modules out there where the author didn’t seem to think at all about CPU usage. Do you already publish your own modules? If so you could publish your version. I’ve done things like that before.

2 Likes
3

great Dieter, :+1:
it would be cool when you can release an updated version of the plugin,
if this is ok with the license for it.

4

Since I didn’t do a deep dive into the code and have no clue what is going on with osc, I do not know whether my patch may be destructive for use cases i do not have. So I posted the fix to enable others to speed up the trowasoft seqs too. If the authors of trowasoft think it is ok to do what i have done, they can use my patch as a blueprint for any optimization approach which takes the whole functionality into account. So if for example you are running with the internal clock of the sequencers my patch does not reduce cpu overhead. For that reason I do not plan to do an own release of this patch.

5

The license looks quite liberal, and there has been no update of the code on github for 7 months. That said, there are no open issues about performance, so if you want to author to fix it, that would be the place to go.

6

Just created the Issue: Easy patch to darstically reduce CPU overhead of trigSeq(64) and and voldSeq · Issue #51 · j4s0n-c/trowaSoft-VCV · GitHub

2 Likes
7

@Stubs Thank you for reporting the issue and taking the time to offer a solution. We’ll get to it ASAP.

1 Like