Pd-list March 2014

pd-list@lists.iem.at

85 participants
111 discussions

[PD-announce] NordiCHI'14 call for late submissions - Music / Sound Art Performances
by Koray Tahiroğlu 18 Mar '14

18 Mar '14

Apologies for cross-postings, please distribute. For the first time, NordiCHI conference invites submissions of provocative, sophisticated, fun, fast and foundational music/sound art performances for the performance program of the conference, which will take place as part of NordiCHI’14 in Helsinki, October 26-30th 2014. We strongly encourage submissions that represent a diverse range of practices in any form of live music/sonic art, exploring artistic and aesthetic aspects of interaction and interface design. Deadline for submissions: August 14, 2014 http://nordichi2014.org/submissions/performances/ ******************************************************************************************* 8th Nordic Conference on Human-Computer Interaction (NordiCHI) 26 - 30 October, 2014 Helsinki Finland web: http://nordichi2014.org/ facebook: https://www.facebook.com/pages/Nordichi-2014/673706125987025 twitter: https://twitter.com/NordiCHI2014 ******************************************************************************************** In collaboration with ACM SIGCHI, NordiCHI'14 is the 8th Nordic Conference on Human-Computer Interaction. The conference takes place in Helsinki, Finland, October 26-30, 2014, and contributions from all over the world are welcome. We expect 400+ participants from 30+ countries, and Don Norman will give the opening keynote. More info: http://nordichi2014.org. ------------------------------------- M.Koray Tahiroğlu Department of Media, Aalto University School of Arts, Design and Architecture http://sopi.media.taik.fi/ http://mlab.taik.fi/~korayt tel. +358 50 4088441 _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift"
by Dan Wilcox 18 Mar '14

18 Mar '14

It's not possible to overload the function? aka 1 that takes 5 args and another that takes 7? From what I can tell, the usual style within the pd core has been to add new args to the end so that backwards compatibility isn't sacrificed. Then again, I don't know the details in this case ... With libpd, so far, we've avoid trying to make any large, incompatible changes to the core. Mainly, at least IMO, because we do not want to end up diverging to the point to where we'll never be able to get said changes upstream. At this point, I'd love to sit down with a bunch of you and work out a proposed roadmap to separating gui & pd core so that libpd could become the standard core between flavors. I haven't delved into the core enough to know if that is a foolish idea, but it really seems like a great idea to standardize some of the functionality ... On Jan 12, 2014, at 5:55 PM, pd-list-request(a)iem.at wrote: > From: Jonathan Wilkes <jancsika(a)yahoo.com> > Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be "pdtk_canvas_sendkey name state key iso shift" > Date: January 12, 2014 at 5:54:49 PM EST > To: pd-list(a)iem.at > > > On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote: >> Hi, >> >> This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it. > > But notice the error tells the user that the proc expects five args, and not seven args like your revision of pdtk_canvas_sendkey. This is because matju told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably has to do with unicode support. I say that because you can find it in the Gridflow source file named "unicorn.cxx" (which is also funny in itself). > > So if you can figure out what it's doing, you can try to merging it into Pd-l2ork or at least make it compatible with it. But there are probably several other places where matju drilled into Pd's walls from the outside, and they probably conflict with Pd-l2ork's renovations. (Probably the widgetbehavior struct and comment struct conflict.) > > -Jonathan -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

20 75

Tannhauser Pure Data compiler
by Ingo 18 Mar '14

18 Mar '14

I just found out about the "Tannhäuser Pure Data compiler". Does anybody know who makes it or where to get this compiler? Thanks! Ingo

7 9

Interface bug switching to edit mode with sub patches
by Jaime E Oliver 17 Mar '14

17 Mar '14

Hi, In os x 10.8.5 with Pd 0.45-4, when I save a patch that has a sub patch and this sub patch is open, the next time that I open it I have the following behavior: + Both the parent patch and sub patch are loaded, but the parent patch shows up in front. + Although the parent patch shows in front of the sub patch, I cannot switch from edit to run mode unless I close the sub patch behind it. It seems like the edit mode switch is being applied to the sub patch which is not the frontmost window and the correct behavior is that the frontmost window is being addressed by commands. I cannot test this in linux now, but I imagine some might. To test, open the attached patch and see if you can switch to edit mode… best, J

2 2

Re: [PD] HD 1920 X 1080 (Mateo De Los R?os)
by olm-e 17 Mar '14

17 Mar '14

