Pd-dev June 2023

pd-dev@lists.iem.at

13 participants
10 discussions

MIDI problems on linux
by Miller Puckette 26 Jun '23

26 Jun '23

I'm having trouble getting "oss MIDI" (that is, access to /dev/midi*) working in linux. Whereas in 0.53 I get choices "none", "/dev/midi3", "/dev/midi4", "/dev/midi5", on 0.54 I get an extra entry, "(no device)". When I select "midi4" for example, the next time I open the dialog it shows "midi3". I think too that it' actually trying to open midi3, not midi4. Commits that might be of interest are a0b74340313d26a430c145a421c7e5660b38d1cd (fixed off-by-one errors in MIDI-dialog) and dfaba7072c0bdae2e97a94f91f0e0a11f97f6687 (handle non-existing selection when showing midi devices) -- although these are dated 2021 I appear to have only merged them for 0.54. I don't know how to figure out what PR they came from. Meanwhile one minor thing: when selecting "alsa midi" dialog the number of devices comes up 0 and 0, even if I had set them to 2 and 2 in the command line ("-alsamidi -mididev 1,2") - this is minor except that Pd unhelpfully closes the existing MIDI devices when the dialog is started. I'm scared to try to fix these as I'm sure I'll break something else if i do :) thanks Miller

4 4

Re: [PD-dev] double precision pd?
by Dan Wilcox 13 Jun '23

13 Jun '23

>> On Mon, 2023-06-05 at 11:46 +0200, Miller Puckette wrote: >> Pdouble? > > Pd? pdpd? enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com

6 7

Re: [PD-dev] double precision pd?
by Dan Wilcox 12 Jun '23

12 Jun '23

My gut feeling is that this is best kept as two separate builds for the platform. IMO we don't want to have to resort to a lot of trickery fighting the system's preferred modus operandi as it will, as you write, likely blow up in our faces. > On Jun 12, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Mon, 12 Jun 2023 09:08:36 +0200 > From: IOhannes m zm?lnig <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] double precision pd? > Message-ID: <d02ebe17-dce6-98a3-b55c-0f923c5f79ec(a)iem.at <mailto:d02ebe17-dce6-98a3-b55c-0f923c5f79ec@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/8/23 15:23, IOhannes m zm?lnig wrote: >>> Oh no, compilation will be complex. >> >> Not really. >> You basically have to build twice... > > oh no, i forgot about the intricacies of the windows build. > > with macOS and Linux we have this nice single "pd" binary (or "pd64"). > but with Windows we need the supporting pd.dll library where all the > guts live (so externals have something to link against), and as of now, > double-precision externals on Windows will link against pd.dll as well > (but expect that to be contain the double-variant). -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

double precision pd?
by Alexandre Torres Porres 12 Jun '23

12 Jun '23

Hi, with pd 0.54-0 round the corner, what is still preventing us from shipping double precision pd downloads? been waiting on it for a while now cheers

9 14

Re: [PD-dev] double precision pd?
by Dan Wilcox 10 Jun '23

10 Jun '23

It will work and I don't think separate apps would be needed. The executable within the .app bundle (Contents/MacOS/Pd) is just the renamed Wish executable which calls the Tk GUI which, in turn, starts the pd core which could be either 32 or 64 bit float precision. This could be selectable via a GUI preference which would take effect on app restart. A bigger issue might be if the core is also sending 64 bit doubles to the GUI but the GUI is not set up for that, although I don't believe that is the case as, at that point, things are sent as stings, ie. the contents of a wide float atom. > On Jun 9, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > For the macOS app, I don't know whether it will work (but of course the downloadable dmg could provide both apps, and it might compress well enough that the additional content won't be a problem) -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] double precision pd?
by Dan Wilcox 08 Jun '23

08 Jun '23

