while tinkering to get my OLED working w/Pepper, i ran into this issue:

i have my O2O service file running in the background.
i have a patch here that runs fine when i drag and drop it in the IDE, then build and run.
however, if i power down and reboot so that the patch runs as one of the loop_ patches, it gives me an underrun detected: 1 block dropped message, seemingly on every clock tick to iterate the patch.
i would think it's the exact same patch with the exact same service file running, so i don't get what is causing this behaviour.

i tried eliminating all OSC communication to the screen (thought i was sending too much info at once every clock tick), but it keeps happening.
like i said, when i modified _main.pdto not send OSC, uploaded and ran it, it was looking good. after reboot, the same thing reoccurred.

thoughts?

When running in •loop_• the project settings you have in the IDE are not obeyed (see /opt/Bela/bela_startup.sh). There are two possible workarounds:

  • if the project settings are the same for all projects you want to run on loop, create /root/.bela/belaconfig and add a line there starting with CL= and including all the non-default settings you are using, e.g.: to set the block size to 128 and input gain to 20dB: 
    CL=-p128 -I20
    Note that these will not be obeyed when running from the IDE, because the settings in the IDE will override these.
  • if each project has its own distinct settings create a file /opt/Bela/local/bela_startup.sh that gets run instead of /opt/Bela/bela_startup.sh. There you can write whatever you want for the loop that gets executed at boot, e.g.: 
    #!/bin/bash
while sleep 0.1; do
  cd /root/Bela/projects/project1
  ./project1 -p 64 -I10 -N0
  cd /root/Bela/projects/project2
  ./project2 -p 128 -I0 -G0
  cd /root/Bela/projects/project3
  ./project3 -p  4096 -I20
    After you create the file, make it executable by running chmod +x /opt/Bela/local/bela_startup.sh. When

To see the full list of command-line options that your project is running with, so you can use them in these two cases, look at the output of journalctl -fu bela_ide in a terminal while you run the program from the IDE.

    ok thank you.

    tbh, i don?t think i ever messed with individual project settings like block size. is there a standard setting that is used when running •loop_•?

    and to be absolutely clear - can i use journalctl -fu bela_ide both when running the loop and when running from the IDE to check what settings i'm using and where they differ?
    and can i just run that command in the IDE console in both cases?

      Remork journalctl -fu bela_ide

      This will show it only when you start the program from the IDE. If you run it from loop, it will run with no arguments (or whatever you specify in /opt/Bela/local/bela_startup.sh if you follow my suggestion above) and so use the default parameters from either ~/.bela/belaconfig or the ones from the C++ source (which are the same defaults as the IDE). There are only a few that would make a real difference to CPU usage:

      • -p blocksize (most important)
      • -N to disable analog
      • -G to disable digital
      • --high-performance-mode (which has to be set as "User Command Line Arguments:" in the IDE)

      I am sorry this is confusing. But also, if your blocksize in the IDE is already 16, which is the default anyhow, then it's unlikely that it will make any difference running it on boot even without parameters.

        giuliomoro (see /opt/Bela/bela_startup.sh)

        just locating this file to see what you mean took me an hour. hahah

          but okay, running it in the IDE with blocksize = 16 shows the same behaviour.
          running it at 32 or higher seems to get rid of the issue.
          will have to read up on blocksize to understand more (and why not to just crank it), i guess.
          threads like these are quite discouraging though - i seem to zone out after three replies.

          will try setting everything to 32 or 64 and call it a day for now..

            Remork will have to read up on blocksize to understand more (and why not to just crank it),

            Increasing it increases latency, so the lowest it is the better. Also, the jump from 64 or 128 (depending on the board) to the next value causes a spike in cpu usage. 32 is a good value

              alright - set the global loop_ blocksize to 32: no more acting up in any of the patches.
              genius.

              had to do a bit of googling on use of the Terminal.
              you learn something new every day.
              to forget it the day after, surely 🙂