Pd-list December 2021

pd-list@lists.iem.at

34 participants
49 discussions

Re: [PD] 0.52.0test2: window jitter on (Mac OS)
by Dan Wilcox 05 Dec '21

05 Dec '21

Howdy Phil, this may be related to a reported GOP performance problem with test2, so I copied your report to the issue on Github: https://github.com/pure-data/pure-data/issues/1488 <https://github.com/pure-data/pure-data/issues/1488> > On Dec 4, 2021, at 6:40 AM, pd-list-request(a)lists.iem.at wrote: > > Message: 1 > Date: Fri, 3 Dec 2021 21:51:19 +0000 > From: Philip Stone <pkstone(a)ucdavis.edu <mailto:pkstone@ucdavis.edu>> > To: "pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: [PD] 0.52.0test2: window jitter on (Mac OS) > Message-ID: > <BY5PR08MB642387D9F7A5DFA96FB21C03A76A9(a)BY5PR08MB6423.namprd08.prod.outlook.com <mailto:BY5PR08MB642387D9F7A5DFA96FB21C03A76A9@BY5PR08MB6423.namprd08.prod.outlook.com>> > > Content-Type: text/plain; charset="windows-1252" > > I?ve just noticed a minor weird thing with v 0.52.0test2: graph on parent windows with margins of 0 or 1 cause a visual flutter when hovering over a graphic object inside the (opened) GOP. I?m on Mac OS 10.15.7. > > Simple example: > > #N canvas 47 74 357 100 12; > #N canvas 308 115 516 183 open_me 0; > #X obj 84 4 bng 15 250 50 0 empty empty empty 17 7 0 10 #fcfcfc #000000 > #000000; > #X text 110 2 <- hover over/off of bang; > #X coords 0 -1 1 1 100 20 1 1 1; > #X restore 130 37 pd open_me; > > Increasing the border to at least 2 X 2 eliminates the jitter. > > Not of critical importance, but long ago I got into the habit of having a 0/0 margin for GOPs (don?t know why). > > > Phil Stone > Davis, CA USA -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

[Öffnen],feature request: [get] and [set] template-agnostic?
by João Pais 04 Dec '21

04 Dec '21

Hi list, not sure if this was discussed before: would it make sense for [get], [set] and other pointer-related objects to be template agnostic? That means that an object [get mytemplate x y] wouldn't need the "mytemplate" argument, and it would get the fields from any pointer it receives. This would allow to simplify the programming in some cases. The way it is now, it needs lots of duplicated code when getting elements from different struct templates. Best, Joao

2 1

Re: [PD] Pd 0.52 test 2 is out
by Dan Wilcox 04 Dec '21

04 Dec '21

Howdy MIller, Just a couple notes after checking the test2 build: On my macOS 11.6.1 system, the test2 build with Tk 8.6.12 seems to work fine, generally. Wheew! *wipes brow* The list atom and individual element editing is great. I like the [file] implementation: light wrapper on the POSIX api. # Help Browser The right-most pane seems to have an update/refresh issue. It flashes to the background before redrawing and disappears if you navigate with the keys in one of the left-hand panes. I can look into this. Also, I found that certain keybindings generate errors (not no TCL crashes), ex. undo.redo CMD+Z, etc. # gatoms Has the selection behavior changed? I see the gatom which receives the current focus now highlights but defocus seems to be inconsistent, at least to me. I would think that clicking into the atom, editing with the keyboard, then pressing enter or escape would defocus, but it doesn't. Is this new behavior? This also makes the behavior different form that of the IEM GUIs. Also, it seems the focus highlight will stay if you double click to edit an atom which highlights the text, then click on another atom. # Keybindings I also agree that MOD+4 should remain as symbol atom and list atom can use MOD+6. I imagine the reasoning is that list atom can work with symbols so it's a decent replacement anyway, but I think this works against established muscle memory for some of us. OTOH I changed the HRadio keybinding from MOD+H to MOD+J so it could consistent on all platforms and we survived (CMD+H on macOS hides the window and is not overridable, oops!)... > On Nov 23, 2021, at 7:27 PM, pd-list-request(a)lists.iem.at wrote: > > Date: Tue, 23 Nov 2021 14:06:02 -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-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] Pd 0.52 test 2 is out -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 8

