New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libpd: unsupported objects #61

Open
giuliomoro opened this Issue Aug 6, 2016 · 9 comments

Comments

Projects
None yet
2 participants
@giuliomoro
Copy link
Contributor

giuliomoro commented Aug 6, 2016

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

This comment has been minimized.

Copy link

flux627 commented Sep 3, 2016

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

This comment has been minimized.

Copy link
Contributor Author

giuliomoro commented Sep 3, 2016

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

This comment has been minimized.

Copy link

flux627 commented Sep 3, 2016

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

This comment has been minimized.

Copy link
Contributor Author

giuliomoro commented Sep 3, 2016

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

This comment has been minimized.

Copy link
Contributor Author

giuliomoro commented Sep 4, 2016

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

This comment has been minimized.

Copy link
Contributor Author

giuliomoro commented Nov 8, 2016

[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

This comment has been minimized.

Copy link

flux627 commented Jan 3, 2018

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

@giuliomoro

This comment has been minimized.

Copy link
Contributor Author

giuliomoro commented Jan 3, 2018

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

This comment has been minimized.

Copy link

flux627 commented Jan 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment