Pd-dev October 2024

pd-dev@lists.iem.at

7 participants
5 discussions

puredata jack audio crashes using pipewire-jack with more than 15 channels under Linux/Debian
by Winfried Ritsch 09 Oct '24

09 Oct '24

Hello, Using Debian bookworm backport puredata and pipewire-audio and pipewire-jack backports, it crashes with 16 channels, but not with 15 channel. To narrow down the problem, before bug issue it, anybody the same or only system specific ? Here the debug output: Here the gdb output: $ pd -version Pd-0.55.1 ("") compiled for Debian (0.55.1+ds-2~bpo12+1) on 2024/09/22 at 20:24:41 UTC $ gdb pd ... (gdb) run -jack -channels 16 Starting program: /usr/bin/pd -jack -channels 16 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Detaching after fork from child process 55024] [Detaching after fork from child process 55027] [New Thread 0x7ffff74a56c0 (LWP 55028)] [Thread 0x7ffff74a56c0 (LWP 55028) exited] [New Thread 0x7ffff74a56c0 (LWP 55029)] [New Thread 0x7ffff6ca46c0 (LWP 55030)] [New Thread 0x7ffff639f6c0 (LWP 55031)] double free or corruption (out) Thread 5 "data-loop.0" received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff639f6c0 (LWP 55031)] 0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... bt #0 0x00007ffff7be3e3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7b94fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff7b7f472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff7bd8430 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007ffff7bed7ba in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x00007ffff7bef820 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00007ffff7bf1e9f in free () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x000055555567ec3a in ?? () #8 0x00007ffff7d952c7 in ?? () from /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so. 0 #9 0x00007ffff7faa44e in ?? () from /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa- support.so #10 0x00007ffff7a971b0 in ?? () from /lib/x86_64-linux-gnu/libpipewire-0.3.so.0 #11 0x00007ffff7be2144 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #12 0x00007ffff7c627dc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) watchdog: signaling pd... watchdog: signaling pd... ... kernel: 6.1.0-26-amd64 mfg winfried -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik, University of Music and Dramatic Art Graz - mobil: ++43-664-2439369 Tel. ++43-316-389-3510 (3170)

5 11

Re: puredata jack audio crashes using pipewire-jack with more than 15 channels under Linux/Debian
by Dan Wilcox 08 Oct '24

08 Oct '24

> On Oct 8, 2024, at 11:28 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Tue, 8 Oct 2024 09:49:09 -0500 > From: Miller Puckette <mpuckette(a)cloud.ucsd.edu <mailto:mpuckette@cloud.ucsd.edu>> > Subject: [PD-dev] Re: puredata jack audio crashes using pipewire-jack > with more than 15 channels under Linux/Debian > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Message-ID: <e30022b2-ccff-4b23-b03d-8fdcc7775f6f(a)cloud.ucsd.edu <mailto:e30022b2-ccff-4b23-b03d-8fdcc7775f6f@cloud.ucsd.edu>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > This might be serious enough to warrant putting out 0.55-2. I would like a new bug fix this for the libpd fixes as well... -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] Re: Lua in pd
by Dan Wilcox 03 Oct '24

03 Oct '24

I don't agree that Lua version are that much different. The API is pretty stable. Funny, I've regularly updated Lua for my openFrameworks bindings, from 5.1 all the way to 5.4 over the years and have not had major issues. I think I am simply not using any real end case features to where it matters. So far SWIG is handling the bindings generation well enough and I do add whatever small shims are needed via macros, but so far that has only been on the C side. The Lua side has been stable for me. > On Oct 3, 2024, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> wrote: > On 02.10.2024 18:30, Timothy Schoen wrote: >> Currently, pdlua is not compatible with luaJIT, since it was updated >> to Lua 5.4 (and uses some of the new features internally). It's >> possible to port it back to luaJIT by taking out all the new Lua bits. >> >> Both have some advantages and disadvantages. But for me, regular Lua >> would win (but only by a small amount). The reason is: it's >> architecturally simpler, more mainstream, more widely used/tested, and >> (in my estimation) more likely to be maintained for a very long time. >> luaJIT is very fast, so I'm not opposed to it either. Having any kind >> of scripting for objects available at all is the most important thing >> here 🙂 > > If LuaJIT stopped working for whatever reason, we could still use > vanilla Lua 5.1 - which will continue to work as long as we have C > compilers :) Lua is a bit peculiar in that every minor version is really > a different language. Once you pick a Lua version, you typically don't > upgrade, unless there is some very compelling reason. > > Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or > 5.4. We just have to be aware that once we pick a version, we basically > have to stick with it because of backwards compatibility. > > Christof -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] Re: Lua in pd
by Sebastian Shader 03 Oct '24