0.52.0test2: window jitter on (Mac OS)
by Philip Stone 03 Dec '21

03 Dec '21

I’ve just noticed a minor weird thing with v 0.52.0test2: graph on parent windows with margins of 0 or 1 cause a visual flutter when hovering over a graphic object inside the (opened) GOP. I’m on Mac OS 10.15.7. Simple example: #N canvas 47 74 357 100 12; #N canvas 308 115 516 183 open_me 0; #X obj 84 4 bng 15 250 50 0 empty empty empty 17 7 0 10 #fcfcfc #000000 #000000; #X text 110 2 <- hover over/off of bang; #X coords 0 -1 1 1 100 20 1 1 1; #X restore 130 37 pd open_me; Increasing the border to at least 2 X 2 eliminates the jitter. Not of critical importance, but long ago I got into the habit of having a 0/0 margin for GOPs (don’t know why). Phil Stone Davis, CA USA

1 0

Re: [PD] '$0' in messages again, another proposal? (Was: Pd 0.52 test 2 is out)
by Christof Ressi 03 Dec '21

03 Dec '21

I think you're extrapolating from your particular use case. I would say most people use $0 for private variables/resources. In this case the very point is that those are not accessible from outside. If I do want to make things accessible from the outside, I wouldn't use $0 in the first place... On 02.12.2021 14:25, Antoine Rousseau wrote: > > Without the "$$" syntax, I wouldn't see the problem... > > > encouraging the use of $0 in messages, without allowing to easily > substitute with [another way to identify the abstraction] $1?.. > > > > Le jeu. 2 déc. 2021 à 13:18, Christof Ressi <info(a)christofressi.com> a > écrit : > >> So I think it's better to keep the $0/$n symmetry. >> >> I think having a "message" object is a better idea [than $$'s >> one] >> >> >> What I like with the $$ idea, is that it would provide a simple >> way to merge creation arguments with variable arguments, i.e >> compose a message with both the abstraction arguments and the >> incoming message elements. > > I have to say I quite like the "$$" idea as well, assuming that we > can take the risk of breaking a few patches (if any). > > I don't think it's a good idea to add a new object just for this > functionality. For me this would create unnecessary complexity > (you have to learn yet another object). > >> I'm not sure either. To me, both $0 and $1 etc. can be used to >> identify an instance of an abstraction. >> IMO $0 is the quick way, but has the limitation to make it >> (nearly) impossible to access members from the outside. >> That's why it often happened to me to rename an instance [myAbs] >> to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so >> I can easily access [myAbs]'s members from the parent - from >> anywhere in fact (Actually, nowadays I tend to use as few $0 as >> possible). >> If we could use $0 in messages, then the last operation would be >> more complicated (cause you couldn't simply substitute $0 with >> e.g $1). > > I agree that if we get the "$$" syntax, then it makes more sense > to use "$$0" for the $0 argument! Without the "$$" syntax, I > wouldn't see the problem... > > One downside of using "$$0" is that it wouldn't be compatible with > Pd-L2Ork / PurrData.If they have already diverged significantly, > we probably don't have to care, but otherwise... > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >

4 9

Pd 0.52 test 2 is out
by Alexandre Torres Porres 02 Dec '21

02 Dec '21

Test it out. http://msp.ucsd.edu/software.html now, Miller, I haven't seen announcements from Pd-announce for the test versions as usual, how come? I have some issues I have to report, by the way. cheers

8 40

Re: [PD] Raspberry Pi 4 HDMI outputs (Simon Iten)
by ol＠ogeem.be 02 Dec '21

02 Dec '21

Hi, I don't know about the state of pd/gem on raspi these days, but some years back I had to synch and control multiple video projections using raspi3's for a performance (with some diy servo shutter for the video projectors), and finally used omxplayer (on the framebuffer directly) and python with OSC control, as it was precise to the frame - the whole was controlled by a puredata timeline sending command by OSC to make loops, pause, jumps in the videos ... it worked nicely for days ;) you can find the messy code here : https://framagit.org/Olm-e/osc-omxplayer (probably to revise with current python/omxplayer) In this it does not support 2 screens directly (raspi3 has only 1), but omxplayer seems to support it so it's probably a matter of passing the good arguments to it (--display=2 and --display=7 ) hope it helps ;) Ol; From: Simon Iten <itensimon(a)gmail.com> > > Hi list, > > Has somebody used the two HDMI outs from PD to play two videos on two > different screens? > > I am finding infos from people doing it with omxplayer, but I need it > synced and looped. Or are there any other Linux video players that can > sync > two streams on two different monitors?

2 1

Re: [PD] documenting messages to/from Pd and dynamic patching
by Dan Wilcox 02 Dec '21

02 Dec '21

Howdy all, My feeling on this is: 1. Recognize that, despite using "private" or "unstable" internal APIs, people have been using/abusing them for years. (So far, I feel we have been recognizing this by being careful not to break things, more or less.) 2. We should document all internal messaging, at least for the sake of developer documentation. If we lump "user space" and "internal" messaging together in an open manual, then they should be clearly delineated with special placed on emphasizing what things are more or less stable and what things are not. Then the user can decide how they want to proceed. I don't see a problem if people want to play with the internals on their own machine and crash Pd... that's half the fun for such activities anyway (learning). 3. We should get a poll of which internal messages are currently in use and consider which of these could be moved into "user space" and/or replaced by a better API. I believe this thread is already providing a good list... 4. Open a technical discussion on supporting "dynamic patching" officially. It's clearly very useful even if clunky through the current workarounds. Even with [clone] there are still many use cases... > On Nov 28, 2021, at 12:25 AM, pd-list-request(a)lists.iem.at wrote: > > Message: 1 > Date: Sat, 27 Nov 2021 20:20:49 +0100 > From: Jean-Yves Gratius <jyg(a)gumo.fr <mailto:jyg@gumo.fr>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] documenting messages to/from Pd and dynamic patching > Message-ID: <f41bab20-e831-3f04-52fb-ba273b1e0daf(a)gumo.fr <mailto:f41bab20-e831-3f04-52fb-ba273b1e0daf@gumo.fr>> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > On 27/11/2021 17:19, pd-list-request(a)lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: >> ForwardedMessage.eml >> >> Subject: >> Re: [PD] documenting messages to/from Pd and dynamic patching >> From: >> Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>> >> Date: >> 27/11/2021 ? 17:01 >> >> To: >> Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> >> >> >> Two examples that come to my mind: >> >> 1) [iemguts/canvasselect] allows to (de)select objects simply by >> index. No need to emulate mouse selection with "mouse" and "mouseup". >> >> 2) canvases/objects can be moved around with [iemguts/canvasposition] >> resp. [iemguts/canvasobjectposition] >> >> Are there any other use cases for "mouse" and "mouseup"? >> > Hi. My 2 cents > > Personally, I use mouse and mouseup messages to forward multitouch > events into the patch, received? from my multitouch linux laptop. > > If those messages were blocked, all my multitouch ecosystem would be out > of order :-) . -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 8

gemwin dosn't work on Big Sur
by Csaba Láng 01 Dec '21

01 Dec '21

Dear list, is there a fix already on this issue? https://github.com/umlaeute/Gem/issues/257 or i have to use [gemglfw3window] and we have to live with it. Best, Popesz

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list December 2021