Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

-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

Re: [PD-dev] plans for next Pd release
by Sebastian Shader 14 Jul '21

14 Jul '21

I have a couple of bugfix prs that would be nice to get merged -clipping GOP objects correctly when their distance is changed using the "font" dialoghttps://github.com/pure-data/pure-data/pull/1247re-do tcl/tk key repeat bugfix for tk 8.6.11https://github.com/pure-data/pure-data/pull/1306 I understand if the feature request prs won't make it in but the color hooks has been sitting around for a few years now & I think it's ready to go, aside from some whitespace issues possiblyhttps://github.com/pure-data/pure-data/pull/196there's another small feature prhttps://github.com/pure-data/pure-data/pull/1324 thanks, -Seb -----Original Message----- Message: 1 Date: Tue, 13 Jul 2021 10:22:17 -0700 From: Miller Puckette <msp(a)ucsd.edu> To: pd-dev(a)lists.iem.at Subject: [PD-dev] plans for next Pd release Message-ID: <20210713172217.v4ch3b3dk7go7k5q(a)ucsd.edu> Content-Type: text/plain; charset=us-ascii (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

2 2

Question about prepping Scheme for Pure Data external for Deken?
by Iain Duncan 12 Jul '21

12 Jul '21

Hi folks, I'm able to spend some time on Scheme for Pure Data again over the next couple of weeks, and just wanted to check on what I need to have done to make it easy to install through Deken. For Max, I had to have successfully compiled binaries for Mac, Windows 32, and Windows 64. Is it the same for Pd? I assume Linux users will get things either by compiling from source or a a linux package manager? thanks! iain

2 1

building with pdlib builder on windows
by Iain Duncan 26 Jun '21

26 Jun '21

Hi folks, I know windows just enough to be dangerous to myself, but would like to at least be able to prepare binaries of s4pd. Wondering what the path of least resistance is to compiling on windows these days if I'm using pd lib builder. ie mingq, cygwin, virtual studio?? thanks iain

3 5

Re: [PD-dev] More clock questions
by Sebastian Shader 15 Jun '21

15 Jun '21

>1) Is the Pd clock scheduler only accurate to the ms or does it operate at>higher than ms accuracy? (As in, if I wanted to role my own mechanism >closer to what Seb did, how frequently should my master time go off?) from what I can tell Pd seems to use its own unit of time in order to interface better with the audio side of things, (but it's stored in a double)lua uses double for it's numbers, and I just used milliseconds (partially because the pd clocks seem to work/have worked with milliseconds primarily/historically) I'm not sure I understand "how frequently should my master time go off?" You have the clock callbacks stored in the priority queue, and use the scheduled time (in ms) for the keys the queue is sorted by.So in order to "start a delay", you put a callback on the queue. Then to start your scheduler, call the underlying t_clock delay with the value of the difference between the time of the top value in the queue (which will be the earliest callback because you set up the priority queue to sort as a min-heap, so that the lowest times get popped out first) and the current time.Every time you return from the underlying t_clock callback, increment your own time by the amount the underlying t_clock was called with/delayed for (in milliseconds stored in a double, in my case). The nice thing about using t_clock is that you don't need to implement the delay part yourself, just the priority queue and figuring out when to start and stop it. (along with dispatching the callbacks associated with members in the queue, wherever those go.) What I do is put my "main thread" on the queue to start. Every time another thread/coroutine is started/sprouted it gets added to the queue. Whenever a delay is encountered the current thread will be at the top of the queue, so you just have to change the delay time and call some downheap() function on the heap to restore the heap property after changing the delay time in the priority queue member. (then delay the t_clock by the new top member of the queue)Every time a coroutine finishes I take it off of the top of the queue. (and call another t_clock delay for the new top member, or stop if there are none left) -Seb -----Original Message-----Message: 2 Date: Sat, 12 Jun 2021 11:11:12 -0700 From: Iain Duncan <iainduncanlists(a)gmail.com> To: pd-dev <pd-dev(a)lists.iem.at> Subject: [PD-dev] More clock questions I have a couple more clock/schedule related questions after rereading the comments from Miller and Seb. 1) Is the Pd clock scheduler only accurate to the ms or does it operate at higher than ms accuracy? (As in, if I wanted to role my own mechanism closer to what Seb did, how frequently should my master time go off?) 2) Miller made reference to the linked list of clocks that pd iterates through. Is that something I could access directly? (and if so, where would it live? 3) if anyone knows good books or online resources for learning more about writing scheduler related code, I'm all ears! :-) thanks iain

2 2

Re: [PD-dev] [PD] Ability to access error messages from patch
by Dan Wilcox 15 Jun '21

15 Jun '21

Some quick thoughts on my end. # error outlets Let's say.... if we were to consider adding some sort of "standard outlet" for errors, how many objects are we talking about? I assume not every object but perhaps those which read/write files and the net objects? That's not so many, really. I already added a general "info" outlet for [soundfiler] which could easily be extended by outputting an error list ala "error # msg symbols..." or simply "errno." One negative is that this sort of approach becomes relatively arbitrary and supported by only a few objects, some which may have a dedicated error outlet and others which may have a generalized outlet with some sort of error list selector etc. OTOH the growth of Pd's objects over time has ensured this kind of "arbitrariness" is part and parcel, so maybe it is less so. A positive point is that it's relatively easy to communicate and work with. For instance, we have this paradigm to a small degree where [netrecieve] will output a 0 if the connect message failed. # errno object As Pd is more or less structured after C to some degree, I like the idea of formalizing something like errno and simply using the standard defined error numbers. At least there is something already to use, however the standard values are probably not enough to cover all cases but at least "can't open file" or "unsupported parameter" etc are there. This would force a certain design paradigm where you need to do A then check error, then maybe do B and check error, etc. Sure, that's how you do it in C, for most things, but it's also a lot of boilerplate and boilerplate is much more annoying in a patcher. # (sub)patch errors I find a sub(patch) level error object enticing, ie. anything in this (sub)patch will throw an error to this object. I think IOhannes called them exceptions, but I would avoid that naming as I assume it will not halt or crash Pd if the error is not handled. Like errno, this would force a certain design paradigm where you need to group object + error object all the time. In some cases it wouldn't bother me and in others I'd find it annoying. It would be simple to communicate however and relatively easy to integrate into Pd by, I assume, a new API call where objects can raise a "patch level" error as opposed to global stdout/stderr all console. > On Jun 14, 2021, at 11:25 PM, pd-dev-request(a)lists.iem.at wrote: > > Method calls which can generate an error send the error code to a global > [errno] object and the user can query the current error state with a > bang. This would be similar to 'errno' in C. > > If the user queries the errno immediately after the method call, Pd's > determinism guarantees that the error really belongs to that method > call. We would have to reserve a special value (e.g. "0") to mean "no > error". > > My main point is that errors should not be *sent* by global or > canvas-local objects, but that they should be *queried*. This way the > user doesn't have to deal with cross talk between different objects. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

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