port granulator from max/msp to pd
Hi there
I'm struggling trying to port to PD an old Max/MSP granulator which I really enjoyed, specially since it allowed me to granulate an incoming signal in real-time, intead of using a stored audio sample from a buffer.
I use to use this patch inside a poly~ object (in PD I implement a clone object).
I'm using the cyclone library to try to stay as close as possible to the original, however it's not even sounding.
I include both patches in case anyone might have any clue or suggestions.
Thanks in advance
Best
Alexis
posted in technical issues
GRM plug-in called “Shuffling” for the granulation for Max in Pd?
@raynovich said:
Hello,
I am working on a new patch for a piece already made. The composer mentions a GRM plug-in called "Shuffling" for the granulation in Max.I do not think I have GRM downloaded. Is that only for Max?
If I'm not mistaken, GRM Tools is a set of VST FX plugins. As such, they would not be restricted to Max. (In theory, you should be able to run it in Pd using IEM's vstplugin~ external.)
I'm pretty sure they are not free, though.
Unfortunately my Internet access is inconsistent and spotty today, so I'm not able to get any further details about Shuffling... Granular techniques in general are fairly straightforward in Pd, but it's the specifics about this plugin's input and behavior that I can't find at the moment (but someone else probably could). So I'm not sure how to emulate this specific granulator in Pd.
hjh
posted in technical issues
Optimizing pd performances to fit an RPI 3
@lysergik As I understand c++ "everything" goes through a *print call....... https://en.cppreference.com/w/c/io/vfprintf
They are the basic i/o for a running program. If you text search Pd there is no executable that is not swimming in them for very obvious reasons.
You should definitely look at the "output snd_pcm_delay failed" error.
There have been posts (Google finds them) in the past suggesting that it is a RPI kernel problem with alsa and was fixed with a kernel update.
It will be causing dropouts and very possibly your dsp crash.
Any audio problem will cause Pd to struggle with control threads as well, as messages are held up, and will likely make greater demand on the cpu.
David.
posted in technical issues
Optimizing pd performances to fit an RPI 3
Hello everyone ! @Nicolas Danet First I've succesfully compiled pd with the flag, then I profiled my 3 patch/subpatches using the command you showed. So here what I got from this profiling (the report dsos=pd command doesn't gave me intersting result, so it's output is not showed here.)
Mother patch:
report ->
- 33,34% 8,01% pd libc-2.23.so [.] vfprintf
- 25,33% vfprintf
16,57% __GI___printf_fp_l
2,95% hack_digit
- 2,45% __GI___ioctl
entry_SYSCALL_64_fastpath
sys_ioctl
+ do_vfs_ioctl
1,29% __mpn_mul_1
0,70% strlen
+ 8,01% __fprintf_chk
- 16,57% 16,18% pd libc-2.23.so [.] __GI___printf_fp_l
16,18% __fprintf_chk
vfprintf
__GI___printf_fp_l
- 13,69% 13,69% pd libc-2.23.so [.] __GI_____strtof_l_internal
- 12,53% 0x2f73250064702f6e
__isoc99_vsscanf
__GI_____strtof_l_internal
- 1,16% 0x7ffc9a2c60
__GI_____strtof_l_internal
- 12,71% 12,51% pd libc-2.23.so [.] _IO_vfscanf
12,51% 0x2f73250064702f6e
__isoc99_vsscanf
_IO_vfscanf
- 5,49% 5,49% pd [kernel.kallsyms] [k] delay_tsc ◆
- 1,94% 0x3a7e647000732520
vfprintf
__GI___ioctl
entry_SYSCALL_64_fastpath
sys_ioctl
do_vfs_ioctl
snd_pcm_capture_ioctl
+ snd_pcm_capture_ioctl1
- 1,49% __GI___ioctl
entry_SYSCALL_64_fastpath
sys_ioctl
do_vfs_ioctl
snd_pcm_capture_ioctl
+ snd_pcm_capture_ioctl1
- 1,34% 0x64c99
__GI___ioctl
entry_SYSCALL_64_fastpath
sys_ioctl
do_vfs_ioctl
snd_pcm_capture_ioctl
- snd_pcm_capture_ioctl1
- 0,80% snd_pcm_common_ioctl1
snd_pcm_status_user
snd_pcm_status
snd_pcm_update_hw_ptr
snd_pcm_update_hw_ptr0
azx_pcm_pointer
azx_get_position
azx_get_pos_skl
__const_udelay
delay_tsc
+ 0,54% __snd_pcm_lib_xfer
report no children ->
- 16,18% pd libc-2.23.so [.] __GI___printf_fp_l
__GI___printf_fp_l
vfprintf
__fprintf_chk
- 13,69% pd libc-2.23.so [.] __GI_____strtof_l_internal
- __GI_____strtof_l_internal
- 12,53% __isoc99_vsscanf
0x2f73250064702f6e
1,16% 0x7ffc9a2c60
- 12,51% pd libc-2.23.so [.] _IO_vfscanf
_IO_vfscanf
__isoc99_vsscanf
0x2f73250064702f6e
- 8,01% pd libc-2.23.so [.] vfprintf ◆
vfprintf
__fprintf_chk
- 5,49% pd [kernel.kallsyms] [k] delay_tsc
delay_tsc
__const_udelay
azx_get_pos_skl
azx_get_position
azx_pcm_pointer
- snd_pcm_update_hw_ptr0
- 2,88% snd_pcm_update_hw_ptr
- 2,69% snd_pcm_status
snd_pcm_status_user
snd_pcm_common_ioctl1
snd_pcm_capture_ioctl1
snd_pcm_capture_ioctl
do_vfs_ioctl
sys_ioctl
entry_SYSCALL_64_fastpath
+ __GI___ioctl
+ 2,60% __snd_pcm_lib_xfer
posted in technical issues
Optimizing pd performances to fit an RPI 3
Well the result I've showed isn't from a global CPU counter(like htop), but it's the result I got by record event comming from the pure data process with perf(with a command like this perf record -p pid), even if there's recurent functions that are called by pd noramlly, they usally don"t run with as much CPU use. I could run a test with a very simple patch to see if the same function calls appear first or not, then we would know if the function calls perf reported are the one linking to the bottlneck.
Edit: I've just run a perf test with a patch looking like this [osc~ 440]-[dac~]. This what perf sends me:
"62,44% pd [kernel.kallsyms] [k] delay_tsc ▒
19,19% pd [kernel.kallsyms] [k] pci_azx_readl "
We see now that only delay_tsc is noramlly called by pd but all the other function called I quoted before are link to my patch.
posted in technical issues
String Machine - Granular
And for those who are interested, an alternative version, with iemguts library. It works differently, using "live" dynamic patching. I might not work on all platforms, depending on the library's versions available.
And here is the patch that I used to automatically generate all the granule~ in the string machine V 1.6
posted in patch~
String Machine - Granular
A string machine. V1.7.3 Definitive Version No library, cross plateforme, 50% less charge on the cpu.
Open the Main patch, set your midi input and your audio output and play.
posted in patch~
coronalay // tape style delay
I've never really found a satisfactory tape delay in Pd so here's a new thing inspired by vintage tape delay machines. Running on MobMuPlat tested on Android smartphone and iPad mini or, of course, desktop.
Time knob from 50-2800 milliseconds.
Feedback knob can be turned all the way to create a loop.
Drive adds a soft overdrive.
Dry/wet is a mix knob.
Smear moves two of the three playheads to non equal positions so that it creates irregularly spaced echoes and it is subtly different each time you turn it on.
Four presets are built into the top four buttons.
posted in patch~
Best Linux build for Pd on old PC? (Intel Core 2 Duo, 2 gig ram, 150 gb hd)
The idea is to use a light window manager, but with a realtime kernel, that would be the best setup. I am not aware of such distribution (I recall vaguely a distribution named puppy but looks dead to me). It's always possible to install a realtime kernel on top of xubuntu but not easy AFAIK.
Ubuntu Studio is your best bet, it use xfce have realtime kernel.
As for pd, I would install purr data, but of course using vanilla is really easy too if you know how to build.
posted in technical issues
rPi no midi input or output found
OK an update!
I installed Raspbian Jessie Lite and Pure Data 0.46 and the MIDI input worked fine. So I figured the problem had to do with the "upgrade" to Stretch and PD 0.47.
HOWEVER then I installed the software for my Pisound audio card, which is what I was using for audio input and output. This requires some sort of kernel update. After that, the MIDI stopped working again! So I'm now wondering if the problem is something to do with that kernel update. This means that Raspbian Stretch and PD 0.47 may actually be fine, but it was my Pisound software messing everything up...
posted in technical issues