Pd-dev August 2018

pd-dev@lists.iem.at

9 participants
8 discussions

Fwd: external help, please
by Alexandre Torres Porres 22 Aug '19

22 Aug '19

Hi folks, I need help on an external. I wanna perform a task on an array of signal inputs. It's a multichannel object, and I define the number of channels with an argument. Here's just the core of it, as an object named "mtx~", where I map the input to the output. And this is what happens. [image: Imagem inline 1] So you see I get a weird mirrored output, instead of something like "1 2 3 4 5 6". The perform method in the code is just static t_int *mtx_perform(t_int *w){ t_mtx *x = (t_mtx *)(w[1]); int nblock = (int)(w[2]); t_float **in_vectors = x->x_in_vectors; t_float **out_vectors = x->x_out_vectors; t_int i; for(i = 0; i < x->x_ch; i++){ t_float *in = in_vectors[i]; t_float *out = out_vectors[i]; t_int n = nblock; while(n--) *out++ = *in++; } return (w + 3); } What am I doing wrong? How should this go? See attached the help test example and code. Thanks

11 26

architecture strings Planet Gemini PDA / Debian
by Fred Jan Kraan 01 Sep '18

01 Sep '18

Hi everyone, Not sure someone is collecting uname responses for various systems, but this is from the Planet Gemini PDA with Debian. $ uname -a Linux localhost 3.18.41+ #7 SMP PREEMPT Wed May 30 16:45:45 MSK 2018 aarch64 GNU/Linux python: >>>print platform.uname() ('Linux', 'localhost', '3.18.41+', '#7 SMP PREEMPT Wed May 30 16:45:45 MSK 2018', 'aarch64', '') Puredata is available and launches as expected. The 403 dpi screen makes the font size teensy-tiny. Reading gets really close to guessing. Greetings, Fred Jan

3 3

How to use the return value of the function canvas_open()?
by Pierre Guillot 25 Aug '18

25 Aug '18

Hi, I use the canvas_open() function to locate a file (FAUST DSP file) but I don't understand if I should use the close() function on the returning value: int fd = canvas_open(...); if(fd >= 0) { close(fd); } This code works well on Linux and Mac but it crashes on Windows. I looked at other uses of the canvas_open() function but they differ. The close() function is used, in the binbuf_read_via_canvas() function (l. 850 of m_binbuf.c) or in the open_soundfile_via_canvas() function (l. 494 of d_soundfile.c). But the returning value is not closed in the bonk_read() function (l. 985 of bonk~.c) or the garray_read() function (l. 1096 of g_array.c). Is there one case where I should call the close() function and another not. Or is there an error in some of these example? Am I missing something important? Thanks

2 2

[pure-data:patches] #585 Fix for #1315: fexpr~ crash due to uninitialized variable
by mrshpot 16 Aug '18

16 Aug '18