03 Oct '24

Well, hopefully someday the allocations/processing/interpretation/compilation isn't happening on the audio thread :) I think JIT compilation shouldn't necessarily be shied away from given class/object creation isn't realtime-safe anyways, and how much slower is it actually? Imo JIT compilation to lower-level should be considered more, like for [expr~] or maybe some heavy-like patch compiler thing that can do some of what gen~ does. somewhat off-topic: there are also some cool compiled lua-inspired languages like terra and nelua (which I was thinking of switching to for the project I was using luajit/pdlua for anyways) -seb On Wednesday, October 2, 2024 at 11:39:30 AM CDT, Christof Ressi <info(a)christofressi.com> wrote: On 02.10.2024 18:30, Timothy Schoen wrote: > Currently, pdlua is not compatible with luaJIT, since it was updated > to Lua 5.4 (and uses some of the new features internally). It's > possible to port it back to luaJIT by taking out all the new Lua bits. > > Both have some advantages and disadvantages. But for me, regular Lua > would win (but only by a small amount). The reason is: it's > architecturally simpler, more mainstream, more widely used/tested, and > (in my estimation) more likely to be maintained for a very long time. > luaJIT is very fast, so I'm not opposed to it either. Having any kind > of scripting for objects available at all is the most important thing > here 🙂 If LuaJIT stopped working for whatever reason, we could still use vanilla Lua 5.1 - which will continue to work as long as we have C compilers :) Lua is a bit peculiar in that every minor version is really a different language. Once you pick a Lua version, you typically don't upgrade, unless there is some very compelling reason. Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or 5.4. We just have to be aware that once we pick a version, we basically have to stick with it because of backwards compatibility. Christof > > > Tim > > > On 02/10/2024 16:09, Sebastian Shader via Pd-list wrote: >> I know it's old but I think for lua in pd luaJit should be considered >> if adding a lua. >> Imo they took out a very powerful feature in setfenv after 5.1 anyways. >> >> Luajit was still working with pdlua last I checked. >> Plus pd messages only use floats. >> >> -Seb >> >> >> On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen >> <timschoen123(a)gmail.com> wrote: >> >> Yeah, +1 for pdlua for me! >> >> Here's a few more reasons I'd love to see this: >> >> * pdlua objects require vastly less boiler-plate code than >> C externals. Especially for signals and graphics, it takes care of >> all the hard parts and common pitfalls for you. >> >> * As a result, creating pdlua objects is much more >> beginner friendly, and experienced programmers are less likely to >> make mistakes. Not requiring compilation makes writing coded >> externals as accessible as abstractions are currently. >> >> * The biggest weakness for a project like pdlua is needing >> to be installed manually. This discourages people from directly >> uploading their Lua objects on Deken. Like porres said, ELSE now >> ships with pdlua just so that we can ship lua objects. It would be >> amazing if we could assume them to just work. >> >> * As you might know, Lua is very compact, it can be >> compiled by adding "onelua.c" to your sources, and it has no external >> dependencies. For ease of maintenance, it's as good at it gets. Lua >> is also fast for a scripting language. Seems like the perfect fit for >> pure-data. >> >> >> If you want a sample of the API, here's the documentation for pdlua >> graphics: >> https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics >> >> Tim >> >> >> >> >> On 02/10/2024 06:12, Alexandre wrote: >> >> >>> >>> >>> >>> Let me share Tim's thoughts he sent me via a chat about coding >>> externals in lua, which I think are a perfect sell. Compared to C >>> externals, lua externals: >>> * Encourages open-source, since the source code is the >>> object >>> * Works on every OS, architecture, pd floatsize, >>> multi-instance, all without needing recompilation >>> * You can easily modify objects if you want to >>> * GUIs are now much easier to write with Lua than with C >>> * Are guaranteed to keep working even if Pd's C API >>> changes, or Pd changes GUI framework >>> * Are guaranteed to work across Pd forks, as long as they >>> correctly implement the lua API >>> >>> >>> >>> >>> >>> >>> Em ter., 1 de out. de 2024 às 15:36, Alexandre <porres(a)gmail.com> >>> escreveu: >>> >>> >>>> Em seg., 30 de set. de 2024 às 16:59, Christof Ressi >>>> <info(a)christofressi.com> escreveu: >>>> >>>> >>>>>>>>> Thanks to Antoine for mentioning pdlua! I will need to >>>>>>>>> check it out. I have already seen people doing some very cool >>>>>>>>> stuff with it. Maybe they already have the perfect solution :) >>>>>>>>> >>>>>>>>> >>>>>>>> I'm also looking at pdlua, which might want to become the >>>>>>>> official way to make graphical externs AND to add scripting in >>>>>>>> a fundamental way to Pd :) >>>>>>>> >>>>>> +1 for an official scripting language! :) (I love Lua, BTW.) And >>>>>> yes, it would make lots of sense to leverage the scripting >>>>>> language to implement custom UIs! >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> +1k >>>> >>>> >>>> >>>> >>>> >>>> Yay, great to hear that! BTW, I remembered about this ticket we >>>> opened years ago inquiring about adding lua to Pd >>>> natively! https://github.com/pure-data/pure-data/issues/687 >>>> >>>> >>>> >>>> >>>> Now that Tim is doing great work for graphics, this would be even >>>> more awesome! And I wouldn't have to worry in shipping it in ELSE >>>> for some externals that already use it :) >>>> >>>> >>>> >>>> >>>> cheers >>>> >>>> >>>> >>> >>> >>> >>> >>> --- >>> pd-dev(a)lists.iem.at - the Pd developers' mailinglist >>> https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB… >>> >> >> --- >> pd-list(a)lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWR… >> >> >> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ >> >> --- >> pd-list(a)lists.iem.at - the Pure Data mailinglist >> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/TJOTDRAY3… >> >> >> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.iem.at/ > > --- > pd-list(a)lists.iem.at - the Pure Data mailinglist > https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/F6CWKKSQH… > > > To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.iem.at/ --- pd-list(a)lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GY5ULQJGM… To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/

