Pd-dev October 2023

pd-dev@lists.iem.at

9 participants
8 discussions

Re: [PD-dev] time for a quick bugfix update?
by Dan Wilcox 26 Oct '23

26 Oct '23

There shouldn't need to be any patches applied. I double-checked and the last patch for 8.6.12 is integrated into 8.6.13 itself. As for running an 8.6.13 Wish on earlier macOS versions... well that is an issue. The builds I had made all link to the UniformTypeIdentifiers framework which apparently was added to macOS 11 and later. Running this Wish on earlier versions seems to crash due to the load not finding the framework. What's interesting is that the Tk build system is supposed to weak link to it yet the loader still exits the app on start. See the thread starting here: https://github.com/pure-data/pure-data/issues/2105#issuecomment-1774233455 > On Oct 23, 2023, at 5:16 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 3 > Date: Mon, 23 Oct 2023 17:16:42 +0200 > From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] time for a quick bugfix update? > Message-ID: <d3f803ab-9216-4e5b-8e15-ad619f1ba61a(a)iem.at <mailto:d3f803ab-9216-4e5b-8e15-ad619f1ba61a@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 10/23/23 13:21, IOhannes m zmoelnig wrote: >> On 10/23/23 11:56, Miller Puckette wrote: >>> Hi list - >>> >>> I've merged the update and documentation branches, and will merge the >>> translation support pretty soon. >>> >>> I don't know where in Iohannes's CI scripts the TCL/TK version gets >>> specified for MacOS (and I can't get to a Macintosh until next week >>> maybe to check this)... so will have to wait for word from Iohannes as >>> to when I can grab a TCL-TK-correct version from CI.? Once I believe >>> that's in place I'll imeddiately put out a 'test' version of 0.54-1... >>> >> >> thanks for checking back. >> >> indeed the Tcl/Tk version that is used for the CI builds is currently >> 8.6.12, i will try to update them asap. >> >> @dan before i do so, i would like to make sure that the Tcl/Tk binaries >> are backwards compatible: >> - arm64 should run on BigSur (and later) >> - x86_64 should run on Yosemite (and later) > > > ah well. > i've created universal builds of Tcl/Tk-8.6.13 myself (on BigSur), but > ran into the same problems as alexandre [1], with the binaries not being > compatible with older versions of macOS (i tested on Sierra). > i'll try to build the x86_64 portion on some older mac (there's a > mavericks machine somewhere...) and see how this turns out. > > sorry for the delay. > > gfmasdr > IOhannes > -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 10

Re: [PD-dev] https, msp.ucsd.edu and file downloads.
by Dan Wilcox 25 Oct '23

25 Oct '23

I agree. Both http and https downloads could be supported by using relative paths in the html a tags: <a href="/Software/$$$"> This should work as the site host is msp.ucsd.edu <http://msp.ucsd.edu/> and the relative path would be append: http or https + :// + msp.ucsd.edu <http://msp.ucsd.edu/> + /Software/$$$ > On Oct 25, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Tue, 24 Oct 2023 23:42:54 -0300 > From: Lucas Cordiviola <lucarda27(a)hotmail.com <mailto:lucarda27@hotmail.com>> > To: mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu> > Cc: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] https, msp.ucsd.edu <http://msp.ucsd.edu/> and file downloads. > Message-ID: > <IA1PR19MB7663C08254A20320483350BEA6DEA(a)IA1PR19MB7663.namprd19.prod.outlook.com <mailto:IA1PR19MB7663C08254A20320483350BEA6DEA@IA1PR19MB7663.namprd19.prod.outlook.com>> > > may be the safer way to allow links to work on both types of connections > (http and https) is to give relative URLs (stripping 'http://msp.ucsd.edu <http://msp.ucsd.edu/>') > > ??? <a href="./$$$"> > -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

https, msp.ucsd.edu and file downloads.
by Lucas Cordiviola 25 Oct '23

25 Oct '23

Miller, this might leave many (using the latest chrome web browser) scratching their heads: if I follow instructions to get the latest Pd from https://msp.ucsd.edu/software.htm when i click to download any of the files nothing happens and no files get downloaded. If I start a console I see: ``` software.htm:1 Mixed Content: The site at 'https://msp.ucsd.edu/' was loaded over a secure connection, but the file at 'https://msp.ucsd.edu/Software/pd-0.54-1test1.windows-installer.exe' was redirected through an insecure connection. This file should be served over HTTPS. See https://blog.chromium.org/2020/02/protecting-users-from-insecure.html for more details. ``` i think the problematic redirection happens in the links in file `software.htm` : <a href="http://msp.ucsd.edu/$$$"> where 'http' is used. --- may be the safer way to allow links to work on both types of connections (http and https) is to give relative URLs (stripping 'http://msp.ucsd.edu') <a href="./$$$"> there might be other ways. --- if i use the non-secure site all files can be downloaded normally. -- Mensaje telepatico asistido por maquinas.

1 0