> Message: 4 > Date: Thu, 13 Mar 2014 18:12:44 -0500 > From: Mateo De Los R?os <mdlrmailinglists(a)gmail.com> > Subject: [PD] HD 1920 X 1080 > To: pd-list(a)iem.at > Message-ID: > <CAL=GbT4p6wfO8eSg35SvBWA-UCaMucZt_sbaKJz_vupsFuVsQw(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > > > I'm trying to load a video in full HD 1920 X 1080 with [pix_film] to > texture a rectangle. > > > > Quicktime movie .mov > > Size 1920 X 1080 > > > I reduced its format size to HD 1280 X 720 and now [pix_film] is able to > open it but reproduction is slow and choppy. > > > > I use [pix_film] to load Quicktime (.mov) DV 780 X 420 videos and they run > perfectly.The same setup won't work with 1920 X 1080. > > > > I work on OS X 10.9.1 and Pd-Ext 0.43.4 extended. > > > > How can I load videos in full HD 1920 x 1080 in order to texture > effectively? > > > M Hello, to my experience, at least on linux, it is hard to keep good framerate with the current implementation of pix_film and HD files, regardless of the format, and it plays far better using pdgst library. https://github.com/umlaeute/pdgst although it still need some polishing (for controlling the playback of a file f.ex. ) the displaying of even multiple movies in full HD mpg4 or mjpg is fluid with it ... (I did a small fork of it on github - https://github.com/Olm-e/pdgst - to play with the code and added the seek parameter so you can control the playhead and speed ... but it still needs some stuff like being able to get the length of a movie to know when to stop, loop, etc ... Iohannes, maybe you can look at this a bit ?) hope it helps, Ol.

3 2

friendly reminder that osx pd-extended is still badly flawed
by i go bananas 17 Mar '14

17 Mar '14

every time i open a patch from clicking on an icon, PD loads 2 patches. pretty sure this is a long standing issue that hasn't been fixed. (os-x)

5 6

Hello Problem with [pix_film]
by bobo ginov 17 Mar '14

17 Mar '14

Hell everyone, i have problem with rendering video files with gemhead. The particular error is Unable to connect filters -2147220969. I work with windows laptop - intel core i5, geforce 310m with updated video drivers. I have quicktime but still it does not working. I will be thankful for any advices and ideas to solve the problem. This error have two more laptops of my colleagues. Thanks and have a nice week :)

1 0

Re: [PD] friendly reminder that osx pd-extended is still badly flawed
by Dan Wilcox 17 Mar '14

17 Mar '14

He's on 10.6, so it's not this: http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 > From: Alexandre Torres Porres <porres(a)gmail.com> > > it's an OS thing, you can set it somewhere so it doenst open the latest files, someone showed how to do it here, cant remeber though :P -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

1 0

Re: [PD] friendly reminder that osx pd-extended is still badly flawed
by Dan Wilcox 17 Mar '14

17 Mar '14

He's on 10.6, so it's not this: http://puredata.info/docs/faq/help-pd-crashes-on-startup-on-mac-osx-10-7 On Mar 17, 2014, at 1:26 AM, pd-list-request(a)iem.at wrote: > From: Alexandre Torres Porres <porres(a)gmail.com> > Subject: Re: [PD] friendly reminder that osx pd-extended is still badly flawed > Date: March 17, 2014 at 1:26:06 AM EDT > To: i go bananas <hard.off(a)gmail.com> > Cc: PD List <pd-list(a)iem.at> > > > it's an OS thing, you can set it somewhere so it doenst open the latest files, someone showed how to do it here, cant remeber though :P -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com

1 0

Re: [PD] Rewriting a unified phasor / metro object for reading tables
by Roman Haefeli 15 Mar '14

15 Mar '14

(I believe this might rather belong to pd-list instead of pd-dev) On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: > Roman, > > >> wrapping points. The only drawback compared to [phasor~] is that > the > >> latter allows to control the frequency with a signal and the > >> [metro]/[vline~] based phasor obviously doesn't. > I never did quite figure it out but how do you do more advanced things > with [vline~] such as updating/increasing ramp speed mid ramp? Frankly, I often find myself struggling with those kinds of problems. > >> I'll be glad to help you build the [phasor~] replacement that has > an > >> additional bang outlet, if you need it. > > Are you saying this is possible with just metro/vline~ combo? I would > be curious what that looks like if you did build it.... It wasn't as easy as I initially expected it to be. I already had a [metro]-like abstraction that can do intra-interval tempo changes. However, I figured it was buggy (it worked only for the first tempo change within an interval) and had to redo it. That was the most difficult part. Combining it with [vline~ ] to make a [vphasor~ ] with extra bangs at each wrapping point wasn't as hard (at least not with its current limitations). Check attachment. Roman

2 2

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →

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 March 2014