2 1

Fwd: Re: Fwd: Re: gtk front end for Pd?
by Christof Ressi 02 Oct '24

02 Oct '24

(forwarding to pd-dev :) > in Pd it's everything the drag-rectangle touches. This might not be > an issue for other people. That's what QGraphicsScene does by default! I just double checked with my level editor. Don't underestimate modern UI frameworks ;-) -------- Forwarded Message -------- Subject: Re: [PD-dev] Re: Fwd: Re: gtk front end for Pd? Date: Mon, 30 Sep 2024 21:55:54 +0200 From: Miller Puckette <mpuckette(a)cloud.ucsd.edu> To: Christof Ressi <info(a)christofressi.com> The specific thing I hate is that only things entirely inside the drag-rectangle get selected - in Pd it's everything the drag-rectangle touches. This might not be an issue for other people. cheers M On 9/30/24 9:45 PM, Christof Ressi wrote: > >>> I also hate the way every canvas I've seen does >>> rectangle-selection. Maybe you know of one I won't hate :) >>> >>> And... every widget set I've seen thinks widgets live in >>> rectangles. The second most important graphical item in Pd is the >>> patch line. Giving it a widget-style selection method? Disaster. I >>> don't think patch lines can be TK or GTK r QT or anyone's widgets - >>> imagine how those bounding rectangles would fill th screen :) > > Qt only uses bounding rectangles for the broad phase hit detection. > The actual hit detection can then be further customized for each > widget. The collision shape can be anything from a circle to an > arbitrary polygon or even a bitmap. For example, a line item only > receives a mouse event if you click on the actual line. > > In case you're talkinga about the actual graphical representation of > the selection: that's totally up to you. By default, QGraphicsScene > only notifies the selected items; you can then decide to how to > present the selection to the user. In the case of Pd, you would only > change the appearance of the selected objects (i.e. make them blue), > but not draw a bounding rectangle. > > Another nice feature about Qt's selection mechanism is that you can > use arbitrary selection shapes. For example, you can select items by > drawing an arbitary path, similar to "free selection" mode in painting > programs. That's actually a feature I've always wanted in Pd :) > >>>> >>>> Thanks to Antoine for mentioning pdlua! I will need to check it >>>> out. I have already seen people doing some very cool stuff with it. >>>> Maybe they already have the perfect solution :) >>>> >>> I'm also looking at pdlua, which might want to become the official >>> way to make graphical externs AND to add scripting in a fundamental >>> way to Pd :) > > +1 for an official scripting language! :) (I love Lua, BTW.) And yes, > it would make lots of sense to leverage the scripting language to > implement custom UIs! > > Christof > > > --- > pd-dev(a)lists.iem.at - the Pd developers' mailinglist > https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lis…

2 2

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 2024