Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

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

14 Sep '21

...which reminds me I haven't had any time to look into macOS-specific stuff (bad) such as usual TK issues, M1 arm builds, etc, due to too much project work (good). Maybe this weekend / coming week. > On Sep 14, 2021, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Mon, 13 Sep 2021 20:52:19 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Cc: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] plans for next Pd release > Message-ID: > <CAEAsFmivBpXw=kCOYO6Xjtjja8wZnKaiy3vG30cc=vHxXOFuYw(a)mail.gmail.com <mailto:CAEAsFmivBpXw=kCOYO6Xjtjja8wZnKaiy3vG30cc=vHxXOFuYw@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > hi, sorry to bug you Miller, but summer is ending and I was wondering about > the next release if it's coming soon. > > cheers -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 4

"extra" folder is not showing its content in Pd's browser.
by Lucas Cordiviola 02 Sep '21

02 Sep '21

Building the current (571ad34) on Linux/Win the extra folder is not shown in Pd's Browser. -- Mensaje telepatico asistido por maquinas.

2 4

Re: [PD-dev] writing exploits in Pd (Re: [PD] [file])
by Christof Ressi 31 Aug '21

31 Aug '21

The exploit successfully changes my MIDI settings and adds search paths, but unfortunately it crashes with a completely wiped stack before showing me the Tk dialog :-( On 31.08.2021 14:33, IOhannes m zmoelnig wrote: > On 8/31/21 1:05 PM, IOhannes m zmoelnig wrote: >> >> ¹ i wonder whether it would be possible (with Pd>=0.42) to create a >> patch that creates a gui-plugin on the fly. >> if this is true, then you can already do everything that [file] >> allows you to do - and much more. > > > like with the attached patch. > > i've tested this on Linux, macOS and Windows (where i have an msys > installation and some folders that might make the exploit work - but > which might not be present on your machine). > > running the patch will add a few search-paths to your preferences and > probably modify your MIDI-settings. > apart from that, it shouldn't do any harm (though i wouldn't recommend > to run it if you have a show tonight). > use at your own risk. > > gmasdr > IOhannes > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

5 12

-verbose vs logpost() (IOhannes m zmoelnig)
by Dan Wilcox 26 Aug '21

26 Aug '21

Maybe an additional -loglevel which allows you set the level explicitly? -verbose to me would set the log level to verbose overall & -noverbose would set it back to the default. Also tangentially, I would also bring up the handling of some of these flags which affect the state: using -verbose also sets the verbose setting which is then saved wirh the user settings. I find this annoying as I would rather have the command line flags like this be *temporary* and not affect the actual setting itself. To me changing the value directly in the GUI should (as it does now). I believe I opened an issue about this already. > On Aug 26, 2021, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > with the latter in mind, we might even use multiple "-noverbose" flags > to lower the verbosity (at least of the stderr) below post() - so that > only errors would be visible. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

-verbose vs logpost()
by IOhannes m zmoelnig 25 Aug '21

25 Aug '21

the other question that is tightly related to the "unifying loglevels" thread is, how to deal with "-verbose" resp "-noverbose". currently the two concepts ("use of '-verbose'" vs "use of logpost()/verbose()") are obviously in the same realm but somewhat independent. raising verbosity with "-verbose" will: - (obviously) make Pd more chatty, regardless of loglevels. e.g. some errors will only printed (as errors!) is "-verbose" is given - verbose() is coupled with "-verbose", as it will only ever print anything if the verbose level is not bigger than the number of "-verbose" flags present. e.g. "verbose(0)" (aka 'PD_DEBUG') will print if no "-verbose" is given but "verbose(1)" (aka 'PD_VERBOSE') will only print if the "-verbose" flag is present and "verbose(2)" will only print if Pd is invoked with double-verbosity "-verbose -verbose" i actually think this is not a bad idea (barring the actual values, sede the other thread), as "-verbose" might generate a sufficient amount of traffic between Pd and Pd-GUI to choke the system. even if the output isn't displayed (as the user just uses loglevel "2 normal"). i wonder, whether we should use the "-verbose" flag, to also suppress logpost() messages. there's two reasons: - deprecate 'verbose()' in favour of 'logpost()' - so we only have to deal with a single beast - better control about what is displayed in "-stderr" mode. when running Pd with "-nogui" (or "-stderr"), the terminal is currently flooded with high-verbose messages (compared to the Pd-console). obviously this is a hyperbole and depends on the actual patch. i do find it annoying though with the latter in mind, we might even use multiple "-noverbose" flags to lower the verbosity (at least of the stderr) below post() - so that only errors would be visible. mgsdr IOhannes PS: i don't know whether there's a question in this mail. but the entire verbose-handling is a bit annoying and i would like to make it easier to grasp.

1 0

Re: [PD-dev] [ot] asiosdk2.3 gone from steinberg's website
by Dan Wilcox 25 Aug '21

25 Aug '21

That should be it. It looks like they moved their downloads to a subdomain and the new direct URL is on download.steinberg.net <http://download.steinberg.net/> so I you are scripting and want the 2.3 version specifically: https://download.steinberg.net/sdk_downloads/asiosdk2.3.zip <https://download.steinberg.net/sdk_downloads/asiosdk2.3.zip> Maybe add this info to the asio/README.txt: https://github.com/pure-data/pure-data/tree/master/asio <https://github.com/pure-data/pure-data/tree/master/asio> ie. "You can download a specific version using https://download.steinberg.net/sdk_downloads/asiosdk#.#.zip" etc > On Aug 25, 2021, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Date: Wed, 25 Aug 2021 10:42:06 +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>" <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: [PD-dev] [ot] asiosdk2.3 gone from steinberg's website > Message-ID: <c98d37d7-fb61-659c-2525-ef74b6372356(a)iem.at <mailto:c98d37d7-fb61-659c-2525-ef74b6372356@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > i just found out on the CI that since yesterday, steinberg obviously > have removed the old asiosdk download? from their website. > > apparently a newer version can be obtained from > https://www.steinberg.net/asiosdk <https://www.steinberg.net/asiosdk> > > mgdasr > IOhannes > > ? http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip <http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip> -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] unifying loglevels
by Dan Wilcox 25 Aug '21

25 Aug '21

Sounds good to me. I agree that 0 (CRITICAL) as the baseline and the levels as an unsigned int is better. With the enum, understanding the numeric values should not be an issue moving forward. I would suggest considering a compatibility mode / compile time option to preserve existing functionality for those that *really* need it, then it can be removed later on (hopefully). I can imagine someone quickly trying to run a project with old pre-compiled externals and getting flooded with prints which they could at the least disable via some compatibility flag, however the amount of time it might take for them to figure this out could make the point moot. OTOH if adding this ends up taking too much time/focus for little benefit, by all means don't do it. :) > On Aug 25, 2021, at 10:35 AM, pd-dev-request(a)lists.iem.at wrote: > > Date: Tue, 24 Aug 2021 15:59:34 +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: [PD-dev] unifying loglevels > Message-ID: <02113e2f-d09f-6cb4-bc88-c25201fc985b(a)iem.at <mailto:02113e2f-d09f-6cb4-bc88-c25201fc985b@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > TL;DR i'd like to propose to unify the loglevels as used by verbose() > and logpost() -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

[ot] asiosdk2.3 gone from steinberg's website
by IOhannes m zmoelnig 25 Aug '21

25 Aug '21

i just found out on the CI that since yesterday, steinberg obviously have removed the old asiosdk download¹ from their website. apparently a newer version can be obtained from https://www.steinberg.net/asiosdk mgdasr IOhannes ¹ http://www.steinberg.net/sdk_downloads/asiosdk2.3.zip

1 0

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

Jump to page:

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