Pd-dev August 2021

pd-dev@lists.iem.at

12 participants
17 discussions

unifying loglevels
by IOhannes m zmoelnig 25 Aug '21

25 Aug '21

TL;DR i'd like to propose to unify the loglevels as used by verbose() and logpost() for unknown reasons, the values accepted by verbose() and logpost() have an offset. the current loglevels are like this: logpost(x, 0,...) -> CRITICAL logpost(x, 1,...) -> ERROR logpost(x, 2,...) -> NORMAL logpost(x, 3,...) -> DEBUG logpost(x, 4,...) -> extra VERBOSE verbose(-3,...) -> CRITICAL verbose(-2,...) -> ERROR verbose(-1,...) -> NORMAL verbose(0,...) -> DEBUG verbose(1,...) -> extra VERBOSE for Pd-0.52, christof has created an enum to use labels that are easier to read and understand (PD_CRITICAL, PD_ERROR, PD_NORMAL, PD_DEBUG, PD_VERBOSE). to add a bit of confusion, this enum is called "t_loglevel" but actually declares values that are usable by verbose() rather than logpost() i would like to have both logpost() and verbose() use the same values (which should be aliased via the "t_loglevel" enum). unfortunately, both methods are used by (a few) externals, so unifying the levels will change the verbosity of these externals. my gut feeling tells me, that i would prefer the current behaviour or logpost() (with the most severe loglevel starting at 0, rather than some negative value). alternatively, i think that a loglevel=0 should be the verbosity of [print] (aka NORMAL). however, this would change the verbosity of *all* libraries using any of verbose() or loglevel(). to see how bad a change would be, i've tried to check how many externals are actually using any of the two functions: and luckily, there are not that many externals involved. these results are based on externals i found on my harddisk * externals using `verbose()` - zexy: mostly uses verbose(1) to report errors - iemguts (canvasdelete, autoabstraction): only calls verbose() once! - triggerize-plugin, doublechord-plugin: uses verbose(10), which is "extra verbose" in all scenarios, so can be ignored) - mediasettings - hexloader - Gem - ggee (shell): uses verbose(4) which is always "extra verbose" - hcs (folderlist) - tclpd - vstplugin~ * externals using `logpost()` - hcs (ce_path, folder_list, passwd, helppath, classpath, stat, group, colorpanel) - vbap - iemnet - iemmatrix: only extra VERBOSE - maxlib: only extra VERBOSE - unauthorized: only extra VERBOSE - libdir: only DEBUG and above - mrpeach (midifile, tcpclient): only DEBUG - lua: only DEBUG - tclpd: only DEBUG - cyclone: original version uses only extra VERBOSE; porres' version doesn't use logpost() at all - creb - smlib - log i'm sure i missed many libraries, but i checked quite a few. anyhow: changing the levels used by verbose() to be "0"-based will make externals (that use verbose()) more chatty. however, afaict, Gem and vstplugin~ are the only libraries in wide use where this might actually become an issue. and i guess "vstplugin~" is being actively enough developed to fix the problem by just pushing out a new version. otoh, changing the levels used by logpost() to be "-3"-based will make externals (that use logpost()) less chatty. in general this shouldn't be a big deal (as people can always raise the verbosity to see these messages). in particular, many libraries using logpost() are very quiet anyhow (using DEBUG or extra VERBOSE), so there won't be that much change. what do you think? fdasr IOhannes

2 2

Pd breaks zexy (?)
by Roman Haefeli 24 Aug '21

24 Aug '21

Hi all I just compiled Pd from master and found that I cannot load [fifop] from zexy anymore. When loading it, I get: ~~~ error: /home/roman/Documents/Pd/externals/zexy/zexy.pd_linux: /home/roman/Documents/Pd/externals/zexy/zexy.pd_linux: undefined symbol: get_sys_sleepgrain fifop error: ... couldn't create ~~~ I believe the related commit in Pd is 95b61465. I haven't tried re-compiling zexy yet, because I am under the impression that Pd shouldn't break existing externals. I'm using 2.3.1 from Deken. Roman

