Pd-list January 2017

pd-list@lists.iem.at

63 participants
84 discussions

loadbang behavior
by Antoine Villeret 02 Jan '17

02 Jan '17

Hello, Happy new year pd-list ! With pd-0.46-7, loadbang method was called only once when patcher loads. Now with 0.47-1, loadbang method are now called twice. Why loadbang method is called twice ? As far as I understand, loadbang method could be called not only on patcher load (LB_LOAD), but also when closing an abstraction (LB_CLOSE) and before the object is connected to parent patcher (LB_INIT). Many externals uses this loadbang method to initiate their state. This new behavior trig a lots of "wrong argument for loadbang method" error in pd console. Is it a good practice to rely on loadbang call to initiate objects ? or should we avoid it and use [loadbang] object and/or make initialisation in object_new method ? -- do it yourself http://antoine.villeret.free.fr

3 8

[PD-announce] puredata.info server outage resolved
by IEM - network operating center (IOhannes m zmoelnig) 02 Jan '17

02 Jan '17

dear patchers, as you might have noticed, the puredata.info server (including your beloved Pd mailinglists) went offline during the Christmas holidays, with no-one nearby to resolve the issues (triggered by a multi-day power outage which albeit planned by some parties was only communicated to the involved parties on *very* short notice). we hope this gave you the time to create some spectacular patches. this mail is to confirm that the services are up and running again. happy new year. fgamsdr IOhannes -- IEM - network operation center mailto:noc@iem.at _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

Latest PD on Ubuntu
by Hrvoje Radnic 02 Jan '17

02 Jan '17

Dear PD List, I am sorry for the beginner's question, but I can't figure out how to install the latest version of PD (0.47-1) to the latest Ubuntu (16.04. LTS) release. I must say that I am complete beginner in that OS. I followed the instructions from INSTALL.txt and after typing ./automake I got this:autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I m4/generated -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: adding subdirectory portaudio to autoreconf autoreconf: Entering directory `portaudio' autoreconf: configure.in: not using Gettext autoreconf: running: aclocal --force aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in' autoreconf: configure.in: tracing autoreconf: configure.in: subdirectory bindings/cpp not present autoreconf: configure.in: not using Libtool autoreconf: running: /usr/bin/autoconf --force configure.in:104: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:105: error: possibly undefined macro: AC_PROG_LIBTOOL autoreconf: /usr/bin/autoconf failed with exit status: 1 Can you please, help me with this?Thanks a lot! Hrvoje Radnic http://soundcloud.com/sumovi-protiv-valova 00385(0)915225162

2 1

threadsafe multi-instance Pd?
by Miller Puckette 02 Jan '17

02 Jan '17

To Pd List, Here's my promised followup mail on Pd thread-ability (the hoped for ability to call Pd instances, via pdlib, from separate threads concurrently). Peter Brinkmann made a suggestion during the Pd convention round-table discussion that I'll paraphrase here. There is a "pd_this" variable in m_pd.c, pointing to the current Pd instance. If this were made per-thread, then it should be possible to run different instances on different threads simultaneously; the only protection needed would be that each individual instance should be protected by pdlib with its own lock. (There would also have to be a global lock to protect pd_init(), which need only be called as setup time). But there's a snag, because the symbol table is global. It wouldn't help to make this per-thread, since calls to pd instances might migrate from thread to thread. Instead, we could do 1 of these 2 things: 1 (Peter's idea) : make gensym(), pd_bind(), and pd_unbind() threadsafe using a lock. Access via gensym() could be nonexclusive, as could locking out pd_bind() and pd_unbind() during accesses to s->s_thing (we'd have to hunt down everywhere in the code this is done). I think there's a complication: what if you pass a message to an object via a symbol's s_thing that's in a different instance from the current one (pd_this) in the thread of the caller? I don't know an easy way to determine what pd instance an arbitrary object belongs to. OR: 2. (another possibility): Go back and make the symbol table be per-instance. I tried this earlier and got stumped because classes, which are global to all Pd instances, contain a list of selectors (symbols) and their associated messages. If the symbol address changes because we switch to a new Pd instance, messages (like #N print) no longer are associated with the method (print_new()), so nothing works. I think it's impractical to make classes per-instance, but what about making each class maintain a separate list of messages for each Pd instance. When a new Pd instance is created, we'd go find all the classes, and add a new message list to each of them for the new instance. Then whenever one passes a message (assuming it's not one of s_bang, s_float, s_symbol, s_list, or s_anything, which are usually handled by a faster mechanism), the message passing functions pd_typedmess(), getfn(), etc., would have to look up the message list associated with the current pd instance, and then look down the list of selectors/methods as before. Anyone see anything fatally wrong with this, and/or can option (1) be made workable and is it better? cheers Miller

1 0

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