Pd-list October 2017

pd-list@lists.iem.at

70 participants
100 discussions

Tcl plugin add a menu to .menubar on Windows doesn't work
by abel.jerome＠free.fr 05 Oct '17

05 Oct '17

Hi, When I write a simple tcl plugin to display a menu after the "Help" menu, it appears on Ubuntu and Mac os X, but not in Windows. Example : set myfantasticmenu "fantastic" menu .menubar.$myfantasticmenu .menubar add cascade -label [_ [string totitle $myfantasticmenu]] -menu .menubar.$myfantasticmenu .menubar.$myfantasticmenu add command -label "malinette.info" -command {menu_openfile {http://malinette.info}} Any idea ? Best, j.

1 0

MCP3208 external for Raspberry Pi
by Malte Steiner 05 Oct '17

05 Oct '17

for upcoming concerts we needed analog inputs in Pure Data on a Raspberry Pi with the MCP3208 converter IC so I created an external for PD to handle the data in addition to the already existing MCP3008 one: https://github.com/HerrSteiner/wiringPD schematic and more tips around Raspberry Pi can be found on http://www.block4.com/index.php?id=167 -- Malte Steiner media artist | electronic musician http://www.block4.com E-mail:mktsteiner@gmail.com phone: +49 (0) 1775522275

2 1

purr data 2.3.2's gem on windows 10
by Py Fave 05 Oct '17

05 Oct '17

Hello List, 1. Please don't ask why i use windows. 2. please tell me if there is a better place to post about this. 3. i installed purr-data 2.3.2 (and other versions before) on windows 10 (x64). gem is included but i startup i get : GEM: image loading support: SGI only and i can't find a way of loading jpg or movies in gem. if i load example pix_film opr pix_movie, i get verbose( 0):[pix_movie]: AVI supportverbose( 0):[pix_movie]: image support [pix_film]: unable to open file: C:/Users/PC-VonoXS/Desktop/pour josep/capture014_type1.avi (standard dv file , that used to work on pd-extended) but gem 93.3 is quite old , especially for glsl stuff. even for alea.mpg or other files I converted an image to sgi format and it works. so it seems there is a problem in gem plugins (except for sgi input) any hint welcome, i can feedback if needed. i already tried a lot of versions of gem, pd , such as this one https://github.com/avilleret/Gem/releases/ without success, but it doesn't seem very far from working state. in fact, what is the better solution to get a working and recent gem on windows? Thanks Py

4 6

Style the Pd html documentation
by abel.jerome＠free.fr 05 Oct '17

05 Oct '17

Some people try to write pd htlm documentation with a single file (pandoc) : https://github.com/pure-data/pure-data/pull/171 I would like to suggest to make it easier/pleasant to read, and design some css selectors + responsive layouts. A first step to see if you are interested to go further : http://reso-nance.org/public/pd-doc/ Here, I use a very nice and light css framework build by W3 (https://www.w3schools.com/w3css/). Jérôme

2 1

Fwd: Re: why not Purr Data?
by Ivica Bukvic 03 Oct '17

03 Oct '17

Forgot to copy list... -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico(a)vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu ico.bukvic.net ---------- Forwarded message ---------- From: "Ivica Bukvic" <ico(a)vt.edu> Date: Oct 2, 2017 23:06 Subject: Re: [PD] why not Purr Data? To: "Roman Haefeli" <reduzent(a)gmail.com> Cc: On Oct 2, 2017 14:07, "Roman Haefeli" <reduzent(a)gmail.com> wrote: On Mon, 2017-10-02 at 15:53 +0000, Jonathan Wilkes wrote: > > Many of my patches that I developed on Pure Data don't run without > > modification in Purr Data. Some crash at loading, some look > graphically > > weird > > Typically, "crashers" and "freezers" get fixed pretty quick in Purr > Data. > > The only freezer I remember with one of your patches was due to a > broken object triggering an infinite loop in your patch's [until] > object. I'm > pretty sure that was an alpha or beta version, and I'm pretty sure I > fixed > whatever object it was that wouldn't create. > > I don't see any other relevant crashers listed on the tracker: > > https://git.purrdata.net/jwilkes/purr-data/issues > > What am I missing? Nothing and I am sure you'll fix anything quickly. I didn't mean at all to doubt your sensible care about Purr Data. It's certainly well maintained. I haven't reported as it seemed too tedious work for not being easily able to support Purr Data anyway. Many patches would require to move sliders and other widgets inside GOP windows around for them to become visible, which would make them invisible again in Pure Data and I can't remember other things that are not bugs, but design decisions. For me, supporting both of them is a lost case, so I decided for one. This is why Pd-l2ork/Purr-Data has had for at least 2-3 years the -legacy startup flag that ensures iemgui widgets are inconsistently offset to match the vanilla behavior plus some other similarly inconsistent behaviors... If supporting pure vanilla patches to their full extent would be a stated goal of the Pure Data project, I'd have some incentive to report stuff, but it seems it isn't. Roman _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list

6 7

Re: [PD] Crasher bug
by Dan Wilcox 02 Oct '17

02 Oct '17

If you want more info, you can compile pd with debugging symbols added via: ./configure --enable-debug CFLAGS="-g" I'm going to add the "-g" back to the default debug settings as it's needed for useful stack frame info, etc. If you have the Xcode command line tools installed (not the Xcode app!), you can use lldb for similar info: http://lldb.llvm.org/lldb-gdb.html <http://lldb.llvm.org/lldb-gdb.html>. It can give you the exact location in the code where the crash occurred. > On Oct 2, 2017, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> > 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: Re: [PD] Crasher bug > Message-ID: <1506929734.2070.4.camel(a)gmail.com <mailto:1506929734.2070.4.camel@gmail.com>> > Content-Type: text/plain; charset="utf-8" > > On Son, 2017-10-01 at 22:16 +0200, Roman Haefeli wrote: >> Hey all >> >> Attached patch crashes Pd, at least on Ubuntu 16.04 amd64. Pd 0.48 >> and >> 0.47-1 seems affected, but not 0.46-7. Also, I cannot make it crash >> with the current 0.48 release for Windows under Wine. I couldn't test >> it on macOS, but the original patch (not this reduced one) crashes on >> macOS 10.11 with Pd 0.48. > > I checked again and it doesn't crash on macOS, however the original > non-reduced patch does reliably crash. It seems it requires a different > reduced version for macOS. > > From 0.48, macOS 10.11: > > pd(4254,0x7fff79118000) malloc: *** error for object 0x7fc3b2096208: incorrect checksum for freed object - object was probably modified after being freed. > *** set a breakpoint in malloc_error_break to debug > Pd: signal 6 > gui socket 4 - closing audio... -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Crasher bug
by Roman Haefeli 02 Oct '17

02 Oct '17

Hey all Attached patch crashes Pd, at least on Ubuntu 16.04 amd64. Pd 0.48 and 0.47-1 seems affected, but not 0.46-7. Also, I cannot make it crash with the current 0.48 release for Windows under Wine. I couldn't test it on macOS, but the original patch (not this reduced one) crashes on macOS 10.11 with Pd 0.48. The patch doesn't do anything meaningful anymore more, since I tried to remove anything that was not needed for the crash. With current git master, I get the following backtrace printed to the console, as soon as I click the bang: $ pd -stderr -nosound -open crashtest.pd *** Error in `pd': corrupted size vs. prev_size: 0x0000000000b5e0a0 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f8f72df17e5] /lib/x86_64-linux-gnu/libc.so.6(+0x80dfb)[0x7f8f72dfadfb] /lib/x86_64-linux-gnu/libc.so.6(+0x83409)[0x7f8f72dfd409] /lib/x86_64-linux-gnu/libc.so.6(realloc+0x179)[0x7f8f72dfe839] pd(resizebytes+0x23)[0x47d183] pd(binbuf_text+0xf6)[0x47d3d6] pd[0x48d561] pd(socketreceiver_read+0x288)[0x48e6e8] pd[0x48d8c5] pd(m_mainloop+0x82f)[0x48a21f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f8f72d9a830] pd(_start+0x29)[0x4138e9] ======= Memory map: ======== ... skipped ... gdb backtrace: (gdb) backtrace #0 0x00007ffff6dcf428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff6dd102a in __GI_abort () at abort.c:89 #2 0x00007ffff6e117ea in __libc_message (do_abort=2, fmt=fmt@entry=0x7ffff6f2ae98 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff6e1adfb in malloc_printerr (ar_ptr=0x7ffff715eb20 <main_arena>, ptr=0x827c20, str=0x7ffff6f27c35 "corrupted size vs. prev_size", action=3) at malloc.c:5006 #4 _int_free (av=0x7ffff715eb20 <main_arena>, p=<optimized out>, have_lock=1) at malloc.c:4014 #5 0x00007ffff6e1d409 in _int_realloc (av=av@entry=0x7ffff715eb20 <main_arena>, oldp=oldp@entry=0x827b00, oldsize=oldsize@entry=288, nb=nb@entry=112) at malloc.c:4384 #6 0x00007ffff6e1e839 in __GI___libc_realloc (oldmem=0x827b10, bytes=96) at malloc.c:3045 #7 0x00000000004b5783 in resizebytes (old=<optimized out>, oldsize=256, newsize=<optimized out>) at m_memory.c:55 #8 0x00000000004a7ae6 in binbuf_text (x=0x7d3ba0, text=text@entry=0x7fffffffcce0 "\r\n.x7e8880 motion 39.0 78.0 0;", size=size@entry=30) at m_binbuf.c:199 #9 0x00000000004c0b15 in socketreceiver_doread (x=x@entry=0x7ef580) at s_inter.c:494 #10 0x00000000004c214c in socketreceiver_read (x=0x7ef580, fd=12) at s_inter.c:597 #11 0x00000000004c0e8e in sys_domicrosleep (microsec=<optimized out>, pollem=1) at s_inter.c:230 #12 0x00000000004c1585 in sys_microsleep (microsec=<optimized out>) at s_inter.c:254 #13 0x00000000004b9fda in m_pollingscheduler () at m_sched.c:541 #14 m_mainloop () at m_sched.c:596 #15 0x00007ffff6dba830 in __libc_start_main (main=0x414aa0 <main>, argc=6, argv=0x7fffffffe048, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe038) at ../csu/libc-start.c:291 #16 0x0000000000414ad9 in _start () Roman

2 2

Re: [PD] why not Purr Data?
by Alexandre Torres Porres 01 Oct '17

01 Oct '17

you haven't replied to the pd list, so I'm bringing it back to the list. Please don't reply directly just to me, keep this thread in the list ;) 2017-10-01 15:31 GMT-03:00 Alexandre Torres Porres <porres(a)gmail.com>: > > > 2017-10-01 15:04 GMT-03:00 Ali Momeni <batchku(a)gmail.com>: >> >> >> By support for many externals that can be loaded into Vanilla, you mean >> ones that have a GUI? or others too? >> > > Mostly GUI, and not just graphical objects, things like > [cyclone/MouseState]. > > Moreover, there are some external libraries that were not provided for > Extended but are now provided for Vanilla and not included in Purr Data, > and some are not compatible too. > > There's also the case of a library being updated and available for > Vanilla, but not on Purr Data yet. Like cyclone, which has new versions > since early 2017 but hasn't made into Purr Data yet. > > There might be a notion that Vanilla is limited, and Purr Data or extended > more complete. I challenge that notion. > > Oh, and if you're into libpd, that's also something that you need Vanilla > for. > > And yeah, I say Purr Data is still less stable than Vanilla. > > cheers > >

1 0

32/64bit Pd and compatible libraries (was: Issues with Gem 0.39-3 on OS X via Deken in Pd)
by Alexandre Torres Porres 01 Oct '17

01 Oct '17

2017-10-01 14:43 GMT-03:00 IOhannes m zmölnig <zmoelnig(a)iem.at>: > > all the pre-built libraries were also only available as 32bit libraries. > all (most) of these libraries could be built for 64bit just as well, but > if you already have a 32bit binary of a given library, you just cannot > use it with a 64bit Pd. > So this means they do work given they're built, but not necessarily that they have been built. Well, let me rephrase the question then. Out of the currently available external libraries in deken, which are only 32 bits and do not work on Pd Vanilla 64 bits for macOS? And actually, what throws me off is that it seems many libraries have the same binary for both 32/64bits Pd. cheers

1 0

Re: [PD] Issues with Gem 0.39-3 on OS X via Deken in Pd
by Dan Wilcox 01 Oct '17

01 Oct '17

> On Sep 30, 2017, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > So I'm really confused on what the technical issues are. The macOS [pix_film], [pix_image], & [pix_record] backends use the Quicktime framework (via QTKit) provided by Apple with the OS. Apple stopped updating Quicktime a while ago in favor of the AVFoundation framework starting with macOS 10.7. Quicktime, being older, was designed for 32 bit systems and not updated for 64 bit. AVFoundation being newer was designed for 64 bit systems and does not support 32 bit. As of macOS 10.12, Quicktime is no longer included with the OS. This was after being deprecated for 5 versions of the OS, so no surprise. If you are running 10.12, [pix_film], [pix_image], & [pix_record] simply will not work as there is no Quicktime. The backends need to be transitions to use AVFoundation instead. Everything else in GEM works. I started the basics of adding AVFoundation backends a couple years ago now, but just haven't gotten around to things very often and was hoping (in vain apparently) that there were some other people willing to finish it off. There is currently a [pix_film] working with AVFoundation but it has a memory leak I haven't fixed, so Pd crashes after playing a video for about a minute. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 9

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 October 2017