When I try to open http://bela.local/ it's super slow, doesn't connect or drops the connection.

Tried to reflash with balenaEtcher but it doesn't detect Bela as a volume, even though it mounts on the desktop and shows as connected in System Settings|Network.

Ventura 13.2.1 and the latest version of Chrome.

Could it be that my project is too big or complex?

    Does this problem manifest itself while your audio program is running or also when it's stopped? Do you have a lot or big projects on the board and or little disk space left? running df -h / in the console at the bottom of the IDE will answer the last question

    The project was a single 428KB Pd patch (no externals, abstractions or audio files) set to run at boot and was the only thing on there. I'll try putting that into the console.

      right, it may be that the patch is too big to render effectively on the IDE. Can you post your patch somewhere so I can check it ?

      https://tinyurl.com/yckjtxp sorry, I wasn’t expecting to share it so it’s still quite a mess, hopefully you can get an idea of what’s going on.
      There’s a lot of message and not many signal objects, I thought this was the way to weight it so it would run well on bela?

      BlahBlah When I try to open http://bela.local/ it's super slow, doesn't connect or drops the connection.

      Sorry it took a while. One issue here is that your patch requires more CPU than is available on Bela, which is what makes the board unresponsive once your program has started and if your program runs automatically when the board boots, then it won't show up on the host (unless you wait a veeeeery long time). If you are running on Bela Mini, you should be seeing some red lights flashing indicating CPU overload.

      BlahBlah it doesn't detect Bela as a volume, even though it mounts on the desktop

      These are mutually exclusive statements: the fact that it mounts on the desktop means that it is detected as a volume.

      BlahBlah shows as connected in System Settings|Network.

      this should mean that you can access the board at http://bela.local . If the SD card was just reflashed, then there should be no program running on boot and it should respond at that address promptly.

      BlahBlah was a single 428KB Pd patch (no externals, abstractions or audio files)

      I looked at this and without even looking for specific performance bottlenecks, I tried building it with the hvcc compiler, which translates a Pd patch which uses a subset of hvcc-compatible Pd objects into optimised C code. It seems that you are using a small number of hvcc-incompatible objects:
      [key], [cputime], [realtime], [vline~], [list]. Now, [key] doesn't make much sense in the Bela case (as there is no straightforward way of connecting a QWERTY-like keyboard to it), [cputime] and the associated objects for computing CPU load are not needed, [realtime] can be replaced with [timer] and [vline~] can be almost-exactly replaced with [hv.vline]. The use that you are making of [list prepend 0] is to simply prepend a 0 to a list of 64 floats, so that can be replaced with an ugly but effective message box like:

      [0 $1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 $17 $18 $19 $20 $21 $22 $23 $24 $25 $26 $27 $28 $29 $30 $31 $32 $33 $34 $35 $36 $37 $38 $39 $40 $41 $42 $43 $44 $45 $46 $47 $48 $49 $50 $51 $52 $53 $54 $55 $56 $57 $58 $59 $60 $61 $62 $63 $64(

      Now, after removing [key], [cputime] , [realtime], replacing [vline~] with [hv.vline] and [list] with the message above, I can compile the patch and running it on the board and the CPU usage drops drastically to 45%. That's good, it means using hvcc could be a viable option for your patch, however now there is no interaction happening because [key] has been removed.

      Now, you'll need to think about interaction. In your original patch, you were using [key] to capture key strokes to trigger sounds and tap tempo (I think). How do you see that happen in Bela ? Are you going to connect physical buttons to replace each of these functions?

      Instructions to use the hvcc/heavy compiler are here, btw.

      Thank you so much for your help! The patch is working fine with those alterations (before putting it on Bela) I will try compiling it with heavy next.
      [key] was just to test it a bit while working on a computer, next I will connect buttons as you say.

      I think I need an extra analog in though. Can I just use one of the audio ins with e.g. a pot, GND and 5V?

        BlahBlah Can I just use one of the audio ins with e.g. a pot, GND and 5V?

        No. But there are some extra ADCs on board that take a maximum of 1.8V . More details are here, that link contains a modified Pd wrapper that includes those, but for you I'd need to apply those changes to the hvcc wrapper. Can do.

        18 days later

        Tried using heavy, seems to build (?) fine in the terminal, then right at the end I get:

        Starting Heavy context with 10 input channels and 9 output channels
        Channels in use:
        Digital in : 0, Digital out: 0
        Scope out: 0
        Failed to open MIDI device hw:1,0,0
        No MIDI device enabled

        and it stops. I found the project in the IDE and clicked Build & Run but nothing seems to happen.

          BlahBlah Tried using heavy, seems to build (?) fine in the terminal, then right at the end I get:

          Starting Heavy context with 10 input channels and 9 output channels
          Channels in use:
          Digital in : 0, Digital out: 0
          Scope out: 0
          Failed to open MIDI device hw:1,0,0
          No MIDI device enabled

          this would mean that it built OK and it is running. Does it make any sound?

          BlahBlah and it stops

          Does it print anything that tells you that it stops?

          No sound or indication of any interaction with digital or analog ins.

          The terminal just stops doing anything after those six lines. I left it about twenty minutes, does it need longer?

            BlahBlah I left it about twenty minutes, does it need longer?

            No. The moment you see those lines it should start playing sound.

            BlahBlah The terminal just stops doing anything after those six lines.

            Hmmm can you elaborate on "stops doing anything"? Does the program "hang" or does it quit? If It looks like it hangs, then it would mean it is processing sound. Can you maybe post a screenshot of the terminal? Also, just to validate the workflow, in your patch add something simple and straightforward like

            [osc~ 1000]
            |   \
            [dac~ 1 2]

            alt text
            Here we go - this is where it stops.

            I added the osc~ and I now get sound from it after clicking Build & run. Could it be loadbang is not working for some reason?

            Audio is crackly with lots of 'Underrun detected: 1 blocks dropped' messages, running at about 50% cpu.

              BlahBlah Here we go - this is where it stops.

              Right. At that point the program has started and is running. It hasn't quit.

              BlahBlah Audio is crackly with lots of 'Underrun detected: 1 blocks dropped' messages,

              Right that suggests your patch is too complex.

              BlahBlah running at about 50% cpu.

              When getting dropouts, the cpu usage indicator becomes unreliable. It's also possible that you have some occasional expensive computations , such that avwrage cpu usage is indeed low, but peak usage is high which causes the dropouts, but that's normally not the case with hvcc.

              Do you want to share your patch so I can look into it?

                OK I checked it out. I ran the patch in batch mode to estimate its true average CPU usage of the patch. Running it with --board Batch --codec-mode p=95,s=1,i=10000 (running 10000 iterations of the audio callback), it gives about 26% on average, to which you should add the about 10% when running with real-time I/O. However, when running it in real-time with the default block size I do see the occasional dropouts printed to the console. I briefly explored the patch and I see you have some [env~ 1024 128] in there. Because of that, I tried running the patch in real-time with a blocksize of 128 and the dropouts disappeared. In general, you shouldn't use env's period sizes larger than the blocksize, or you may get dropouts before using the full CPU. Btw, I think this is a bug in heavy's implementation of [env~]: it runs a long expensive computation occasionally instead of smoothing it out over several callbacks.

                I didn't get any sound throughout, but that was true even when I ran the patch with PureData without heavy, so I am not sure what is expected here...

                Btw, make sure you are using the latest master-bela branch from here as with previous versions you may not be able to send messages larger than 63 elements, and I see you are doing that in your patch.

                To run your project with a 128 block size add -p 128 to the command line options to the build_pd_hvcc.sh script