Per Csound project block size on Pepper with loop_* ?

jaradical

Hello,

I'm running multiple Csound projects on Pepper using the loop_* project settings (See https://forum.bela.io/d/2983-help-getting-bela-button-to-loop-csound-projects-on-pepper), and it's been working wonderfully so far.

I've been working on a kind of drum machine, and was having trouble with dropped blocks. To try and fix that I've changed Csound ksmps and the block size in the IDE (and hence settings.json) to 32. The project runs fine when launched from the IDE, but when I get to it from the bela button as part of project looping, it sounds like it's reverted to the default block size of 16 and the mismatch between the Csound ksmps and block size is causing severe distortion and loads of dropped blocks.

Is there a way to have per project block size settings when using the loop_* functionality?

Cheers

giuliomoro

this is not supported at the moment, but I have a sense you are a pretty experienced user, so you should be able to follow these instructions:

edit the file /opt/Bela/bela_startup.sh on the board.

This loop is what calls each project matching the loop_* pattern:

        for PROJECT in "$BELA_HOME"/projects/loop_*; do
            echo Running $PROJECT;
            /usr/bin/make -C /root/Bela PROJECT=`basename "${PROJECT}"` CL="${ARGS}" runonly
        done

the ARGS variable contains the command-line values that are passed to the project. When selecting loop_*, this is empty. Inside the loop, you could overwrite it for the desired project. Something like this should do, if you replace MYPROJECT with the name of the project that needs a blocksize of 32.

        for PROJECT in "$BELA_HOME"/projects/loop_*; do
            echo Running $PROJECT;
            ARGS=
            if [ "$PROJECT" == "MYPROJECT" ]; then
                ARGS="-p32"
            fi
            /usr/bin/make -C /root/Bela PROJECT=`basename "${PROJECT}"` CL="${ARGS}" runonly
        done

jaradical

Brilliant Giulio, it's working now!

I was poking around in the Makefile, but I can see that /opt/Bela/bela_startup.sh is the place to be.

I ended up doing it slightly differently like this:

         for PROJECT in "$BELA_HOME"/projects/loop_*; do
             echo Running $PROJECT;
             PROJNAME=`basename $PROJECT`
             if [ "$PROJNAME" == "MYPROJECT" ]; then
                 ARGS="-p32"
             fi
             /usr/bin/make -C /root/Bela PROJECT=`basename "${PROJECT}"` CL="${ARGS}" runonly
         done

Thanks again for your help, and if you'd like to play with it, it's here:

https://github.com/jazamatronic/bela_pepper_patches/blob/main/drumkit_bela_csound/_main.csd

Cheers

giuliomoro

Looks good, thanks for spotting my mistake. Perhaps it would have been better like this (one fewer call to basename):

         for folder in "$BELA_HOME"/projects/loop_*; do
             PROJECT=`basename $folder`
             echo Running $PROJECT;
             if [ "$PROJECT" == "MYPROJECT" ]; then
                 ARGS="-p32"
             fi
             /usr/bin/make -C /root/Bela PROJECT="${PROJECT}" CL="${ARGS}" runonly
         done

jaradical

Oh yeah, I didn't catch that we already do a basename, I'll update my scripts accordingly.

I'm wondering if there's any way to make this more generic - something like using jq to parse the settings.json if it exists in the project directory and creating the ARGS from that or something?

giuliomoro

Sure that would be a better option.
See https://github.com/BelaPlatform/Bela/issues/395 and https://github.com/BelaPlatform/Bela/issues/394 for context. This is compound with the issue that all command line options shown in the IDE are passed to the command line even though they have not been modified, which makes it hard to identify those that the user actually cares about from those that are just defaults and so I wanted to fix that first (though it is somehow orthogonal). Last, I didn't want to add any runtime dependency (such as jq) to the program. At some point in the process I beautified the settings.json so that now it has one parameter per line and so could be parsed via grep and sed if needed, but still there are some backwards-compatibility caveats in doing that (what happens if a user has an old settings.json?).

The issue is I never got around to doing it the right way and didn't want to get it only "partially" right, so I always left it "broken". I was planning on fixing it some better way in the next major release. Anyhow, I will consider any suggestions for expedient fixes.

jaradical

Ok - a little more complicated than I had envisaged.

Would adding it to RTAudioCommandLine.cpp make sense? I can see two ways to handle it:

Like the userBelaConfig in Bela_defaultSettings - look for settings.json and populate the settings with that - probably after userBelaConfig is processed.
As part of Bela_getopt_long, by using --jsopts or similar and providing --jsopts settings.json via the Makefile (with file existence tests etc.)

I can see the various JSON cpp/h files and could probably have a go at coding something up using them.

Let me know what you'd prefer, and if we should move this conversation to the github issue instead?

Cheers

giuliomoro

jaradical Let me know what you'd prefer, and if we should move this conversation to the github issue instead?

sure. I just added a bit of context to https://github.com/BelaPlatform/Bela/issues/394