Pd-dev July 2023

pd-dev@lists.iem.at

8 participants
11 discussions

windows installer > 0.54-0
by Lucas Cordiviola 27 Jul '23

27 Jul '23

there are a couple of things i must do but i should ask first: 1. "winget install puredata" i tried to be smart and always trigger "interactive installs" and test it locally but when i tried to add the package friendly people from Microsoft didn't approve it and they are right :) see: https://github.com/microsoft/winget-pkgs/pull/111566#issuecomment-1625580667 2. "Wipe prefs" i'm not really sure if this is needed but may be useful if prefs are stopping people from loading the app (as it was reported by oliver: https://lists.puredata.info/pipermail/pd-list/2023-06/132360.html ) actually we have a radio button menu for [ ] run the uninstaller [ ] continue we can add [ ] clear Pd prefs and exit (try this if Pd is not loading anymore) 3. "make the uninstaller recursively delete install path" actually this is not happening but if someone is running the installer without an uninstall, files that changed names get accumulated and successive uninstalls loose track of them. this can lead to people browsing "reference" or "examples" not meant for their pd-version thoughts welcomed :) lucarda -- Mensaje telepatico asistido por maquinas.

2 2

is "pd64" the official name for double-pd?
by IOhannes m zmoelnig 25 Jul '23

25 Jul '23

so now that Pd-0.54 is out, I wonder whether we have settled on "pd64" being the "official" name for double-precision binaries. the question mostly arises from an flext issue [54] that i recently raised: flext can be built as a dynamic library, which is called libflext-pd.so (for Pd obviously). since flext can only handle a single floatsize, we would need a different dylib name for the double-precision variant of Pd, and i suggested libflext-pd64.so as thomas has rightfully pointed out, this would only make sense if "pd64" is indeed the agreed-on name of the double-precision Pd binary. so: is it? afaict there has been rough consensus about this from all vocal parties; however miller has not said anything beyond the initial "Pdouble". mgfasdr IOhannes PS: this is really about the names of the executable files (/usr/bin/pd64, .../pd/bin/pd64.exe, .../pd/bin/pd64.dll). i think this *can* be kept distinct from the "marketing name" (e.g. what is announced on websites), but of course it need not be. PPS: and yes, as indicated in previous mails, Debian now ships a puredata64 package which includes a /usr/bin/pd64 binary; which is all my doing (so you know who is to blame). while this sets a precedent, I don't think it is too late to change the name (even though I would rather not :-)) [54] https://github.com/grrrr/flext/issues/54

2 2

Fwd: help with some new multichannel tools
by Christof Ressi 24 Jul '23

24 Jul '23

Forgot to send to the list... --- Buffer aliasing means that the input and output signal might point to the same buffer. This is done to minimize memory usage and increase cache friendliness. In practice, this means that processing happens /in place/. You must not write to any output before reading the /corresponding /inputs. For most objects this is not a problem because for each sample you'd typically read the input(s) and then calculate the output(s). Problems arise when you want to write a whole output /block /before processing/copying all the inputs. Here's a simple example: Say you send the list [2 1( to your [remap~] object. In your original "naive" version, you would copy the second input channel to the first output channel (2 -> 1). However, since input and output alias each other, you have in fact overwritten the first input channel! Now, when you go on to copy the first input channel to the second output channel (1 -> 2), you get unexpected values. Side note: why do your channel indexes start at 1? Pd uses zero-based indexes for almost anything, with only few exceptions (ADC/DAC and MIDI channels, anything else?). Christof On 23.07.2023 05:59, Alexandre Torres Porres wrote: > > > On Sun, 23 Jul 2023 at 00:10 Alexandre Torres Porres > <porres(a)gmail.com> wrote: > > I see now I was just doing something silly thinking I was trying > to copy some sophisticated trick that would sove things. > > I can't remember now which object I had to deal with something > like this. > > > > Found one, copied the structure, it works! I still have no good idea > on how things work, but hey, I got it working and I can sleep > > > > Thanks > > > > > anyway, in this last version, I have my own "perform" method that > fails equally as before in some cases, but it is not as weird as > before... > > let me just copy it instead of linking to a github code that might > change, here's the code section > > *static*t_int*remap_perform(t_int *w){ > > t_remap *x = (t_remap *)(w[1]); > > t_int n = (t_int)(w[2]); > > t_int nchans = (t_int)(w[3]); > > t_sample *in = (t_sample *)(w[4]); > > t_sample *out = (t_sample *)(w[5]); > > *for*(*int* i = 0; i < x->x_n; i++){ // channels to copy > > *int* ch = x->x_vec[i].a_w.w_float - 1; // get channel number > > *if*(ch >= nchans) > > ch = nchans - 1; > > *for*(*int*j = 0; j < n; j++){ // j is sample number of each channel > > *if*(ch >= 0) > > *out++ = in[ch*n + j]; > > *else* > > *out++ = 0; > > } > > } > > *return*(w+6); > > } > > > Em sáb., 22 de jul. de 2023 às 21:22, Alexandre Torres Porres > <porres(a)gmail.com> escreveu: > > ok, I was able to compile a version that does not blow pd up > > obviously I have no idea of what I am doing and I did some > things based on warnings I was getting, but then, I do copy > the input first and then reorder the channels but I do get the > exact same result as before, so it was all for nothing. > > here's my new attempt, hopefully not too far from getting > things right > https://github.com/porres/pd-else/blob/master/Code_source/Compiled/signal/r… > > cheers > > Em sáb., 22 de jul. de 2023 às 21:02, Alexandre Torres Porres > <porres(a)gmail.com> escreveu: > > > > Em sáb., 22 de jul. de 2023 às 18:39, Christof Ressi > <info(a)christofressi.com> escreveu: > > if the input and output signals have the same channel > count, they will alias each other, just like in > regular single-channel objects. > > actually, funny stuff happens for 4 multichannel input and > 3 multichannel output, but I've seen that issue with > single channel objects and I tried copying stuff from > other objects in ELSE into this multichannel idea and failed. > > You first need to copy the whole input signal to a > temporary buffer (probably allocated in your object) > and then copy the corresponding channels to the output > signal. > > > I wonder if you can give me a better detailed strategy/steps. > thanks >

2 1

help with some new multichannel tools
by Alexandre Torres Porres 23 Jul '23

23 Jul '23

Hi, I'm creating new fun objects that are tools to deal with multichannel signals to include in the next update of ELSE. I have a working "pick~" object that picks a single channel from a multichannel connection. Of course you can set which channel with a message. I'm now expanding this concept to remap or reorder a multichannel signal, much like how you can reorder a list message in Pd with dollar symbols ($1, $2, etc). It is called "remap~" for now and takes floats or lists. A "0" means "none", so no channel is picked and we get zeros. With a float input or argument it is just like "pick~". It is working well depending on the list I am sending, but somehow it doesn't work for other lists. here's the "dsp" code. *static* *void* remap_dsp(t_remap *x, t_signal **sp){ signal_setmultiout(&sp[1], x->x_n); *int* length = sp[0]->s_length; *for*(*int* i = 0; i < x->x_n; i++){ *int* ch = x->x_vec[i].a_w.w_float; *if*(ch > sp[0]->s_nchans) ch = sp[0]->s_nchans; *if*(ch >= 0) dsp_add_copy(sp[0]->s_vec + ch*length, sp[1]->s_vec + i*length, length); *else* dsp_add_zero(sp[1]->s_vec + i*length, length); } } If I print the "ch" values and ch*length or i_lenght I get the expected values, so I can't understand what goes wrong. For instance, if I have a 4 channel connection input with values "1 2 3 4" and send it the list "1 2 3 2 1" I get the correct expected output of "1 2 3 2 1". If I send it "2 1", output is the same! Single float values also work as mentioned, now for some bugged outputs... "3 2 1" gives me "3 2 *3*" "1 1 2" gives me "1 1 *1*" "1 2 2 3" gives me "1 2 2 *2*" funny enough, something like "1 2 2 2 3" gives me the same correct output. I can't see a pattern here. I need help from the wizards to please save me. Test patch attached. Code lives here https://github.com/porres/pd-else/blob/master/Code_source/Compiled/signal/r… thanks ps. While we're at it, I don't get why we have both sp[0]->s_length and sp[0]->s_n, aren't both the same?

2 5

Re: [PD-dev] performance of different Wish versions
by Dan Wilcox 16 Jul '23

16 Jul '23

I disagree with this assessment. In recent years the macOS maintenance of Tk picked up quite a bit and it is *much better* than before. It was always reacting as opposed to staying on top of platform changes but they at least have integrated changes from our end for sticky things like the key handling issues. I also disagree that macOS has “constantly changing” APIs and associated FUD. Most changes are well documented in advanced and major changes often leave deprecation mechanism in places for many years after (ie. Carbon). That these updates come as a surprise to open source developers who don’t keep up with all the minutia (myself much included) is not always Apples fault. Should we stick with Tk forever? Possibly not, but I don’t see issues like this as always the next reason to drop it ASAP consider how difficult cross-platform development is due to platform differences. It’s disappointing but kinda “par for the course.” enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com > On Jul 15, 2023, at 9:18 AM, pd-dev-request(a)lists.iem.at wrote: > > From: Sebastian Shader <sebfumaster(a)aol.com> > To: "pd-dev(a)lists.iem.at" <pd-dev(a)lists.iem.at> > Subject: [PD-dev] performance of different Wish versions > Message-ID: <22683916.267738.1689344746296(a)mail.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > From my brief interactions with making prs for tk, my impression was that Wish development on macos isn't very healthy.Probably partly due to MacOS changing APIs all the time and leaving developers to figure out how to migrate in the best way. > There are a few different threads regarding performance issues with recent wish and MacOS, but unless someone investigates it and opens up a ticket with Tk to fix it it probably won't get fixed. > Tcl/tk that isn't recent has some little things that don't really work on macos, so there's really nothing to be done on the pd side aside from switching to another gui toolkit entirely.

2 2

Re: [PD-dev] performance of different Wish versions
by Dan Wilcox 15 Jul '23

15 Jul '23

I'd be curious to know if this is related to Pd itself *or* Tk? It appears to be the latter and the next test would be to write a minimal Tcl/Tk script which reproduces the behavior. It could be something like a single window with a Tk cnv and a rectangle which changes color in a loop. If the performance hit comes with just the Tcl script then we can open an issue with the Tk devs as there may be a regression. > On Jul 14, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 3 > Date: Thu, 13 Jul 2023 23:22:10 +0200 > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: [PD-dev] performance of different Wish versions > Message-ID: <1d9d56e5434211950cc1b1b363d84af42ff3b7f9.camel(a)gmail.com <mailto:1d9d56e5434211950cc1b1b363d84af42ff3b7f9.camel@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hey all > > I was seeing a suspiciously high CPU usage (~52% in Acitivity Monitor) > on macOS with one of my patches basically idling. It turned out to be > the GUI process and not 'pd'. Then I figured out that it was related to > frequently changing the color of a [cnv] in a GOP. The same patch with > the same rate of color changes eats almost no CPU on Linux (4-5% in > htop). -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

performance of different Wish versions
by Sebastian Shader 14 Jul '23

14 Jul '23

From my brief interactions with making prs for tk, my impression was that Wish development on macos isn't very healthy.Probably partly due to MacOS changing APIs all the time and leaving developers to figure out how to migrate in the best way. There are a few different threads regarding performance issues with recent wish and MacOS, but unless someone investigates it and opens up a ticket with Tk to fix it it probably won't get fixed. Tcl/tk that isn't recent has some little things that don't really work on macos, so there's really nothing to be done on the pd side aside from switching to another gui toolkit entirely. -seb Date: Thu, 13 Jul 2023 23:22:10 +0200 From: Roman Haefeli <reduzent(a)gmail.com> To: pd-dev(a)lists.iem.at Subject: [PD-dev] performance of different Wish versions Message-ID: <1d9d56e5434211950cc1b1b363d84af42ff3b7f9.camel(a)gmail.com> Content-Type: text/plain; charset="utf-8" Hey all I was seeing a suspiciously high CPU usage (~52% in Acitivity Monitor) on macOS with one of my patches basically idling. It turned out to be the GUI process and not 'pd'. Then I figured out that it was related to frequently changing the color of a [cnv] in a GOP. The same patch with the same rate of color changes eats almost no CPU on Linux (4-5% in htop). Because of lack of better ideas, I tried to build a Pd-0.54.0.app based on different Wish versions. On macOS 12.1.6 (Monterey, the only version I have currently access to), I was able to create the following Wish versions with the help of the tcltk.sh script that is part of the pure- data repo: - 8.6.11 - 8.6.12 - 8.6.13 8.6.10 doesn't seem to build on macOS 12, so I didn't try smaller versions. The biggest difference between different Wish versions I got with the patch flat-gops-refreshing-often.pd. When turning on the [metro] and let a signle GOP square blink by clicking into the light green area, those are the CPU usages I see with different Wish versions / Pd 0.54- 0: - 8.6.12 67% - 8.6.13 65% - 8.6.11 %6 Yeah, in this particular test, 8.6.11 is 11x faster than 8.6.12! With some other tests the differences are less pronounced. When flickering a [cnv] directly in the patch (not GOP), all versions show similar CPU usages. With another patch (not included), 8.6.13 is clearly better than 8.6.12, but still beaten by a wide margin by 8.6.11. The unusual high CPU usage seems related to GOP usage. The flat-gops- refreshing-often patch holds many instances of a GOP abstraction. It performs badly even the other GOP instances are not flickering. However, when number of idling GOP abstractions is reduced, the flickering instance eats much less CPU. Miller's 0.54-0 release apparently uses 8.6.12 which - according to my tests - performs the worst of the three tested versions.? This is my test env: - Pd 0.54-0 (built with 'make app') - macOS 12.6.3 - Wish/TclTk - 8.6.11 - 8.6.12 - 8.6.13 My test builds and some test patches are included here: https://netpd.org/~roman/tmp/wish-speed-macos.tar.gz Cheers Roman

1 0

performance of different Wish versions
by Roman Haefeli 13 Jul '23

13 Jul '23

Hey all I was seeing a suspiciously high CPU usage (~52% in Acitivity Monitor) on macOS with one of my patches basically idling. It turned out to be the GUI process and not 'pd'. Then I figured out that it was related to frequently changing the color of a [cnv] in a GOP. The same patch with the same rate of color changes eats almost no CPU on Linux (4-5% in htop). Because of lack of better ideas, I tried to build a Pd-0.54.0.app based on different Wish versions. On macOS 12.1.6 (Monterey, the only version I have currently access to), I was able to create the following Wish versions with the help of the tcltk.sh script that is part of the pure- data repo: - 8.6.11 - 8.6.12 - 8.6.13 8.6.10 doesn't seem to build on macOS 12, so I didn't try smaller versions. The biggest difference between different Wish versions I got with the patch flat-gops-refreshing-often.pd. When turning on the [metro] and let a signle GOP square blink by clicking into the light green area, those are the CPU usages I see with different Wish versions / Pd 0.54- 0: - 8.6.12 67% - 8.6.13 65% - 8.6.11 %6 Yeah, in this particular test, 8.6.11 is 11x faster than 8.6.12! With some other tests the differences are less pronounced. When flickering a [cnv] directly in the patch (not GOP), all versions show similar CPU usages. With another patch (not included), 8.6.13 is clearly better than 8.6.12, but still beaten by a wide margin by 8.6.11. The unusual high CPU usage seems related to GOP usage. The flat-gops- refreshing-often patch holds many instances of a GOP abstraction. It performs badly even the other GOP instances are not flickering. However, when number of idling GOP abstractions is reduced, the flickering instance eats much less CPU. Miller's 0.54-0 release apparently uses 8.6.12 which - according to my tests - performs the worst of the three tested versions. This is my test env: - Pd 0.54-0 (built with 'make app') - macOS 12.6.3 - Wish/TclTk - 8.6.11 - 8.6.12 - 8.6.13 My test builds and some test patches are included here: https://netpd.org/~roman/tmp/wish-speed-macos.tar.gz Cheers Roman

1 0

how to have the same help file for different abstractions?
by Alexandre Torres Porres 13 Jul '23

13 Jul '23

Hi, when compiling objects we can use "add creator" or "set help file" so you can have the same help file for a group of objects or creating aliased/abbreviated versions of an object. There's no way to do this with abstractions though. I also know there's no way to do something like this right now and that we'd need some new object or external - maybe something in the realm of iemguts, like a nem 'canvassethelp' object. I could code an external but I have no idea how to start or where to go... help me wizards please thanks

2 1

help building string for an external
by Alexandre Torres Porres 10 Jul '23

10 Jul '23

So, i have a code that I copied from ceammc's sfizz~ for my new sfz~ object to load alternate tunings. The object loads SFZ soundfont files All we need is a string into a built in sfizz_load_scala_string function. The string is tuning name, number of steps and steps in cents in this format "weird\n4\n155\n555\n777\n1111\n" So I am trying to build this string from a list of intervals in cents and it is failing, but trying the string above works! The code from ceammc's sfizz~ uses this structure and if I print the string in the code I do get something that looks exactly like a string that gets accepted, but trying to build this string this way fails somehow (while it must work for ceammc maybe, haven't tested) *char* scale[2048] = "autogenerated scale\n"; *char** pscale = &scale[0] + strlen(scale); pscale += sprintf(pscale, "%d\n", ac); *for*(*int* i = 1; i < ac; i++) pscale += sprintf(pscale, "%f\n", atom_getfloat(av+i)); So I am here asking for some other strategy to build this string or a way to fix whatever could be wrong here. thanks

1 3

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