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.