Re: [PD-dev] time for a quick bugfix update?
by Dan Wilcox 23 Oct '23

23 Oct '23

I will try to check this tonight as we may/may not need to update the custom patches which are applied when building Tk for Pd. IN general, I think it's a good idea to make a 0.54-1 bugfix release for this as well as include the small changes in the develop branch which include a fix required for libpd... then I can make a libpd release too. > On Oct 22, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Sat, 21 Oct 2023 13:57:07 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] time for a quick bugfix update? > Message-ID: > <CAEAsFmjyVNDQXX7oHGNWw=43LS_aTcAhr1Z-8C=bTnLB7JhzTQ(a)mail.gmail.com <mailto:CAEAsFmjyVNDQXX7oHGNWw=43LS_aTcAhr1Z-8C=bTnLB7JhzTQ@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hi, we have an issue with the latest macOS, see > https://github.com/pure-data/pure-data/issues/2105 > > It seems an upgrade of tcl/tk is required and it would be worth a bugfix > release as I see it. What do people say? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 11

time for a quick bugfix update?
by Alexandre Torres Porres 21 Oct '23

21 Oct '23

Hi, we have an issue with the latest macOS, see https://github.com/pure-data/pure-data/issues/2105 It seems an upgrade of tcl/tk is required and it would be worth a bugfix release as I see it. What do people say? cheers

2 1

myfft~.c:2:10: fatal error: fftw3.h: No such file or directory
by Alexandros Drymonitis 20 Oct '23

20 Oct '23

I'm trying to create an external to test if I can embed [rfft~] and [rifft~] in one object. This is just a test to see if I can get this right, before I implement this to another external. I'm stripping what I think is necessary from Pd's source code, but I already get the error in the subject line. The FFTW3 library is used by Pd, and it is #included in the d_fft_fftw.c file. I have compiled Pd myself, and no such error occurred, so, this file must be somewhere in my system. Any idea how to solve this?

2 5

Object crashes when trying to write to its outlet
by Alexandros Drymonitis 10 Oct '23

10 Oct '23

I'm trying to code an object with a variable number of inlets and outlets, that's more complex than the one I posted a few days ago. Writing to its input works fine, but when I try to write to its output, Pd crashes. The culprit is when I try to access each individual output. In the new routine, I allocate memory likes this: ``` x->x_in = (t_sample **)getbytes(ninlets * sizeof(t_sample *)); x->x_out = (t_sample **)getbytes(noutlets * sizeof(t_sample *)); for (i = 0; i < ninlets; i++) x->x_in[i] = (t_sample *)getbytes(x->x_blksize * sizeof(t_sample)); for (i = 0; i < noutlets; i++) x->x_out[i] = (t_sample *)getbytes(x->x_blksize * sizeof(t_sample)); ``` But Pd crashes when I try to access any output other that x->x_out[0][0]. In a function that is called by the perform routine, I do the following: ``` for (i = 0; i < x->x_noutlets; i++) { x->x_out[i][x->x_sample_index] = (t_sample)x->x_outvec[i]; } ``` and Pd crashes. Debugging with gdb pointed to this line. Changing the code to x->x_out[0][0] does not crash Pd. I have also confirmed that x->x_outvec[i] is not crashing Pd. Since memory for x->x_out has been allocated, and since I'm not trying to access an element beyond this allocated memory (which is also confirmed), why does Pd crash? Or am I doing something wrong in the memory allocation part?

2 5

help coding an object, I need it cause I don't know better
by Alexandre Torres Porres 10 Oct '23

10 Oct '23

Hi, I'm working on a new object that is kinda like [value], but much simplified and you can set multiple variable names and output them all as a list (only floats now). It's been fun and it was working, compiling with some weird bugs. I then started revising it and when I thought I could be fixing the last bug, code does not compile now. What I'm doing is storing multiple variable values and variable names, just like I'm doing with some float values for my new multichannel aware audio objects (one value per channel). So I have. *typedef* *struct* _var{ t_object x_obj; t_int x_n; // number of given vars as arguments t_symbol **x_sym; // variable name *float* *x_fval; // var value }t_var; Now, when initializing the variable, in "new", I am trying to get the value of an existing variable name (which is created if it doesn't exist yet). This is done in the same as in [value] by the way In [value] you have x->x_floatstar = value_get(s); I got x->x_fval[i] = var_get(x->x_sym[i] = atom_getsymbol(av+i)); But this gives me the error * *var.c:80:22: **error: **assigning to 'float' from incompatible type 't_float *'* * (aka 'float *'); dereference with ** x->x_fval[i] = var_get(x->x_sym[i] = atom_getsymbol(av+i)); * ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* Funny enough, I had an older version that would compile and work very well despite some crashes, that initialized x_fval as *float* **x_fval; // var value Instead of just "*x_fval", which doesn't seem right. Please help, and also, at this time, I could take suggestions of some nice and free online C course that would make me intelligent to the point I would have a minimum idea of what I am doing. thanks

2 7

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 October 2023