Yeah, after batting names around, I think "pd64" is the simplest even if it potentially runs into architecture naming. It's definitely true we are well past the 32 - 64 bit transition at this point anyway. If it worked for CSound it can work for us and, really, most other naming is clunky IMO. This just needs a good explanation so the usage of 64 is clear: 64-bit double precision floats and support for very long sound files (via CAF). > On Jun 8, 2023, at 11:15 AM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Wed, 7 Jun 2023 16:42:53 +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] double precision pd? > Message-ID: <5cf4aa6d-c70e-8fd3-993a-e4d1b49d1f89(a)iem.at <mailto:5cf4aa6d-c70e-8fd3-993a-e4d1b49d1f89@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 6/7/23 12:55, Antoine Rousseau wrote: >> Le mer. 7 juin 2023 ? 10:47, Lucas Cordiviola <lucarda27(a)hotmail.com <mailto:lucarda27@hotmail.com>> a >> ?crit : >> >>> For me pd64 gives more chances of confusion than pdd or pdpd. >>> >> (...) >> >>> Starting with a new name of the app seems the most sane. >>> >> >> Funnily, my personal feeling is the opposite :-) >> I feel that Pd64 clearly describes Pd working with 64 bit data. > [...] >> >> To me, "pdd" or "pdpd" really sound like different apps, which I find a bit >> strange (it's actually the same app, only different options). > > that's also my personal feeling. > > double-precision Pd ist just a variant, and pdpd is hard to read (once > you leave the Pd universe). > > on my system i can install "libpdl, libpdb-redo, libpda-* packages, and > I'm not overly enthusiastic about finding a "libpdpd" in this list. > probably the library version is not so important, so with applications > it is: "pdal, pdd, pdf, pdl, pdb", and having a "pdpd" in there seems > also hard to sport. > > my brain is just faster with keeping number (like "64" or "2") apart > from alpha-chars... > > >> I quite like Pd? or even Pd2, though. > > i like them too, esp the "Pd?" looks good and has a nice ring, but of > course this is not an ASCII-compatible name and thus a no go. > > with Pd2, i guess people will wonder when they missed the v1.0 release > of Pd though (something I don't see happening with Pd64). > > > as a reference, the venerable Csound (which i think has been using > double precision as the internal data representation for >10 years no), > is (still) using csound64 (as in "csound64.dll") for the > double-precision (even though it no longer offers any single-precision > variant). > afaict this is independent from "64bit architecture" (but it seems they > no longer provide any 32bit architecture downloads (e.g. for Win32)) > > so in the long run, i think that 32bit architectures will no longer be > relevant on any download page (i guess the only 32bit architecture that > will stay relevant for some time is armv8; but there are no downloadable > binaries on any homepage anyhow; and a package manager like "apt" picks > the "correct" version of Pd anyhow) > > > i think one of the questions is, where the name will actually be exposed. > > - of course, the webpage (https://msp.ucsd.edu/, https://puredata.info/) > cou use whatever descriptive name to lure the people into downloading > the right package. > - personally I'm mostly concerned with package managers (and as said > above: all package managers I know of have a way to handle the > architecture (amd64, i386) more or less transparently) > - then there's the binary you run on your computer -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Suggestions for 0.54
by Alexandre Torres Porres 06 Jun '23

06 Jun '23

Ok, merging season is on and people have been suggesting PRs and there's lot of actions on the github repository. Here's my curated list to you Miller. First, something that I hope we cannot wait any longer as I first reported this bug like, I dunno, in version 0.46 :) a fix has been sitting for quite a while. This PR allocates the correct buffer size for delays based on the actual block size and is really important for some patches ==> *delwrite~: allocate extra space based on actual block size* https://github.com/pure-data/pure-data/pull/708 This is a nice fix that affects me with my tutorial and allows more colummns to be displayed, should be worry free I guess ==> *allow helpbrowser to display any amount of columns* https://github.com/pure-data/pure-data/pull/1240 *And now some PRs and features by myself...* Some features for [pdcontrol] (and I just pinged you about it on github for it) https://github.com/pure-data/pure-data/pull/828/ *allow flags to come first in [text sequence] * https://github.com/pure-data/pure-data/pull/1581 <== I actually consider this a bug (not as a feature as marked), it is not the way things usually work and it is in conflict with the way things are documented Some cool, useful and simple features: - load seeds based on system time for pseudo random number generators https://github.com/pure-data/pure-data/pull/1719 - Add font size argument for [drawtext] https://github.com/pure-data/pure-data/pull/1622 - [oscparse] improvements https://github.com/pure-data/pure-data/pull/1623 - Add channel inlet/outlet & argument for [makenote] https://github.com/pure-data/pure-data/pull/1670 Here's an old one that is more problematic: add an inlet to [receive] https://github.com/pure-data/pure-data/pull/604 it needs another PR which is "make pd_unbind safe" https://github.com/pure-data/pure-data/pull/1760 *This one need to solve conflicts, I'll try to find time and do it right away, but tell me if I shouldn't bother maybe* add '-h' flag for hexadecimal color in Data Structures. https://github.com/pure-data/pure-data/pull/1621 ------------ No pull requests but issues and requests I'd hope we could deal with but I know it might be too late in the game use same properties for horizontal/vertical versions of slider and radio https://github.com/pure-data/pure-data/issues/1757 (hopefully IOhannes could do this one) allow data through signal connections ==> https://github.com/pure-data/pure-data/issues/1887 This is a quite old issue that I'd just hope we could have some attention https://github.com/pure-data/pure-data/issues/234 Cheers

1 1

sqrt/(not q8_sqrt) for 0.54
by Sebastian Shader 05 Jun '23

05 Jun '23

As long as we're bringing attention to things to get into 0.54, it would be nice to finally resolve the sqrt/q8_sqrt differenceshttps://github.com/pure-data/pure-data/issues/1906https://github… the osc/cos symmetry stuffhttps://github.com/pure-data/pure-data/issues/105https://github.com/pu… -seb

1 0

Pd 0.54 macOS stuff etc?
by Dan Wilcox 05 Jun '23

05 Jun '23

Howdy all, if we are in a release cycle, is there anything major I can look at? I’m thinking of Tk 8.6.13 for macOS builds, etc. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com

1 0

Re: [PD-dev] double precision pd?
by Dan Wilcox 05 Jun '23

05 Jun '23

I agree the “64” naming, while technically correct, will just get mixed up with architecture. Too bad “dp” is already used by pddp. I now think of “wide” pd but that’s perhaps too general, although could be fun. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com > On Jun 5, 2023, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 3 > Date: Mon, 5 Jun 2023 11:44:54 +0200 > From: IOhannes m zm?lnig <zmoelnig(a)iem.at> > To: pd-dev(a)lists.iem.at > Subject: Re: [PD-dev] double precision pd? > Message-ID: <0891ab25-d572-828b-881a-cef4cc65c300(a)iem.at> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> On 6/4/23 17:22, Alexandre Torres Porres wrote: >> well, great then, cause it's been merged :) time to get ready for double >> precision finally then I guess! Really excited about it <3 > > > the other question that ought to answered is: how do we actually call it > in order to prevent confusion? > > "Pd double precision" is a bit clumsy. > > "Pd64" is terser ("pd64.exe", "libpd64.dll"; and that's what I called > the tentative double-precision packages for Debian/Ubuntu/... for now) > but of course there might be some confusion with amd64/x86_64/arm64...

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