--- ** [patches:#585] Fix for #1315: fexpr~ crash due to uninitialized variable ** **Status:** open **Group:** bugfix **Created:** Thu Aug 16, 2018 12:17 PM UTC by mrshpot **Last Updated:** Thu Aug 16, 2018 12:17 PM UTC **Owner:** nobody **Attachments:** - [0001-fix-crash-due-to-uninitialized-variable-in-expr-fexp.patch](https://so… (717 Bytes; text/x-patch) Here is my fix for https://sourceforge.net/p/pure-data/bugs/1315/ Sorry for double-posting, I've just realized that this is the place to submit patches. --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

[pure-data:bugs] #1315 fexpr~ crash due to uninitialized variable
by mrshpot 16 Aug '18

16 Aug '18

--- ** [bugs:#1315] fexpr~ crash due to uninitialized variable** **Status:** open **Group:** v0.48 **Created:** Thu Aug 16, 2018 12:11 PM UTC by mrshpot **Last Updated:** Thu Aug 16, 2018 12:11 PM UTC **Owner:** nobody **Attachments:** - [pd-fexpr-crash-fix.patch](https://sourceforge.net/p/pure-data/bugs/1315/att… (424 Bytes; text/x-patch) pd: commit 511f4cfd2a0332bbf3a7654102a1518f3eb95bf6 (tag: 0.48-2) distro: Arch Linux amd64, gcc-8.2.0 Steps to reproduce: - Run: `pd doc/5.reference/expr-help.pd` - Open the fexpr~ example subpatch - Enable DSP - Click any 'start' message or: - Run: `pd doc/5.reference/expr-help.pd` - Open the expr~ example subpatch - Enable DSP - Tweak the limiter/clip example slider Pd dies with abort() in ex_eval: ~~~ (gdb) bt 0 0x00007ffff7087b5f in raise () from /usr/lib/libc.so.6 1 0x00007ffff7072452 in abort () from /usr/lib/libc.so.6 2 0x0000555555652d5e in ex_eval () at x_vexp.c:1139 3 0x00005555556541e4 in eval_store () at x_vexp.c:1335 4 0x0000555555648d6b in ex_eval () at x_vexp.c:1174 5 0x000055555566a2b0 in expr_perform () at x_vexp_if.c:451 6 0x000055555559787d in dsp_tick () at d_ugen.c:369 7 0x0000555555603847 in sched_tick () at m_sched.c:422 8 0x00005555556040f5 in m_pollingscheduler () at m_sched.c:517 9 m_mainloop () at m_sched.c:596 10 0x00007ffff7074003 in __libc_start_main () from /usr/lib/libc.so.6 11 0x000055555556a21e in _start () ~~~ Valgrind gives the following warning: ~~~ ==15650== Conditional jump or move depends on uninitialised value(s) ==15650== at 0x1FC409: ex_eval (x_vexp.c:1137) ==15650== by 0x2081E3: eval_store (x_vexp.c:1335) ==15650== by 0x1FCD6A: ex_eval (x_vexp.c:1174) ==15650== by 0x21E2AF: expr_perform (x_vexp_if.c:451) ==15650== by 0x14B87C: dsp_tick (d_ugen.c:369) ==15650== by 0x1B7846: sched_tick (m_sched.c:422) ==15650== by 0x1B80F4: m_pollingscheduler (m_sched.c:517) ==15650== by 0x1B80F4: m_mainloop (m_sched.c:596) ==15650== by 0x5622002: (below main) (in /usr/lib/libc-2.28.so) ==15650== Uninitialised value was created by a stack allocation ==15650== at 0x208080: eval_store (x_vexp.c:1323) ~~~ So the story seems to be that: 1) eval_store has an uninitialized `struct ex_ex arg;` local variable which is passed to ex_eval() in `case ET_VAR:` 2) ex_eval trips on the `optr->ex_type==ET_VEC` check in `case ET_XI0:` or `case ET_XI:` If the `struct ex_ex arg;` variable is initialized, all expr~/fexpr~ examples work. This fixes the problem for me: ~~~ diff --git a/src/x_vexp.c b/src/x_vexp.c index 0ce43ae..bff93ac 100644 --- a/src/x_vexp.c +++ b/src/x_vexp.c @@ -1329,6 +1329,9 @@ eval_store(struct expr *expr, struct ex_ex *eptr, struct ex_ex *optr, int idx) int badleft = 0; int notable = 0; + arg.ex_type = ET_INT; + arg.ex_int = 0; + switch (eptr->ex_type) { case ET_VAR: var = (char *) eptr->ex_ptr; ~~~ --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

key/keyname fixes for macOS
by Dan Wilcox 14 Aug '18

14 Aug '18

There seems to be a fix now in Tk for the key event issues on macOS. The caveat is that we will probably need to ship with Tk 8.6+ as this fix will not be back ported to Tk 8.5. One issue could be whether Tcl/TK 8.6 can be built on a macOS 10.6 system. I'm not 100% sure. One option would be to have binaries for 10.6-10.11 which use TK 8.4 and binaries for 10.12+ which ship with TK 8.6. It could be a pain but the scripting already handles most of the headaches. Details here: https://github.com/pure-data/pure-data/issues/213#issuecomment-412829151 <https://github.com/pure-data/pure-data/issues/213#issuecomment-412829151> -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

About inlet DSP prolog.
by Nicolas Danet 05 Aug '18

05 Aug '18

Hi, < https://github.com/pure-data/pure-data/blob/master/src/g_io.c#L210 > x->x_fill = x->x_endbuf - (x->x_hop - prologphase * re_parentvecsize); < g.io.c / line 210 > IMHO it does not properly shift the buffer in case of overlap (i.g. [block~ 512 4]) if stopping/restarting the DSP. x->x_fill = prologphase ? x->x_endbuf - (x->x_hop - prologphase * re_parentvecsize) : x->x_endbuf; The change above might solve the problem. I'm not 100 % sure. I'm currently testing the fix on Spaghettis < https://github.com/Spaghettis/Spaghettis/compare/dev >.

2 2

[pure-data:bugs] #1314 WSAStartup failure prevents pd patch from running headless on Windows 10
by Ticket 1314 04 Aug '18

04 Aug '18

--- ** [bugs:#1314] WSAStartup failure prevents pd patch from running headless on Windows 10** **Status:** open **Group:** v0.48 **Created:** Sat Aug 04, 2018 06:38 PM UTC by Anonymous **Last Updated:** Sat Aug 04, 2018 06:38 PM UTC **Owner:** nobody **Attachments:** - [osc_test.pd](https://sourceforge.net/p/pure-data/bugs/1314/attachment/osc_t… (426 Bytes; application/octet-stream) I am attempting to run this simple patch: osc_test.pd on my Windows 10 computer, headless, using pd 0.48-1 vanilla along with the mrpeach external. Using the command prompt, I go to the directory that contains this patch, and then enter the command "pd -nogui osc_test.pd". When I do this, I get error: udpreceive: socket: Either the application has not called WSAStartup, or WSAStartup failed. (10093) verbose(4): ... you might be able to track this down from the Find menu. error: udpsend socket: Either the application has not called WSAStartup, or WSAStartup failed. (10093) error: udpsend: not connected However, when I instead enter the command "pd osc_test.pd" (with the GUI) it is able to run properly. By run properly, I mean that udpsend: connecting to port 9001 print: /test 20 30 40 is printed in the pd terminal window, which is the expected behavior. --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev August 2018