libpd: unsupported objects

[giuliomoro]

At least:

[pd~]
[sigmund~]
[fiddle~]
[netreceive]
[netsend]
[key]
[keyup]
[keydown]
[keyname]
[realtime]

(One of) the issue(s) with [fiddle~] is that it tries to use pd_fft() which is defined in 'src/d_fft_fftw.c', which is not compiled by libpd, according to this.

[netreceive] and [netsend] need to be reimplemented so that

1. they do not cause mode switches, and
2. they are heavy-compatible (probably with a [r netreceive] and [s netsend], though it is not clear how to best deal with multiple instances. Actually [netsend] currently works but causes mode switches.

The [key*] family is:

1. handled by the GUI, and
2. requires a way to connect a keyboard, whether it is stdin or a USB keyboard

[flux627]

I was very excited about getting the Bela, however now that I know that sigmund~ is not compatible I am very sad. What will it take to support sigmund~?

[giuliomoro]

I am not sure what is broken about it, it just segfaults at creation or when the DSP callback is called, I am not sure.
I noticed that there is something wrong with the FFT library that underlies [fiddle~] so maybe it is the same issue?
Will try to have a look at it soon.

Partially related: I should specify that while [block~] and [switch~] are supported, if you specify a block size larger than the buffer-size of Bela (which is user-defined, defaults to 16, up to 128), then you will likely have issues if you perform some occasional but intense task (e.g.: if you are trying to do a large FFT). Because of the way Pd is implemented, this FFT will be computed all in one audio callback, which will most likely make you miss your deadline with the audio clock. For this we should implement some sort of "transparent threading".
Similar issues may occur with objects which operate on large blocks of data, unless they internally implement some threading.These issues exist also on mainline PureData, but are often masked by large buffer sizes and additional buffering within the software.

This is NOT the reason why [fiddle~] and [sigmund~] do not work at the moment, but may be a reason(again, depending on how the objects are implemented internally) why they will not work straight away after I fixed the segfault.

[flux627]

Thank you. I would greatly appreciate if you could get sigmund~ to work, because my current project depends on it (and it also currently depends on my laptop, which I'm hoping to replace with the Bela)

[giuliomoro]

Found the issue, it was a failed alloca. I can replace it with malloc easily. Point is, as I prefigured earlier, using [sigmund~] with -nptsgreater than 512 will cause dropouts in the audio. I will have a look if there is an easy way of threading sigmund_doit() out to a lower-priority task.

[giuliomoro]

Alright, I hacked together [sigmund~] in a threaded fashion. This is ultra-experimental: race conditions are there but because of the xenomai scheduling they should not cause troubles.

Performance:
At the moment, you get this:
[sigmund~ -npts 4096 -hop 4096 pitch env]
uses about 26% of CPU.

[sigmund~ -npts 4096 -hop 2048 pitch env]
goes up to about 50%.

I forced a sleep period so you should not be able to hang your board, but be advised that CPU power is not unlimited. You will be displayed a debug warning every time sigmund~ drops some frames. Adjust your setup so that you never receive such warnings

See if you can play around with it and let me know how it goes.
You'll have to manually install this patched version of libpd.so:

• download it from here
• if you are familiar with the terminal:
  scp libpd.so root@192.168.7.2:/usr/lib
• otherwise, open any project in the IDE, drag and drop the file in the project explorer (top tab) and then run this in the console at the bottom of the IDE:
  mv projects/projectName/libpd.so /usr/lib/
  where projectName should be replaced with the name of the project you are in.

[giuliomoro]

[bob~] works but is quite expensive
This patch makes it cheaper, but uses a different solver, which slightly changes the sonic output of the filter.

--- a/extra/bob~/bob~.c
+++ b/extra/bob~/bob~.c
@@ -5,7 +5,7 @@
 #include "m_pd.h"
 #include <math.h>
 #define DIM 4
-#define FLOAT double
+#define FLOAT float

 /* if CALCERROR is defined we compute an error estaimate to verify
 the filter, outputting it from a second outlet on demand.  This
@@ -219,7 +219,7 @@ static t_int *bob_perform(t_int *w)
         if ((x->x_params.p_resonance = *resonancein++) < 0)
             x->x_params.p_resonance = 0;
         for (j = 0; j < x->x_oversample; j++)
-            solver_rungekutte(x->x_state, &errorestimate,
+            solver_euler(x->x_state, &errorestimate,

[flux627]

It's been a while. Any other progress on [sigmund~]?

[giuliomoro]

I have done quite some work on it before Christmas but haven't managed to finish it off before I went on holiday. Check out my puredata fork

[flux627]

Awesome, great to hear. I'm in no rush, but still waiting on this support to commit to purchase a few Bela units and start a pet project I've had for many years.

[jarmitage]

I'm getting lots of underruns when using [sigmund~] (using the configuration mentioned above). Is there a status update on using it?

[giuliomoro]

I'm getting lots of underruns when using [sigmund~] (using the configuration mentioned above).

Are you using 128 samples per block?

Is there a status update on using it?

We put to the side that approach as it is hard, ad-hoc, and we decided to concentrate instead on allowing arbitrarily large blocksizes, as it comes with a much greater impact for a much smaller effort. #388

[jarmitage]

Are you using 128 samples per block?

[sigmund~], 128 samples per block

• [sigmund~ -npts 4096 -hop 4096 -npeak 2 tracks]
• MSW: 1
• CPU: 27%
• Underruns: 1

[fiddle~], 128 samples per block

• [fiddle~ 1024 1 20 3]
• MSW: 0
• CPU: 19%
• Underruns: 0

[giuliomoro]

yeah sorry, that 4096/4096 was for the threaded one. You'll need smaller FFT sizes for the non-threaded one (which is the one that ships with Bela). Also, you can almost "safely" take the -hop to be the same as the blocksize (but no smaller!), if that can be useful. Remember that the peak CPU usage is given by the size of the FFT and the max number of FFTs performed in a single block. Therefore, for a fixed FFT size, the peak CPU usage is the same for any value of hop such that hop >= blocksize. What is displayed in the IDE is the average usage.

[jarmitage]

Ok. I can get up to [sigmund~ -npts 1024 -hop 1024 -npeak 20 tracks] @ 128 samples per block without underruns, will see if that'll do the trick!

Thanks.

[brycebot]

Hello. I'm curious on the current state of [netsend] and [netrecieve] on the bela. I'm planning to implement a system which uses ethernet to communicate between a bela and an ethernet enabled microcontroller, and wanted to check the viability of such a system.

[giuliomoro]

they have been working great for a while. If you want to try out the latest build, update your board to this branch (feedback welcome): https://github.com/BelaPlatform/Bela/tree/libpd-0.51