3 5

-stderr garbled
by Roman Haefeli 23 Aug '21

23 Aug '21

Hi Since f16dd5ec34 (I believe) everything printed to stderr is garbled. For instance, when doing: [list a b 12( | [print] in 'pd -stderr', I get: ~~~ verbose(2): print: listverbose(2): averbose(2): bverbose(2): 12 ~~~ Without '-stderr', the print output looks fine in the Pd console. Roman

3 2

Re: [PD-dev] Pd breaks zexy (?)
by Dan Wilcox 21 Aug '21

21 Aug '21

My understanding has always been: m_pd.h is public and generally shouldn't change without some sort of compatibility coverage. Anything other .h is private. I wrote d_soundfile.h and s_net.h as private headers, but they could be included in m_pd.h to make them public for example. We could add commenting marking them as such. > On Aug 21, 2021, at 5:03 AM, pd-dev-request(a)lists.iem.at wrote: > >> Well, I've never been able to articulate a clear and complete policy... >> Roughly speaking, I'm maintaining source and binary compatibility for anything >> that uses the public API (m_pd.h) and trying not to break things that use >> private APIs (g_vanas.h, s_stuff.h and, privater still, m_imp.h"). Meanwhile >> there's a profusion of ".h" files I didn't write (d_soundfile.h, g_all_guis.h, >> etc) that I've never formed a policy for. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Passing creation arguments to newmethod
by Matt Barber 11 Aug '21

11 Aug '21

Hi dev list, Question about the syntax of creation arguments and type checking. I was working on an object yesterday, with the following setup line: grab_class = class_new(s, (t_newmethod)grab_new, (t_method)grab_free, sizeof(t_grab), 0, A_DEFFLOAT, A_DEFSYM, 0); I'd assumed that it would require grab_new() to have this declaration to match the order float, symbol as in class_new: static void *grab_new(t_floatarg f, t_symbol *s); but it only worked with the reverse: static void *grab_new(t_symbol *s, t_floatarg f); We ended up using A_GIMME, but for the future, is there a way to know the order of parameters passed to the creator? Thanks, Matt

4 6

Re: [PD-dev] plans for next Pd release
by Dan Wilcox 05 Aug '21

05 Aug '21

Personally, as this affects fundamental objects, I would do both. As this can be a workflow issue, my thinking is: * Assume vast majority of users & use cases want fixed behavior (or don't particularly care), so update objects to use new/fixed behavior by default. * Add a compatibility flag for older projects which *rely* on older behavior for *all* instances of the objects. * Add a creation argument to the objects for those cases where people rely on the old behavior for certain situations, but also want the newer behavior for most other instances. * Document the old versus new behavior in a help-patch subpath with comparisons. > On Aug 5, 2021, at 10:55 AM, pd-dev-request(a)lists.iem.at wrote: > > Date: Thu, 5 Aug 2021 10:55:38 +0200 > From: Max <abonnements(a)revolwear.com <mailto:abonnements@revolwear.com>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] plans for next Pd release > Message-ID: <265a5773-2750-af8b-22a5-d01bdc4f6483(a)revolwear.com <mailto:265a5773-2750-af8b-22a5-d01bdc4f6483@revolwear.com>> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 05.08.21 03:56, Miller Puckette via Pd-dev wrote: >> I'm using that as rarely as I can, so far only for bug fixes. I don't think >> a limit on numerical accuracy is exactly a bug. I think it's nicer to most >> users not to have them have to bother with specifying a compatibility >> version. > > Maybe make the numerical accuracy a settable variable with the current > depth as a default? (bonus: instant bitcrusher effect) -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

plans for next Pd release
by Miller Puckette 05 Aug '21

05 Aug '21

(re-send - I had sent to pd-dev(a)iem.at but that now seems to be defunct...) To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/). Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another. This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what? PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists cheers Miller

12 34

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 2021