Re: [PD-dev] add a new tcl file to pd source [was: recentfiles_list explanation]
Good news! Add the file here, like it sounds like you already have: pd/tcl/Makefile.am pd/po/Makefile.am Then manually edit pkgIndex.tcl, I haven't had good luck with pkg_mkIndex.tcl. .hc On Mar 18, 2011, at 12:46 PM, yvan volochine wrote: hi as my work on recent files is nearly done, I'd like to know what's the proper way to add a new *.tcl file to pd source. as I said in the other thread, I added my new file to: pd/tcl/Makefile.am pd/tcl/po/Makefile.am then I ran manually tcl/pkg_mkIndex.tcl and my file ends up in tcl/ pkgIndex.tcl is that the right thing to do ? I'm a Makefile n00b so please tell me if I do something stupid. I cannot provide a patch until I solved this. ps: I found nothing related to this in the developper doc cheers, _y ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] integrating pdlua into Pd-extended
Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/ Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] add a new tcl file to pd source [was: recentfiles_list explanation]
On Mar 19, 2011, at 2:54 PM, yvan volochine wrote: On 03/18/2011 06:16 PM, Hans-Christoph Steiner wrote: Good news! Add the file here, like it sounds like you already have: pd/tcl/Makefile.am pd/po/Makefile.am Then manually edit pkgIndex.tcl, I haven't had good luck with pkg_mkIndex.tcl. it worked for me, it filled out pkdIndex.tcl and it seems to be correct. so far it works nicely on osx and linux. I will try to build and test on win32 before posting a patch. slightly OT, for the sake of clarity, there will now be 5 maximum recent files when inlined in File menu (on x11 and win32). as osx has a 'Open Recent' separated menu, should I keep the old behavior there (i.e. 10 max recent files) or should I also limit it to 5 ? cheers, _y I think 10 is the standard for Mac OS X, so I say keep it. .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] add a new tcl file to pd source [was: recentfiles_list explanation]
On Mar 22, 2011, at 12:11 PM, yvan volochine wrote: On 03/20/2011 04:41 AM, Hans-Christoph Steiner wrote: On Mar 19, 2011, at 2:54 PM, yvan volochine wrote: On 03/18/2011 06:16 PM, Hans-Christoph Steiner wrote: Good news! Add the file here, like it sounds like you already have: pd/tcl/Makefile.am pd/po/Makefile.am Then manually edit pkgIndex.tcl, I haven't had good luck with pkg_mkIndex.tcl. it worked for me, it filled out pkdIndex.tcl and it seems to be correct. so far it works nicely on osx and linux. I will try to build and test on win32 before posting a patch. slightly OT, for the sake of clarity, there will now be 5 maximum recent files when inlined in File menu (on x11 and win32). as osx has a 'Open Recent' separated menu, should I keep the old behavior there (i.e. 10 max recent files) or should I also limit it to 5 ? cheers, _y I think 10 is the standard for Mac OS X, so I say keep it. I just posted my patch but unfortunately I couldn't try it on windows. let me know what you think. cheers, _y I'll check it out when I have some time. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] canvas class polymorphism
What's the end goal here? You want an object that acts like a t_canvas/ t_glist? .hc On Mar 13, 2011, at 3:31 PM, Charles Henry wrote: I've been working through my CUDA Pd project, and I ran into the problem of making externals that copy the canvas class. My first idea was that I wanted a completely separate class with different methods using glist. Calls from Pd looking for t_canvas work just fine, but functions like pd_findbyclass that look for canvas_class fail. I started mucking around in the pd src, and I think it's just too difficult and would make onerous changes that I don't like. Is there something I'm not getting about canvas classes and externals? My second approach to creating an external library is to modify glist by adding an unsigned int gl_hascuda variable. I'd still prefer solutions that make use of entirely external libraries over modifying src, but this small change gets me half the way there. Then, I just need to write the creator functions and the class works. Chuck ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] canvas class polymorphism
I think its going to be quite difficult to have a single object running in the CUDA/GPU while the rest of the patch runs on the CPU in regular Pd. My guess is that the best first step would be to implement a basic Pd in CUDA, then work from there about integrating it. Perhaps then you could use the [pd~] model. For examples of reimplmentations of Pd, check out ZenGarden (C++) and Webpd (Javascript) http://mccormick.cx/projects/WebPd/ .hc On Mar 23, 2011, at 5:20 PM, Charles Henry wrote: Hi, hc Let me explain a little further here. The end goal is to have an external library that allows one to create externals that use memory on GPUs. Big idea here is that once you've got a system for handling the memory allocation and dsp sorting in *exactly* the same way as Pd, then you can write externals for CUDA or CL in a way that's consistent with existing externals. With Pd handling the signal memory allocation inside of d_ugen.c and called from canvas_dodsp, I wanted for my external library to have its own canvas class and different methods for handling the memory allocation differently. In fact, I think of that as being the key class to create the library. I worked through it for a while, and I think it's just plain impossible to have another canvas class in an external library, unless there's something good I don't understand. And I really want to understand :) So, since then, I've been thinking that I'd have to modify the pd- vanilla source code. I've got something that loads a CUDA device and gets me to run code during canvas_new, canvas_free, and canvas_dsp. I'm still trying to organize around the idea of having an external library to load and make as few changes directly in the vanilla source code. Chuck On Wed, Mar 23, 2011 at 1:51 PM, Hans-Christoph Steiner h...@at.or.at wrote: What's the end goal here? You want an object that acts like a t_canvas/t_glist? .hc On Mar 13, 2011, at 3:31 PM, Charles Henry wrote: I've been working through my CUDA Pd project, and I ran into the problem of making externals that copy the canvas class. My first idea was that I wanted a completely separate class with different methods using glist. Calls from Pd looking for t_canvas work just fine, but functions like pd_findbyclass that look for canvas_class fail. I started mucking around in the pd src, and I think it's just too difficult and would make onerous changes that I don't like. Is there something I'm not getting about canvas classes and externals? My second approach to creating an external library is to modify glist by adding an unsigned int gl_hascuda variable. I'd still prefer solutions that make use of entirely external libraries over modifying src, but this small change gets me half the way there. Then, I just need to write the creator functions and the class works. Chuck ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] read a *.plist array in tcl
On Thu, 2011-03-24 at 19:43 +0100, yvan volochine wrote:
hi
when reading from a *.plist file in tcl, if the value asked is an array,
I get a string:
if {![catch {exec defaults read org.puredata $akey} arr]} {
puts $arr
}
// this string is printed
(
foo,
bar
)
is there any elegant way to get this array as a tcl list directly ?
Some Tcl regsub tricks seem to work pretty well, see attachment.
.hc
#!/usr/bin/tclsh
set domain recentfilestext
set key recentfiles
catch {exec defaults write recentfilestext recentfiles -array patch.pd another.pd file with spaces.txt file,with,commas.pd oneword anotherpatch.pd}
if {![catch {exec defaults read $domain $key} arr]} {
puts arr $arr
set filelist $arr
regsub -all -- {(?),\s+(?)} $filelist {\1 \2} filelist
regsub -all -- {\n} $filelist {} filelist
regsub -all -- {^\(} $filelist {} filelist
regsub -all -- {\)$} $filelist {} filelist
puts filelist: $filelist
foreach file $filelist {
set filename [regsub -- {,$} $file {}]
puts file: $filename
}
}
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] read a *.plist array in tcl
On Mar 25, 2011, at 2:56 PM, yvan volochine wrote:
On 03/25/2011 05:35 PM, Hans-Christoph Steiner wrote:
On Thu, 2011-03-24 at 19:43 +0100, yvan volochine wrote:
hi
when reading from a *.plist file in tcl, if the value asked is an
array,
I get a string:
if {![catch {exec defaults read org.puredata $akey} arr]} {
puts $arr
}
// this string is printed
(
foo,
bar
)
is there any elegant way to get this array as a tcl list directly ?
Some Tcl regsub tricks seem to work pretty well, see attachment.
hey thanks
it might be a bit slower than [string map] but it handles better
special chars in filenames
I should have been working on something else, but I couldn't stop.
Hope this helps:
parse-defaults.tcl
Description: Binary data
.hc
Making boring techno music is really easy with modern tools, but with
live coding, boring techno is much harder. - Chris McCormick
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] integrating pdlua into Pd-extended
Yeah, we can build Lua on Windows and install it into the MinGW path. That's how the rest of the libraries are currently handled. Then the installer grabs the .dlls from the MinGW install path. Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server. .hc On Mar 26, 2011, at 6:31 PM, Martin Peach wrote: From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that dll. Sooo, maybe pd-extended should build lua as well, like portaudio, or should the dll be put in pd/bin, like pthreads.dll? Martin On 2011-03-18 23:55, Hans-Christoph Steiner wrote: Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org mailto:cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] integrating pdlua into Pd-extended
Hmm, turns out it was already installed on the Windows build machine, but I just updated it. Something with the way pdlua is being linked makes it not able to find lua51.dll. My guess is because the Lua build system doesn't generate a liblua51.dll.a to put in /usr/local/ lib, like the other libs there. libogg for example. I don't know how to generate the liblua51.dll.a, do you? .hc On Mar 26, 2011, at 9:03 PM, Martin Peach wrote: If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work. Martin On 2011-03-26 20:20, Hans-Christoph Steiner wrote: Yeah, we can build Lua on Windows and install it into the MinGW path. That's how the rest of the libraries are currently handled. Then the installer grabs the .dlls from the MinGW install path. Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server. .hc On Mar 26, 2011, at 6:31 PM, Martin Peach wrote: From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that dll. Sooo, maybe pd-extended should build lua as well, like portaudio, or should the dll be put in pd/bin, like pthreads.dll? Martin On 2011-03-18 23:55, Hans-Christoph Steiner wrote: Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org mailto:cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] integrating pdlua into Pd-extended
I think the key is to generate the liblua51.dll.a file using the instructions that were just posted, and stick that into the pdlua folder, set -L., then -llua51 should just work. The .dll.a file seems to expose the DLL symbols in a way that ld understands. If that works, I'll include it in the build machine. .hc On Mar 27, 2011, at 9:40 PM, Martin Peach wrote: I just built that lua-5.1.4 package in MinGW. Just typing 'make mingw'produces liblua.a and lua51.dll in src. liblua.a is somewhat larger than the dll. 'Make install' copies liblua.a into /usr/local/lib and creates an empty directory /usr/local/lib/lua. The error in the latest autobuild log (2011-03-27_03.31.00_mingw32_nt-5.1_windowsxp-i386_pd-extended.txt) is gcc -s -shared -Wl,--enable-auto-import -o pdlua.dll pdlua.o - L/home/pd/auto-build/pd-extended/pd/src -L/home/pd/auto-build/pd- extended/pd/bin -L/home/pd/auto-build/pd-extended/pd/obj -lpd - lwsock32 -lkernel32 -luser32 -lgdi32 -llua51.dll c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin \ld.exe: cannot find -llua51.dll So maybe it should be looking for -llua instead of -llua51.dll. Or else placing lua51.dll in /usr/local/lib or /usr/local/lib/lua might work. The lua wiki seems to imply that you should link against the dll. I'll change it to -llua first as that seems consistent with the rest of the MinGW Pd build. Martin On 2011-03-27 12:25, Hans-Christoph Steiner wrote: Hmm, turns out it was already installed on the Windows build machine, but I just updated it. Something with the way pdlua is being linked makes it not able to find lua51.dll. My guess is because the Lua build system doesn't generate a liblua51.dll.a to put in /usr/local/lib, like the other libs there. libogg for example. I don't know how to generate the liblua51.dll.a, do you? .hc On Mar 26, 2011, at 9:03 PM, Martin Peach wrote: If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work. Martin On 2011-03-26 20:20, Hans-Christoph Steiner wrote: Yeah, we can build Lua on Windows and install it into the MinGW path. That's how the rest of the libraries are currently handled. Then the installer grabs the .dlls from the MinGW install path. Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server. .hc On Mar 26, 2011, at 6:31 PM, Martin Peach wrote: From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that dll. Sooo, maybe pd-extended should build lua as well, like portaudio, or should the dll be put in pd/bin, like pthreads.dll? Martin On 2011-03-18 23:55, Hans-Christoph Steiner wrote: Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org mailto:cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war
Re: [PD-dev] integrating pdlua into Pd-extended
Oh, I assumed that a libfoo.a was a complete library for static linking, like on GNU/Linux and Mac OS X, and that the libfoo.dll.a was a special MinGW dlltool format to trick ld into linking against a Windows DLL. That was my impression from reading about the dlltool trick. .hc On Mar 28, 2011, at 12:24 AM, Martin Peach wrote: That would be the same file as liblua.a. Giving it another name won't change much. It looks like all the other libs in the MinGW build of pd-extended are .a and not .dll. As I understand it the .a libs have all the symbols included while dlls expose only what was specified to be exported. Martin On 2011-03-27 22:07, Hans-Christoph Steiner wrote: I think the key is to generate the liblua51.dll.a file using the instructions that were just posted, and stick that into the pdlua folder, set -L., then -llua51 should just work. The .dll.a file seems to expose the DLL symbols in a way that ld understands. If that works, I'll include it in the build machine. .hc On Mar 27, 2011, at 9:40 PM, Martin Peach wrote: I just built that lua-5.1.4 package in MinGW. Just typing 'make mingw'produces liblua.a and lua51.dll in src. liblua.a is somewhat larger than the dll. 'Make install' copies liblua.a into /usr/local/lib and creates an empty directory /usr/local/lib/lua. The error in the latest autobuild log (2011-03-27_03.31.00_mingw32_nt-5.1_windowsxp-i386_pd- extended.txt) is gcc -s -shared -Wl,--enable-auto-import -o pdlua.dll pdlua.o -L/home/pd/auto-build/pd-extended/pd/src -L/home/pd/auto-build/pd-extended/pd/bin -L/home/pd/auto-build/pd-extended/pd/obj -lpd -lwsock32 -lkernel32 -luser32 -lgdi32 -llua51.dll c:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin \ld.exe: cannot find -llua51.dll So maybe it should be looking for -llua instead of -llua51.dll. Or else placing lua51.dll in /usr/local/lib or /usr/local/lib/lua might work. The lua wiki seems to imply that you should link against the dll. I'll change it to -llua first as that seems consistent with the rest of the MinGW Pd build. Martin On 2011-03-27 12:25, Hans-Christoph Steiner wrote: Hmm, turns out it was already installed on the Windows build machine, but I just updated it. Something with the way pdlua is being linked makes it not able to find lua51.dll. My guess is because the Lua build system doesn't generate a liblua51.dll.a to put in /usr/local/ lib, like the other libs there. libogg for example. I don't know how to generate the liblua51.dll.a, do you? .hc On Mar 26, 2011, at 9:03 PM, Martin Peach wrote: If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work. Martin On 2011-03-26 20:20, Hans-Christoph Steiner wrote: Yeah, we can build Lua on Windows and install it into the MinGW path. That's how the rest of the libraries are currently handled. Then the installer grabs the .dlls from the MinGW install path. Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server. .hc On Mar 26, 2011, at 6:31 PM, Martin Peach wrote: From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that dll. Sooo, maybe pd-extended should build lua as well, like portaudio, or should the dll be put in pd/bin, like pthreads.dll? Martin On 2011-03-18 23:55, Hans-Christoph Steiner wrote: Martin, I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib tho. .hc On Mar 18, 2011, at 5:02 PM, katja wrote: Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.org mailto:cla...@goto10.org wrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http
Re: [PD-dev] gtk-open-plugin update
Hey Lorenzo,
I cc'ed pd-dev since this could be generally useful discussion. The
save thing works a fair amount different than open, and the messages are
hidden within the pd - pd-gui communications. The place to start in
finding the File-Save function is to look at what the File-Save or
Ctrl-S calls. In tcl/pd_bindings.tcl, you can see this:
bind all $::modifier-Key-s {menu_send %W menusave}
So Ctrl-S directly sends 'menusave' to pd. To find that in the C
source, I look for 'menusave' i.e. menusave in double-quotes:
hans@palatschinken pure-data.git $ grep 'menusave' src/*.c
src/g_readwrite.c:gensym(menusave), 0);
Which is a piece of this line:
class_addmethod(canvas_class, (t_method)canvas_menusave,
gensym(menusave), 0);
So that binds menusave to the canvas_menusave function which
ultimately replies to pd-gui calling the Tcl proc pdtk_canvas_saveas.
So you just need to override that Tcl proc since that is where
tk_getSaveFile is called to launch the Save As panel.
.hc
On Thu, 2011-03-31 at 23:35 +0200, Lorenzo Sutton wrote:
Hans,
I was looking into putting the save as well, but as hard as I looked I
just can't find where the save is... I was expecting to find something
like proc ::pd_menucommands::menu_save but it doesn't seem to be there.
In 0.42 I hacked a proc called pdtk_canvas_saveas to have the gtk but I
can't find any reference to that either
Any clue?
Lorenzo
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] erase object text
On Apr 2, 2011, at 11:57 AM, yvan volochine wrote:
On 04/02/2011 05:38 PM, yvan volochine wrote:
On 04/01/2011 11:29 PM, yvan volochine wrote:
On 04/01/2011 10:43 PM, Miller Puckette wrote:
Can't be done -- the actual text editing is done in Pd and the TCL
code is just to display the current state of affairs down in Pd.
There might be a way to do it via messages to Pd though -- for
instance,
simlulating the necessary mouse/keyboard actions.
ah yes, that works if I simulate a double-click.
it seems that simulating the mouse is a bad idea (focus problems).
how would I go to simulate CTRL-A ??
this does not work:
proc ctrl_all {} {
...
set key Control_L
set a 97
pdsend $mytoplevel key 1 $key 0
actually this should be better but it also does not work:
pdsend $mytoplevel selectall
in pd, it seems that CTRL-A just releases the object.
Have you tried watching the actual traffic that pd-gui sends to pd?
Run pd from the command line like 'pd -stderr -d 3' and you'll see the
communications between pd and pd-gui. -d 1 would be one direction of
that traffic, and -d 2 would be the other direction, but I forget
which is which.
That way you can figure out which messages are the ones that you want
to hijack :)
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] submitting gui-plugins
I think its best to keep them separate, so people can easily mix-n- match what they want, IMHO. Looking forward to trying the auto- completion plugin! .hc On Apr 2, 2011, at 8:15 AM, yvan volochine wrote: hi, I have a couple of gui-plugins[*] I'd like to submit but I'm afraid I couldn't find how :/ I created an account on the wiki but I don't know how to add something in projects/software/gui-plugin. cheers, _y ps: I realized that my RecentFiles patch fits in a Gui-Plugin, as well as other goodies. pps: say I wrote 3 gui-plugins, do you think it's better to add them separately or group them all together ? (recent-files, menubar- shortcuts, auto-completion) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] flext and gnu/windows - 'undefined reference' with pd global vars?
'undefined reference' generally means that the linker has found symbols in the .o files that it can't find a reference to. I.e. take the function 'foo', if myobject.o uses foo() from the bar lib, and the bar lib is not including the linking, because its not specified or not in the lib path, the you'll get an 'undefined reference'. Basically it means it can't find the code that matches a given symbol (i.e. function, variable, etc). .hc On Apr 4, 2011, at 9:33 AM, dmotd wrote: fwd'd from flext list.. background: i've been working on a new autotools template for flext based libs and started testing on windows platform with cygwin + mingw, immediate issues with building flext lib itself. have any pd-devs experienced this 'undefined reference' issue with the linker? i'm testing against millers pd-0.43-0.msw.zip on win2k and winxp virtualbox images. build logs attached. cheers, dmotd Original Message Subject: Re: [flext] autotools builders - flext and gnu/windows Date: Mon, 4 Apr 2011 14:27:52 +0200 From: Thomas Grill g...@g.org To: dmotd inaudi...@simplesuperlativ.es CC: fl...@g.org hi dmotd, many thanks for your efforts, mingw (gcc 4.5.2): with both your buildsys (cmd prompt) and autoconf (msys shell), mingw will build all the static libs, but fails at the linker stage when building the dynamic library, with a bunch of undefined references (see attachment). i have attempted to encourage the build further by passing linker flags (-Wl,--as-needed and -Wl,--no-undefined *plus numerous others/ combinations*) but nothing seems to make it budge. i'm not sure if the compiler is being pedantic or i'm just not understanding something. I can remember that problem - it is connected to the way how global variables (like garray_class, s_float etc.) in Pd are defined for the linker. I must have found a solution once cygwin (gcc 3.4.4) cygwin breaks with your buildsys due to what appears to be an issue with the environment (see attachment). with autoconf it acts much like mingw - it can successfully build static libs but fails to make the shared dll, a few more undefined references than with mingw (see attachment). The flext-build output seems to indicate a c++ namespace problem which should not be too hard to fix. The autoconf output seems different, probably a mixture of problems. i'm not sure if i can spare any time for that soon but it's good to know the weak spots. all the best, Thomas flext-autotools-cygwin.txtflext-build-cygwin.txtflext-build- mingw.txt___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl registry pd-0.43
According to the Tcl/Tk 8.4 docs, it should be included. What if you just try to use 'registry' without the 'package require registry'? http://tcl.tk/man/tcl8.4/TclCmd/registry.htm .hc On Apr 5, 2011, at 11:19 AM, yvan volochine wrote: hi, I use `package require registry' in a Gui-Plugin and it seems that it's not included in pd-0.43 win binaries. I have no experience on win32 so I'd like to know if this package is included when users build pd themselves ? thanks, _y ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev A cellphone to me is just an opportunity to be irritated wherever you are. - Linus Torvalds ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] mingw/autotools/libtool, some success (flext and gnu/windows - 'undefined reference' with pd global vars?)
On Apr 8, 2011, at 2:08 PM, Thomas Grill wrote: the bottom line, mingw + autotools is some kinda headache! so where to now? Hi, doesn't the pd build system use mingw and autotools? It must have the same problems, or a solution for it, no? gr~~~ mingw and autotools seems to work fine for things like zexy, OSCx, etc. Plus all the of the libs that Pd-extended uses are built on MinGW. .hc ¡El pueblo unido jamás será vencido! ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [flext] mingw/autotools/libtool, some success (flext and gnu/windows - 'undefined reference' with pd global vars?)
On Apr 9, 2011, at 2:27 AM, dmotd wrote: On 04/09/2011 03:48 PM, Patrice Colet wrote: hello, - dmotdinaudi...@simplesuperlativ.es a écrit : and the source of my original problem, milllers pd.dll breaking the gnu linker likely will effect building other libs under mingw. did you try to compile Miller's pd.dll with makefile.mingw ? yes, but the build failed - i can't remember why.. and i decided to make the autotools work for mingw instead - that shouldn't be a bad thing, no? It would be great if we had a single build system that worked on all platforms. The autotools/libtool based build system new in 0.43 did work on MinGW at some point, but I haven't tested it in a while. Also, I don't think I tried building externals against it. But as long as I left out ASIO, it built and ran. .hc http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0.42/pd/src wouldn't it be easier to use pd.dll from pd-extended rather, because it has been compiled with mingw? yes, but in principle you shouldn't need to install pd-extended to compile for pd. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl registry pd-0.43
On Apr 7, 2011, at 3:13 AM, yvan volochine wrote: On 04/06/2011 08:04 PM, Hans-Christoph Steiner wrote: According to the Tcl/Tk 8.4 docs, it should be included. What if you just try to use 'registry' without the 'package require registry'? http://tcl.tk/man/tcl8.4/TclCmd/registry.htm it should but it's not. running tclsh84.exe shipped with pd-0.43 win binary: package require registry Unknown command registry That's a bummer. Any luck with Pd-extended 0.43? I think I made it include everything, plus I recently added all of tcllib. .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl registry pd-0.43
On Apr 7, 2011, at 3:13 AM, yvan volochine wrote: On 04/06/2011 08:04 PM, Hans-Christoph Steiner wrote: According to the Tcl/Tk 8.4 docs, it should be included. What if you just try to use 'registry' without the 'package require registry'? http://tcl.tk/man/tcl8.4/TclCmd/registry.htm it should but it's not. running tclsh84.exe shipped with pd-0.43 win binary: package require registry Unknown command registry Miller, do you think you could add the libs that come with Tcl/Tk to your included version? There are two folders called 'reg1.2' and 'dde1.3' that should go into pd/lib directly, they come with Tcl/Tk in tcl/library/. These will also be needed to support making a double- clicked file open in the currently running instance of Pd. Really everything in tcl/library/ should be included so we have a full Tcl/Tk install. Yvan, it should also be possible to include the 'reg1.2' folder in your plugin folder for making a plugin that people can use now. I think its just a matter of adding the local folder to the auto_path, so adding something like this to the plugin: set auto_path [linsert $auto_path 0 \ [file join $::current_plugin_loadpath openrecent-plugin] .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl registry pd-0.43
While avoiding bloat is a worthy goal, it seems to me that a good place to draw that line is at the standard Tcl/Tk. I don't think adding those libs will add a lot, but it does mean that people can rely on the standard Tcl/Tk docs to know what they can do with Tcl/Tk in Pd. .hc On Apr 10, 2011, at 3:58 PM, Miller Puckette wrote: Hmmm. yep, maybe the right policy would be simply to throw all of tk/tcl in Pd... I've been trying to avoid bloat but there's a real potential for lots of features breaking on Pcs if I try to hold to the policy of only include what is being used. I have to crank up my PC anyway to see about a bug report (asio4all seems not to work with 0.43) but probably won't be able to get to it this weekend - I have lots of bureaucrap awaiting me... cheers Miller On Sun, Apr 10, 2011 at 12:31:30PM -0400, Hans-Christoph Steiner wrote: On Apr 7, 2011, at 3:13 AM, yvan volochine wrote: On 04/06/2011 08:04 PM, Hans-Christoph Steiner wrote: According to the Tcl/Tk 8.4 docs, it should be included. What if you just try to use 'registry' without the 'package require registry'? http://tcl.tk/man/tcl8.4/TclCmd/registry.htm it should but it's not. running tclsh84.exe shipped with pd-0.43 win binary: package require registry Unknown command registry Miller, do you think you could add the libs that come with Tcl/Tk to your included version? There are two folders called 'reg1.2' and 'dde1.3' that should go into pd/lib directly, they come with Tcl/Tk in tcl/library/. These will also be needed to support making a double-clicked file open in the currently running instance of Pd. Really everything in tcl/library/ should be included so we have a full Tcl/Tk install. Yvan, it should also be possible to include the 'reg1.2' folder in your plugin folder for making a plugin that people can use now. I think its just a matter of adding the local folder to the auto_path, so adding something like this to the plugin: set auto_path [linsert $auto_path 0 \ [file join $::current_plugin_loadpath openrecent-plugin] .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl registry pd-0.43
On Apr 11, 2011, at 5:38 AM, yvan volochine wrote: On 04/11/2011 06:01 AM, Hans-Christoph Steiner wrote: While avoiding bloat is a worthy goal, it seems to me that a good place to draw that line is at the standard Tcl/Tk. I don't think adding those libs will add a lot, but it does mean that people can rely on the standard Tcl/Tk docs to know what they can do with Tcl/Tk in Pd. OTOH, as this is just for a Gui-Plugin, maybe I can use the same behavior on windowz as on linux (i.e. write RecentFiles to a file in $HOME/AppData instead of the registry) so this issue would not have to be fixed right now. while this might be less conventional, it could always change when/ if you want to include this feature in standard pd ? I agree if it is just for a GUI plugin it should just be included in the plugin. I think that pd-gui should be able to store its preferences in the registry, so the 'reg1.2' library would be for Pd core. Then to enable the DDE communications to allow a double-clicked file to open in the currently running Pd, we need the 'dde' library. The 'reg' and 'dde' libs might then depend on some of the other libs included in Tcl/Tk so its probably easiest to just include the whole suite of what's included in Tcl/Tk. On Apr 10, 2011, at 3:58 PM, Miller Puckette wrote: Hmmm. yep, maybe the right policy would be simply to throw all of tk/tcl in Pd... I spent the last days asking myself if that would make sense to rewrite the whole pd-gui in Qt instead of tcl/tk. Part of this pd-gui rewrite was laying the foundation to make such a project easier. The next step is converting the pd - pd-gui communications from Tcl commands to Pd messages. Then it should be not hard to make your own pd-gui in Qt, wxWindows, Cocoa, GTK, whatever. That is not a small project tho. .hc It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
Most vanilla objects are split out into their own 'vanilla' lib right now. So if you don't add vanilla/list and vanilla to the libraries loaded by default, they won't be loaded. You can do [import vanilla/list vanilla] to quickly try a patch without changing your prefs. .hc On Apr 11, 2011, at 9:03 AM, João Pais wrote: Hi, I thought about downloading a build of pd-ext 0.43 that works, to try it out. But the version I tried yesterday is apparently not ok, for example even cnv objects don't exist. Does anyone noticed a previous windows build that is more stable? (even if it doesn't have all the extra objects) João -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers. .hc On Apr 11, 2011, at 12:59 PM, João Pais wrote: of course, I saw that being discussed some days ago. ok. On Mon, 11 Apr 2011 17:32:19 +0200, Hans-Christoph Steiner h...@at.or.at wrote: Most vanilla objects are split out into their own 'vanilla' lib right now. So if you don't add vanilla/list and vanilla to the libraries loaded by default, they won't be loaded. You can do [import vanilla/list vanilla] to quickly try a patch without changing your prefs. .hc On Apr 11, 2011, at 9:03 AM, João Pais wrote: Hi, I thought about downloading a build of pd-ext 0.43 that works, to try it out. But the version I tried yesterday is apparently not ok, for example even cnv objects don't exist. Does anyone noticed a previous windows build that is more stable? (even if it doesn't have all the extra objects) João --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
Try loading 'libdir' as the first lib. .hc On Apr 11, 2011, at 6:32 PM, João Pais wrote: hmm, vanilla and vanilla/list are already in the startup libs of pd. and after that when trying import them, they say [import]: can't load library in 'vanilla' (vanilla/list seems to work). also, when editing the startup parameters in pd, the writing is really small, hardly readable. I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers. .hc On Apr 11, 2011, at 12:59 PM, João Pais wrote: of course, I saw that being discussed some days ago. ok. On Mon, 11 Apr 2011 17:32:19 +0200, Hans-Christoph Steiner h...@at.or.at wrote: Most vanilla objects are split out into their own 'vanilla' lib right now. So if you don't add vanilla/list and vanilla to the libraries loaded by default, they won't be loaded. You can do [import vanilla/list vanilla] to quickly try a patch without changing your prefs. .hc On Apr 11, 2011, at 9:03 AM, João Pais wrote: Hi, I thought about downloading a build of pd-ext 0.43 that works, to try it out. But the version I tried yesterday is apparently not ok, for example even cnv objects don't exist. Does anyone noticed a previous windows build that is more stable? (even if it doesn't have all the extra objects) João --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
Part of the idea is that people can make CPU-optimized versions of 'vanilla' and load them as they need them. So they shouldn't be locked in to using 'vanilla', or I would have just left those objects built-in. .hc On Apr 11, 2011, at 7:31 PM, João Pais wrote: you mean this lib structure? as long as they're configured properly, I myself don't see any difference - talking from the dumb user point of view. it might be better to lock them, or hide them from the editor - this would prevent someone who is trying out stuff to delete them. but maybe it's too much trouble for something that will likely hardly happen... I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers. http://at.or.at/hans/ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] string/blob type back in Pd-extended 0.43
FYI: Using the magic of meld, git gui, and gitk, I have refactored Martin's string/blob patch against pd 0.43.0 and included it into Pd- extended 0.43 git. .hc I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] big Pd-extended 0.43 updates
A few updates on Pd-extended 0.43 from work I did yesterday, last night: - just finally merged in all the relevant changes from Pd-extended 0.42 into the pd-extended.git, so tonight's build should include these changes, including Martin's string patch - I merged in a couple things from pd-l2ork, specifically: - IOhannes' $@ patch simplified to only $@ by Ico - jsarlo's Magic Glass - jsarlo's outlet highlighting .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Receive from Pd into tcl plugin
(I cc'ed pd-dev since I think this is a topic of general interest).
Yes, that's how it would have to happen, as far as I know. The idea
is to have a simple way to get the messages on the pd-gui side,
something like pd_bind. To start with, I think just having a single
receiver 'pd-gui' setup, then plugins would use something like [pd-gui
mousecursor target(, and whatever proc was registered to receive the
'mousecursor' messages would be called. I think a real simple
implementation would be to just make a ::pd-gui:: namespace, then
people would create procs in ::pd-gui:: to receive messages. So like:
proc ::pd-gui::mousecursor {args} {
$tkcanvas configure -cursor [lindex $args 0]
}
And the pd-gui receiver would just strip the 'pd-gui' part and exec
the rest.
.hc
On Apr 12, 2011, at 2:06 AM, Chris McCormick wrote:
Hi Hans,
I am curious, would it be possible to bind a function in Pd to catch
all
messages and send them through to a tcl/tk proc? Not that I want to
do this, I
am just curious. It might be best to set up a callback style
arrangement where
inside the tcl/tk plugin the developer can make a call specifying
which receive
symbol(s) they would like to listen for. That would make things
pretty flexible
and allow multiple plugins to use the functionality too.
Cheers,
Chris.
On Tue, Mar 29, 2011 at 02:21:06PM -0400, Hans-Christoph Steiner
wrote:
The easiest way is to create a proc in `pd-gui`, then bind a
function in
`pd` to a receive symbol, then have that function call the proc
using
sys_vgui(). I've been thinking that we should have a pre-registered
'pd-gui' receive symbol which will automatically get set to `pd-gui`,
just like the 'pd' receive symbol gets sent to `pd`, but I've never
found
the time. Please beat me to it! :-D
.hc
On Mar 29, 2011, at 2:46 AM, Chris McCormick wrote:
Hi Hans,
Is there any way to use the pd_connect tcl in the same way that it
does pdsend
to receive data back from Pd? I am persuing a bit of a hack of an
idea.
Cheers,
Chris.
---
http://mccormick.cx
Making boring techno music is really easy with modern tools, but
with
live coding, boring techno is much harder. - Chris McCormick
---
http://mccormick.cx
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone. --Bjarne Stroustrup (creator of C++)
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
On Apr 12, 2011, at 4:21 PM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2011 01:46 AM, Hans-Christoph Steiner wrote: Part of the idea is that people can make CPU-optimized versions of 'vanilla' and load them as they need them. So they shouldn't be locked in to using 'vanilla', or I would have just left those objects built-in. i think a better approach (than to have no [f] object) would be, to automatically load the std library until explicitely requested not to do so. e.g. add a -nostdlib flag to disable loading of the vanilla library. this seems to be perfectly in line with the current set of flags, and minimizes problems with 99% of the users The vanilla libdir will include [f], [t], [b], etc. you don't need a - nostdlib option to do that. I so no reason to add a different library loading mechanism when we have one that works. .hc kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
On Wed, 2011-04-13 at 19:09 +0200, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2011 05:11 PM, Hans-Christoph Steiner wrote: That is not quite a good analogy. The existing method was there: a folder that was searched by default called path/to/pd/extra. You did not need to specify -path path/to/pd/extra. ~/pd-externals is just another folder in that same list of folders to search. i think it is a good analogy. objects are loaded by default (vanilla set of objects). afair, you never needed to import vanilla to create [f]. however, what my analogy is really about is, that there is a startup flag -nostdpath which will _prevent_ path/to/pd/extra to be searched for objects. hence my suggestion to load vanilla by default, and add a flag -nostdlib to prevent loading of this if you need to. removing the core objects from Pd seems a more aggressive assault to people's workflows than having them manually add some standard search paths. either you do make exceptions or you don't. I want nothing aggressive or assaulting. i appreciate that and i admit that using both aggressive and assault was a bit of an overshoot. The idea is to solve problems like: - wanting use a SIMD-optimized version of the core objects for things that need it a) i fully understand and support this. b) i don't understand how my suggestion breaks with your idea. you can always do a -nostdlib -lib chocolate to replace vanilla with stracciatella. c) i don't understand how this is not possible with current Pd. as has been shown numerous times that you can simply override existing objects. cf. zexy's [pack] and gf's [print]. basically it seems that you are proposing something complicated to achieve something that is just there. - ability to use the new GUI/editor features while maintaining compatibility with older versions of Pd (i.e. steps towards the separation of the editor and the runtime). i'm all in favour of separating editor and runtime, and providing cool features. i fail to see how this is accomplished by forcing people to load core objects (and in fact leaving them with a bare, non working (for about all of the people) version of Pd) First, its not done yet, so yes there are problems. It'll be invisible to all Pd-extended users except those that want to know about it. That's my pledge. Second, you don't even use Pd-extended, so you are hardly the target audience. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
I recently committed some fixes so that these registry settings shouldn't be needed any more. I'd like to hear about others' experiences with it. .hc On Apr 11, 2011, at 6:56 PM, Martin Peach wrote: As I mentioned last week, you can change the pd-settings.reg file in a text editor so it starts like this: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Pd-extended] flags= loadlib1=libdir loadlib2=vanilla/list loadlib3=vanilla loadlib4=extra loadlib5=Gem loadlib6=cyclone loadlib7=zexy nloadlib=7 ; delete any previous loadlib flags loadlib8=- loadlib9=- ... Martin On 2011-04-11 18:53, Hans-Christoph Steiner wrote: Try loading 'libdir' as the first lib. .hc On Apr 11, 2011, at 6:32 PM, João Pais wrote: hmm, vanilla and vanilla/list are already in the startup libs of pd. and after that when trying import them, they say [import]: can't load library in 'vanilla' (vanilla/list seems to work). also, when editing the startup parameters in pd, the writing is really small, hardly readable. I forgot to add, I am interested in feedback on this particular feature. Right now its in there to try out. I'm not yet convinced it should be permanent, but it does offer some advantages, especially on mobile phones and smaller computers. .hc On Apr 11, 2011, at 12:59 PM, João Pais wrote: of course, I saw that being discussed some days ago. ok. On Mon, 11 Apr 2011 17:32:19 +0200, Hans-Christoph Steiner h...@at.or.at wrote: Most vanilla objects are split out into their own 'vanilla' lib right now. So if you don't add vanilla/list and vanilla to the libraries loaded by default, they won't be loaded. You can do [import vanilla/list vanilla] to quickly try a patch without changing your prefs. .hc On Apr 11, 2011, at 9:03 AM, João Pais wrote: Hi, I thought about downloading a build of pd-ext 0.43 that works, to try it out. But the version I tried yesterday is apparently not ok, for example even cnv objects don't exist. Does anyone noticed a previous windows build that is more stable? (even if it doesn't have all the extra objects) João --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. --Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling externals on linux
The library template should make your life easier: http://puredata.info/docs/developer/LibraryTemplate With it, you can build on Windows/MinGW,Windows/Cygwin, GNU/Linux, Mac OS X, Android, iPhoneOS... .hc On Thu, 21 Apr 2011 15:15 +0100, Andrew Hassall a.r.hass...@gmail.com wrote: I've been building externals on windows but now i need to build on linux to use debugging tools. Ive been trying to build my .c files and can't seem to get them to work. Can anyone give me some instructions/ a good walk through? I've also tried to create a make file but I don't really understand them and couldn't get it to work. Thanks Andy ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pure data sound effect library running on iOS app
I answered there: http://stackoverflow.com/questions/6047390/pure-data-sound-effect-library-running-on-iphone/6047556#6047556 Basically, you want http://gitorious.org/pdlib/ .hc On May 18, 2011, at 11:45 AM, Tomas Čerkasas wrote: Dear All, i'll just repeat the question I've asked in http://stackoverflow.com/questions/6047390/pure-data-sound-effect-library-running-on-iphone : i wonder if someone managed to use [Pure data][1] sound library as an external library of the an iOS app. [Pure data wiki][2] claims it can be compiled only on jailbroken iOS device. [iPD project][3] claims to be 'Pd ported to iPhone OS to be used as an audio/control engine', but it doesn't mention anything considering wheteher it can only be deployed to jailbroken devices. Has anyone made the pure data library to work on iOS device app, which successfully got approved by AppStore? Thanks in advance, tomas [1]: http://puredata.info/ [2]: http://puredata.info/docs/developer/BuildingPdForiPhone [3]: http://code.google.com/p/ipd/ to ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] hello-hallo-salut-konichiwa-ciao-hola-messalame
Its defintiely been long enough for the lazy consensus. If you are still interesting, post your sourceforge account name, and I'll add you. .hc On May 6, 2011, at 10:37 AM, yvan volochine wrote: hi, I'd like to join the Pure-Data developers team on sf.net. I am a musician (and programmer) and I have been using pd for some years (like 5 years ago) to eventually use SuperCollider only. now that I managed to make my girlfriend switch to linux and that she uses pd a lot (daily), I had to go back to pd myself sometimes, in order to help her ;) while doing this, I realized that pd still lacks some basic things that would make it cooler, (like some of my recent patches on sf.net, recentfiles, menubar, etc). therefore, when I have some free time, I like to make patches for pd and make it more user-friendly to incite more people to use it (instead of.. say.. max ? :P) because I think that open source is the future. I am not very good with C but I can help with fixing small bugs or make the UI better, etc.. you can find some patches to pd-src and some gui-plugins that I use here: http://github.com/gusano/pd_stuffs some of my other projects: http://yvanvolochine.com thanks for reading! cheers, _y ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev kill your television ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] hello-hallo-salut-konichiwa-ciao-hola-messalame
On May 27, 2011, at 12:02 PM, yvan volochine wrote: On 05/27/2011 05:18 PM, Hans-Christoph Steiner wrote: Its defintiely been long enough for the lazy consensus. If you are still interesting, post your sourceforge account name, and I'll add you. cool =) my username: elgusanorojo cheers, _y Welcome! I am curious, are you planning on moving your GUI plugin development to the pure-data SVN? If so that would make eventual integration into Pd-extended easier. But its not necessary. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-cvs Digest, Vol 75, Issue 5
macosx104-powerpc should be ok now, but I botched the upgrade on the ubuntu machine, so its in an odd state until I can get physical access to the machine. That should happen tomorrow morning. .hc On May 30, 2011, at 9:11 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-05-30 12:00, pd-cvs-requ...@iem.at wrote: Message: 1 Date: Thu, 1 Jan 1970 07:39:28 -0500 (EST) From: p...@macosx104-powerpc.idmi.poly.edu (Pd User) Subject: [PD-cvs] autobuild: pd-extended macosx104-powerpc 1970-01-01 03.15.05 seems like the system time of the osx10.4 build bot has been reset. Message: 2 Date: Sun, 29 May 2011 08:02:52 -0400 (EDT) From: p...@ubuntu-dapper-i386.idmi.poly.edu Subject: [PD-cvs] autobuild: pd-extended ubuntu-lucid-i386 2011-05-29 08.01.11 sh: cannot create /dev/null: Permission denied and Message: 3 Date: Sun, 29 May 2011 08:03:33 -0400 (EDT) From: p...@ubuntu-dapper-i386.idmi.poly.edu Subject: [PD-cvs] autobuild: pd-extended ubuntu-natty-i386 2011-05-29 08.01.11 sh: cannot create /dev/null: Permission denied seems like the chroot jails do not have /dev mounted properly. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3jl5MACgkQkX2Xpv6ydvRb4wCgrV8BNUeB8BnQetNEUOGPrnur AHkAn24Q4aay8LNi2HGoJOYsOPAdbFSe =yP5r -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-exxtended repo?
The repos are all listed here: http://puredata.info/docs/developer/GettingPdSource For details on the Pd-extended git workflow that I use, see the Pd- extended section of this: http://puredata.info/docs/developer/GitWorkflows .hc On Jun 2, 2011, at 5:57 PM, Albert Graef wrote: Where is the repository with the current pd-extended sources? (I.e., the pd-extended 0.43.) I thought it already was in git, but when browsing pd-extended.git on sf.net, it seems to be empty, and trying to clone that repo gives an error. TIA, Albert -- Dr. Albert Graf Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev “We must become the change we want to see. - Mahatma Gandhi ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-exxtended repo?
Oops, sorry, I messed up the post-receive hooks stuff. It should be fixed now, and commits should be emailed to pd-cvs also. .hc On Jun 3, 2011, at 11:50 AM, Albert Graef wrote: On 06/03/2011 04:48 PM, Hans-Christoph Steiner wrote: The repos are all listed here: http://puredata.info/docs/developer/GettingPdSource Yes, I know that page and I also know how to find my way on sf.net. The pure-data and pd-anywhere git repos I can browse and clone without problems, it's just the pd-extended repo that doesn't work for me. Here's what I get: $ git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pd- extended.git Cloning into pd-extended... fatal: The remote end hung up unexpectedly Using the ssh protocol with my sf.net account doesn't work either: $ git clone ssh://agr...@pure-data.git.sourceforge.net/gitroot/pure-data/pd-extended Cloning into pd-extended... agr...@pure-data.git.sourceforge.net's password: fatal: bad config file line 12 in ./config fatal: The remote end hung up unexpectedly (My git version is 1.7.3.4, using openSUSE Linux 11.4.) When I try to browse the tree of that repo at http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=tree , it just gives me a 404 - Reading tree failed, and the log page doesn't show any commits. Am I the only one with that problem? I tried since yesterday, and I always get the same error message. Have the contents of this repo been removed? Is it for project members only? Downloading the pd-extended sources from the auto-build server via rsync works for me, but that's rather inconvenient. Thanks, Albert -- Dr. Albert Graf Dept. of Music-Informatics, University of Mainz, Germany Email: dr.gr...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de WWW:http://www.musikinformatik.uni-mainz.de/ag You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-exxtended repo?
On Jun 3, 2011, at 5:07 PM, Albert Graef wrote: On 06/03/2011 10:47 PM, Albert Graef wrote: On 06/03/2011 09:50 PM, Hans-Christoph Steiner wrote: Oops, sorry, I messed up the post-receive hooks stuff. It should be fixed now, and commits should be emailed to pd-cvs also. Thanks, it works now. :) BTW, Hans, I think I read somewhere that it was planned to merge the GUI improvements in pd-extended back into vanilla. Are there still any plans to do so? I usually don't need all the stuff that comes bundled with pd- extended, but I really like the magic glass and the coloring of objects, inlets/outlets and cables. That's also great for teaching Pd. That's really up to Miller. I've know moved the Pd-extended core to be based off of the pure-data git, so the Pd-extended changes are now a set of patches against pure-data (see the patch_series branch). But with 0.43, there are already many things that have been incorporated into pure-data. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] commit emails from git: pure-data and pd-extended
I just setup a 'post-receive' hook in both 'pure-data' and 'pd- extended.git' git repos on SourceForge. This hook sends the commits to pd-...@iem.at to join the SVN emails as well. Let me know if this is a problem for anyone. I messed up the pd- extended.git one before, but now that that problem is ironed out, I figured it would be good to have commit hooks for 'pure-data' as well. .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] New externals
Hey Brian, Welcome, glad to see more libraries being produced. One thing that should make your life a lot easier is using the library template. It handles building on GNU/Linux, all Debian flavors (kFreeBSD, etc), Mac OS X Universal, Windows/MinGW and Windows/Cygwin. iOS and Android are also supported, though much less tested. Provided you write your objects to be one class per .c file, its really easy to use. Here are the docs: http://puredata.info/docs/developer/LibraryTemplate It also provides an easy path for packaging your library for Debian. .hc On May 29, 2011, at 3:20 PM, Brian Neltner wrote: Dear Puredata folks, I have a new external that does HSI (hue, saturation, intensity) to RGB conversion. There is already an existing HSV2RGB function, but HSI is a more sensible color space for LED lighting (which is what I use my external for). I don't want to get involved in the PureData development community really, given the numerous current demands on my time. However, I think that others may want this external so I was wondering if there is a simple way to upload it. As is, you just run the makefile using gcc on either a mac or linux to produce the external. I don't know how to use windows, but I imagine someone could figure out how to modify the makefile to target the platform if they wanted. I also included a usage patch showing how I use it to control LED lighting over OSC through a MIDI controller. Sorry if it's a bit messy, I grew up on Max/MSP where we just wire everything and then hide them. I didn't realize that hiding in PD is done with some kind of window and so I didn't do things like send and receive. Should work though. I'd also be curious if anyone knows of a datarate limiting object for messages. Right now, I'm using buddy along with a metronome to accomplish the task (pretty straightforward), but it seems like a task that other people might be interested in -- for instance in cases where events are overwhelming the CPU and there is a desire to limit the rate of messages when the CPU is being overutilized. In my patch, I use it to limit the maximum datarate physically being sent out over UDP to my wifi lights because too high of datarates result in lags at the 802.11b level. The other object that I found was strangely missing was the ability to do powers or logarithms inside of an expr. Probably been brought up before, but I wanted to do logarithmic scaling of a dial output to control the speed of hue rotation of lighting. I ended up doing it with an any mode sync, pow, and an expr on the exponent but it was messy and perhaps tricky for someone with less experience to figure out how to do. Best, Brian Neltner hsi2rgb .zip hsi2rgb .pd_darwin hsi2rgb .pd_linux directosc.pd___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] web portal for builds (jenkins)
So my current job involved setting up a Jenkins build automation server, so I figured I could also set one up for Pd as well. The nice thing about it is that all the config can be done with the web interface. So that means I can give certain devs their own accounts so they can setup and manage their own nightly builds. It should be possible to set up builds on all platforms and have them automatically upload the builds. I figure this could be most useful for libraries like Gridflow, Gem, etc. Anyone interested? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] control backspace inside tk entry
On Jun 10, 2011, at 2:03 AM, Jonathan Wilkes wrote: --- On Fri, 6/10/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] control backspace inside tk entry To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev pd-dev@iem.at Date: Friday, June 10, 2011, 6:07 AM Looking forward to an update on your search plugin, its already really good. I think that the Tk text widget has all of this stuff built into it. Then you just need to lock it down a bit to act like a Tk entry. From http://www.tcl.tk/man/tcl8.5/TkCmd/text.htm (under Bindings): [29] Meta-backspace and Meta-Delete delete the word to the left of the insertion cursor. Unfortunately I don't seem to have a Meta key anywhere on my keyboard. Tried ctrl-delete, alt-delete, fn-delete, Super-delete, finally tried ctrl-alt-delete then logged in again. (Oops.) I'm already using a combobox instead of an entry widget (to get a drop-down history), and I have a feeling it would be a royal pain to get the text widget to act like a combobox. What's worse is that these default bindings don't seem to exist for entry. Evidently no one who uses tk needs to delete whole words unless there are multiple lines... The other thing to check is whether the ttk entry supports those bindings. ttk is included in Tcl/Tk 8.5. The puredata 0.43 Debian/ Ubuntu/Mint package uses 8.5, and Pd-extended uses 8.5. .hc If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
Yeah, I think its known its broken on Windows. I'll try to get to it when I can, but with a baby coming soon, that might not happen for a bit. Patches definitely welcome, if anyone figures it out! .hc On Jun 19, 2011, at 2:36 PM, Tris Whyte wrote: hello people, is it known that the autobuild of pdextended does not work on vista?, or is it just my laptop thats the trouble? ive never got the autobuild to work, but it does state that its only for xp. if its needed i could help somehow, im dying to try out the new tcl on sindows. would you need more info on my setup? is this even the right place to ask? (by not work i mean it just doesnt run)(wsh is running in the task manager however) thanks for your time :-) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] revised search-plugin.tcl
That's quite nice, looks and works very well. You've taken my sketch and made it something far beyond what it was originally. One thing, I notice that for objects' help files, you strip the paths. That make sense, except it does the same for all_about* patches. Also, that could get confusing when a search result finds something in an abstraction and its help file. .hc On Jun 16, 2011, at 3:50 PM, Jonathan Wilkes wrote: Here's a revised version of the search-plugin that Hans started: * fixed problem with double results if a path dir was a subdir of another * can search for phrases by using double quotes * search for whole words or partial matches * search for all or any terms * better scrollbar (ttk::scrollbar) * Google-style search history (press the down-arrow in the search box to make it appear, Escape to make it go away) * hacked a proc to get control-delete to delete previous word Requires tcl/tk 8.5. Works best with the revised pddp docs (i.e., if you want to search by the keywords listed you'll need them). -Jonathansearch- plugin.tcl___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] revised search-plugin.tcl
On Jun 20, 2011, at 6:55 PM, Jonathan Wilkes wrote: --- On Mon, 6/20/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] revised search-plugin.tcl To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev pd-dev@iem.at Date: Monday, June 20, 2011, 4:37 PM That's quite nice, looks and works very well. You've taken my sketch and made it something far beyond what it was originally. One thing, I notice that for objects' help files, you strip the paths. I strip out everything except the immediate parent. That way you can still tell the difference between libs-- intimacy/love-help.pd vs. tennis/love-help.pd. But I don't see a reason to display /usr/local/softwares/classic-90s-interfaces/tinytinyscrollbarzplzthx/ pd/doc/externals/Dr.Externals/... One thing that might be useful to see is whether the library is included or whether its a user-installed lib. That make sense, except it does the same for all_about* patches. Also, that could get confusing when a search result finds something in an abstraction and its help file. I'm just testing it on pd vanilla at the moment: foo.pd displays as foo.pd, and foo-help.pd displays as foo-help.pd. Is it different for you? I'll rethink the all_about* regsub. Probably just displaying All About foo will look decent and not too repetitive... Yeah, that sounds good. .hc -Jonathan .hc On Jun 16, 2011, at 3:50 PM, Jonathan Wilkes wrote: Here's a revised version of the search-plugin that Hans started: * fixed problem with double results if a path dir was a subdir of another * can search for phrases by using double quotes * search for whole words or partial matches * search for all or any terms * better scrollbar (ttk::scrollbar) * Google-style search history (press the down-arrow in the search box to make it appear, Escape to make it go away) * hacked a proc to get control-delete to delete previous word Requires tcl/tk 8.5. Works best with the revised pddp docs (i.e., if you want to search by the keywords listed you'll need them). -Jonathansearch- plugin.tcl___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] revised search-plugin.tcl
On Jun 24, 2011, at 4:36 AM, IOhannes m zmoelnig wrote:
On 2011-06-23 01:05, Jonathan Wilkes wrote:
I think separating on by dir to get a distinction between root/user
accessible libraries won't work, like if I compile pd in ~/newest-
vanilla/
and search for included libs. (Plus MacOS/Win/GNU-Linux
distinctions...)
e.g., everything in /path/to/pd/bin/../extra would be
included,
whereas everything in /home/${USER}/ would be
user-installed.
well, the trick was not to look at the permissions of the directory.
but of course you are right, that the full path should not be the only
means for discrimination.
my original example noted /path/to/pd/ which of course could
resolved to
/home/me/newest-vanilla/
what makes things worse, is that for different instances of Pd, the
term
included and user-installed might get swapped.
e.g.
$ ~/pd-0.43/src/pd -path ~/pd-0.42/src/extra
would use the not-included-in-pd-0.43 [expr~] from pd-0.42,
In Tcl space, there are different variables to tell you this, and
they'll work cross-platform, and should work cross-installation (i.e.
in ~/newest-vanilla.) From pd-gui.tcl:
# root path to lib of Pd's files, see s_main.c for more info
set sys_libdir {}
# root path where the pd-gui.tcl GUI script is located
set sys_guidir {}
# user-specified search path for objects, help, fonts, etc.
set sys_searchpath {}
# hard-coded search patch for objects, help, plugins, etc.
set sys_staticpath {}
.hc
i would probably find it more convenient, if there was a
simple way to
see the full path of a certain object.
i can then figure out myself, whether this is
user-installed or
system-installed, and it helps me discriminate between
multiple entries
of the same name.
Could probably do a firefox style status bar to show the path when
the
mouse hovers over the respective link (otherwise it's pretty ugly
if it's
just in the search results for each result).
yes something like this.
i originally thought of using tooltips, but tried to avoid giving any
specifics.
Do you think the path is needed in the search results for any
reason other
than to resolve ambiguity between the same library being system-
installed
and user-installed at the same time? I mean, if someone just
wants to
know whether the object described by cyclone/foo-help.pd is
system- or
user-installed, they just click on the link and see the path is at
the top
of the help patch window.
well, the search results could be made anonymous buttons, since the
user
will see what they selected as soon as the patch opens anyhow.
it's mainly about convenience, and if i know that the system-installed
patch is sure to crash my installation, then i probably want to know
beforehand.
fgmasdr
IOhannes
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
I hate it when they say, He gave his life for his country. Nobody
gives their life for anything. We steal the lives of these kids. -
Admiral Gene LeRocque
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
Ok, it was a weird one, I think its fixed, please try it and let me know. .hc On Sun, 19 Jun 2011 23:51 +0100, Tris Whyte slippyc...@yahoo.com wrote: damn i wish i could code, maybe i should try and build it on vista, have successfully built it on linux before, i would just use the linux version but i use a lot of vsts and swapping between two O.Ss can be a bit tiresome. (kid on the way? somone has been doing the dirty!! congrats man:-) thank you ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] packaging the pddp docs
Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose. Here's the files in puredata-doc: http://packages.debian.org/sid/all/puredata-doc/filelist .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] packaging the pddp docs
On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes wrote: --- On Mon, 6/27/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose. The PDDP docs I did are all for vanilla objects (exceptions are expr family, and the other vanilla extras). If a new user clicks Help on a vanilla object, it should show the revised PDDP help patch by default. So instead of what you propose, please make something like a legacy-vanilla-help package. That way, if someone really prefers the old docs, they can still find them, and we won't waste new users' time by forcing them to use outdated and unmaintained docs (until they figure out they're supposed to download a separate package for the current vanilla help patches, which nobody has to do for any of the external packages). -Jonathan I agree that the PDDP docs are much better, that's why I want to get them out there more. Part of packaging is representing the upstream as it is and letting the user decide. So I think it makes sense to keep puredata-doc as what's included in the official tarball. As for Pd-extended, I think it should still use the PDDP docs, so like you say, showing the PDDP docs by default. I think that making the PDDP docs as their own package and distro will make it easier for you to get your work out to users. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] packaging the pddp docs
On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes wrote: --- On Tue, 6/28/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes wrote: --- On Mon, 6/27/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose. The PDDP docs I did are all for vanilla objects (exceptions are expr family, and the other vanilla extras). If a new user clicks Help on a vanilla object, it should show the revised PDDP help patch by default. So instead of what you propose, please make something like a legacy-vanilla-help package. That way, if someone really prefers the old docs, they can still find them, and we won't waste new users' time by forcing them to use outdated and unmaintained docs (until they figure out they're supposed to download a separate package for the current vanilla help patches, which nobody has to do for any of the external packages). -Jonathan I agree that the PDDP docs are much better, that's why I want to get them out there more. Part of packaging is representing the upstream as it is and letting the user decide. So I think it makes sense to keep puredata-doc as what's included in the official tarball. As for Pd-extended, I think it should still use the PDDP docs, so like you say, showing the PDDP docs by default. Ok. So we just need a plan of attack. If you can lead up this project, I will help as much as I can. Do you want to include the whole docs tree in the doc/pddp SVN? Or something else? It seems to me the easiest would be to start a separate repository for them, like on SourceForge, pddp is available: http://sourceforge.net/projects/pddp Or we could reorganize doc/pddp in the pure-data SVN. .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] packaging the pddp docs
On Jun 28, 2011, at 12:51 PM, Jonathan Wilkes wrote: --- On Tue, 6/28/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:33 PM On Jun 28, 2011, at 11:43 AM, Jonathan Wilkes wrote: --- On Tue, 6/28/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 5:11 PM On Jun 28, 2011, at 12:55 AM, Jonathan Wilkes wrote: --- On Tue, 6/28/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 6:27 AM On Jun 27, 2011, at 6:45 PM, Jonathan Wilkes wrote: --- On Mon, 6/27/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD-dev] packaging the pddp docs To: pd-dev@iem.at Date: Monday, June 27, 2011, 9:21 PM Now that the core Pd docs (i.e. /usr/lib/pd/doc/*) are split out into a separate Debian package, I think it could make sense to package the PDDP docs in a kind of mirror or replacement package. Something like pddp-doc. Jonathan, in particular, I was thinking that since you have wanted to work on all the patches there, we could set it up so the pddp-doc package mirrors the whole /usr/lib/pd/doc* directory and patch structure, have this in SVN, git, or whatever somewhere. Then people could choose the pddp-doc package if they so choose. The PDDP docs I did are all for vanilla objects (exceptions are expr family, and the other vanilla extras). If a new user clicks Help on a vanilla object, it should show the revised PDDP help patch by default. So instead of what you propose, please make something like a legacy-vanilla-help package. That way, if someone really prefers the old docs, they can still find them, and we won't waste new users' time by forcing them to use outdated and unmaintained docs (until they figure out they're supposed to download a separate package for the current vanilla help patches, which nobody has to do for any of the external packages). -Jonathan I agree that the PDDP docs are much better, that's why I want to get them out there more. Part of packaging is representing the upstream as it is and letting the user decide. So I think it makes sense to keep puredata-doc as what's included in the official tarball. As for Pd-extended, I think it should still use the PDDP docs, so like you say, showing the PDDP docs by default. Ok. So we just need a plan of attack. If you can lead up this project, I will help as much as I can. Do you want to include the whole docs tree in the doc/pddp SVN? I'm already kind of doing that with pd-l2ork. I've revised Miller's control/audio/ds tutorials. Pd-l2ork has fixed the crasher bug when a patch closes itself, so I've got a navigation toolbar in those tutorials that is currently incompatible with pd-extended/vanilla. I had no idea. Ico seems to work on his own. It would be great to have those bug fixes submitted to the patch tracker. The patch tracker is what Miller, IOhannes, Martin Peach, me and others use for keeping track of patches that are meant to go into pure-data core. Or something else? It seems to me the easiest would be to start a separate repository for them, like on SourceForge, pddp is available: http://sourceforge.net/projects/ pddp Or we could reorganize doc/pddp in the pure-data SVN. .hc Since Pd-extended and Pd-l2ork already use the PDDP docs, the only thing we're talking about here is providing PDDP docs for people who use vanilla, and that's a simple commit. So I don't see why I have to head up some new project and learn Debian packaging in order to meander toward (or around) that goal. Its not a new project. I see it as a better representation of what's currently happening. You are doing great work with the PDDP docs, I think we can make the structure of that project work better for you. Having it as a distinct entity means you are less encumbered by others when making decisions about what should happen with PDDP. That distinct entity can be either a folder in the pure-data SVN, a separate SourceForge project, or whatever we think is easiest. I think one of the first two options would work well. I'm happy to do all of the Debian packaging, that part would be easy for me. So what is it you want me to do? To start with, choose a repository to work out of. Shall we just reorganize the doc/pddp folder in pure-data SVN? Then make that the home of your PDDP work, and I'll package it for Debian
Re: [PD-dev] packaging the pddp docs
On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes wrote: I'm already kind of doing that with pd-l2ork. I've revised Miller's control/audio/ds tutorials. Pd-l2ork has fixed the crasher bug when a patch closes itself, so I've got a navigation toolbar in those tutorials that is currently incompatible with pd-extended/vanilla. I had no idea. Ico seems to work on his own. It would be great to have those bug fixes submitted to the patch tracker. The patch tracker is what Miller, IOhannes, Martin Peach, me and others use for keeping track of patches that are meant to go into pure-data core. He's also working off 0.42 currently, so submitting to the tracker would be pointless. I think someone was working to port the changes forward to 0.43, but Ico is currently on vacation and I'm not sure where they are in the process. I merged in a couple things from l2ork, like Joe Sarlo's Magic Glass and inlet/outlet highlighting. More patches would be great to have. Its not a new project. I see it as a better representation of what's currently happening. You are doing great work with the PDDP docs, I think we can make the structure of that project work better for you. Having it as a distinct entity means you are less encumbered by others when making decisions about what should happen with PDDP. That distinct entity can be either a folder in the pure-data SVN, a separate SourceForge project, or whatever we think is easiest. I think one of the first two options would work well. I'm happy to do all of the Debian packaging, that part would be easy for me. So what is it you want me to do? To start with, choose a repository to work out of. Shall we just reorganize the doc/pddp folder in pure-data SVN? Then make that the home of your PDDP work, and I'll package it for Debian, and make sure the new layout works in Pd-extended. That works. Should it be merged with the current pddp libdir? No, the 'pddp' lib is a standard Pd library of objects meant to support documentation. The idea of this chunk is a collection of reference and tutorials. What if, for now, we make doc/pddp/tutorials and add 2.control.examples, 3.audio.examples and 4.data.structures there. Then keep reference patches in doc/pddp for now while we figure out the best place for them. It might make sense, for example, to keep the reference patches in the 'vanilla' libdir in externals/vanilla. That's a library of all the vanilla core objects split out into a library. But its probably not quite yet time to do this, since that library is only vaguely defined now. .hc If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] packaging the pddp docs
On Jun 28, 2011, at 4:06 PM, Jonathan Wilkes wrote: --- On Tue, 6/28/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 8:52 PM On Jun 28, 2011, at 2:41 PM, Jonathan Wilkes wrote: --- On Tue, 6/28/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD-dev] packaging the pddp docs To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev@iem.at Date: Tuesday, June 28, 2011, 7:20 PM On Jun 28, 2011, at 1:10 PM, Jonathan Wilkes wrote: I'm already kind of doing that with pd-l2ork. I've revised Miller's control/audio/ds tutorials. Pd-l2ork has fixed the crasher bug when a patch closes itself, so I've got a navigation toolbar in those tutorials that is currently incompatible with pd-extended/vanilla. I had no idea. Ico seems to work on his own. It would be great to have those bug fixes submitted to the patch tracker. The patch tracker is what Miller, IOhannes, Martin Peach, me and others use for keeping track of patches that are meant to go into pure-data core. He's also working off 0.42 currently, so submitting to the tracker would be pointless. I think someone was working to port the changes forward to 0.43, but Ico is currently on vacation and I'm not sure where they are in the process. I merged in a couple things from l2ork, like Joe Sarlo's Magic Glass and inlet/outlet highlighting. More patches would be great to have. As far as I understand there are a lot of changes in Pd-l2ork to core Pd, and if you accepted them into Pd-extended it would introduce more discrepancies between vanilla and extended. If that's a possibility you'd entertain to get the some of the functionality that pd-l2ork adds, then I can help with this process. Bug fixes should definitely be included, other patches are on a case by case basis. Accepting patches is a time consuming process, especially if the patch submitted are not super clean or has not been thoroughly tested. That's the main reason for patches to be rejected or ignored. I've gone thru a lot of patches from l2ork before, and found that they were not well tested, sometimes didn't even apply cleanly, and sometimes introduced new bugs. It seems that Ico didn't want to work thru the patch process, and instead is working on a fork. That's a good way to develop solid, well tested patches so it could be that a lot of the l2ork stuff is ready to be resubmitted. Well, like I said, it's still based off 0.42. When it gets ported to 0.43, maybe we can figure out a way to do this. While the pd-gui Tcl code is very different, most of the pd C code was unchanged in 0.42 -- 0.43. So stuff that doesn't really touch the Tcl code should be really easy to apply to 0.43. .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
Yeah, that's a annoyance of that build system. I think you need to make sure your source dir is called 'pd', not something like 'pure- data' or 'pure-data.git'. We really should finalize the configure.ac and Makefile.am for MinGW. Its quite close. I think someone just needs to figure out how to do the final linking using g++ to link the C ++ ASIO files and C files from the rest. .hc On Jun 29, 2011, at 4:38 PM, Patrice Colet wrote: hello, I've been trying to comile pd-vanilla with makefile.mingw but something weird is happening, the file in makefile.dependencies aren't compiled, I could figure out why. - Hans-Christoph Steiner h...@at.or.at a écrit : Ok, it was a weird one, I think its fixed, please try it and let me know. .hc On Sun, 19 Jun 2011 23:51 +0100, Tris Whyte slippyc...@yahoo.com wrote: damn i wish i could code, maybe i should try and build it on vista, have successfully built it on linux before, i would just use the linux version but i use a lot of vsts and swapping between two O.Ss can be a bit tiresome. (kid on the way? somone has been doing the dirty!! congrats man:-) thank you ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Jun 30, 2011, at 3:44 AM, Patrice Colet wrote: all right it was because of source name indeed because of this: cvs_root_dir = ../.. pd_src = $(cvs_root_dir)/pd pd.exe could be compiled with this file by adding s_utf8.h to HEADERS AH, you are working with an old version of the makefile.mingw, I think. Check the file in the pd-extended.git for the most recent version. (replacing filenames by $(wildcard ../src/*.h) works very well) Wildcards in build systems are generally not a good idea. When building software, including a file that is not meant to be included is an error. Same goes for not including a file that is meant to be included. By specifying the files individually, the build system can check both of those errors. Using wildcards it will not. and s_utf8.c have to be added in SRC by testing everything I've seen that asio drivers loading problem comes from a conflict with jack because since I've uninstalled jack server the asio devices are displayed into asio devices list and working. the multiplatform build system is now very cryptic, it's very hard to figure anything out. There is pd/configure.ac which does the detection and setting of variables like LINUX, ASIO, etc. There is pd/Makefile.am for the main Makefile. Then each folder has its own Makefile.am for building that folder (i.e. asio, pd, portaudio, po, etc). Ignore all Makefile and Makefile.in files. Those are generated from Makefile.am. .hc - Hans-Christoph Steiner h...@at.or.at a écrit : Yeah, that's a annoyance of that build system. I think you need to make sure your source dir is called 'pd', not something like 'pure- data' or 'pure-data.git'. We really should finalize the configure.ac and Makefile.am for MinGW. Its quite close. I think someone just needs to figure out how to do the final linking using g++ to link the C ++ ASIO files and C files from the rest. .hc On Jun 29, 2011, at 4:38 PM, Patrice Colet wrote: hello, I've been trying to comile pd-vanilla with makefile.mingw but something weird is happening, the file in makefile.dependencies aren't compiled, I could figure out why. - Hans-Christoph Steiner h...@at.or.at a écrit : Ok, it was a weird one, I think its fixed, please try it and let me know. .hc On Sun, 19 Jun 2011 23:51 +0100, Tris Whyte slippyc...@yahoo.com wrote: damn i wish i could code, maybe i should try and build it on vista, have successfully built it on linux before, i would just use the linux version but i use a lot of vsts and swapping between two O.Ss can be a bit tiresome. (kid on the way? somone has been doing the dirty!! congrats man:-) thank you ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet Mistrust authority - promote decentralization. - the hacker ethic -- Patrice Colet You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Fri, 01 Jul 2011 11:08 +0200, IOhannes m zmölnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/01/2011 08:40 AM, Patrice Colet wrote: needs to figure out how to do the final linking using g++ to link the C ++ ASIO files and C files from the rest. why not using cc for compiling portaudio files, because you need a c++ compiler to compile c++ code. and you need a c++ linker to link with c++ objects (such as the portaudio objects) the trick to use g++ for linking, is to use a dummy .cpp file, so autotools will automatically choose g++. something like: snip nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif /snip It would be worth trying: LD=$CXX It might be more complicated than that, but the makefile.mingw seems to disprove this: - You must use your C++ compiler when compiling main() (e.g., for static initialization) - Your C++ compiler should direct the linking process (e.g., so it can get its special libraries) Other potentially useful info here: http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Fri, 01 Jul 2011 19:36 +0200, IOhannes m zmölnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: the trick to use g++ for linking, is to use a dummy .cpp file, so autotools will automatically choose g++. something like: snip nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif /snip It would be worth trying: LD=$CXX http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries That solution at the bottom of that page looks easy but a bit odd. I suppose its the 'official' way. Patco, do you think you can try to get that working? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any luck with the LD=$(CXX) option? .hc On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote: I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't. On Fri, 01 Jul 2011 19:36 +0200, IOhannes m zmölnig On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: the trick to use g++ for linking, is to use a dummy .cpp file, so autotools will automatically choose g++. something like: snip nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif /snip It would be worth trying: LD=$CXX http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries That solution at the bottom of that page looks easy but a bit odd. I suppose its the 'official' way. Patco, do you think you can try to get that working? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote: - Hans-Christoph Steiner h...@at.or.at a écrit : Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any luck with the LD=$(CXX) option? Still same error, this is exactly like this one: http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences. I tried changing the if ASIO section in pd/Makefile.am to this: if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif And it did indeed switch to using g++, but for compiling too, and that triggers the same issue. It seems that you can't compile portaudio WMME with g++, and the current build system is using g++ by default. So I think we actually need the opposite than that solution. If we include the ASIO files, automake switches to g++. So we need to force portaudio to always be built using gcc. Anyone have any ideas there? .hc .hc On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote: I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't. On Fri, 01 Jul 2011 19:36 +0200, IOhannes m zmölnig On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: the trick to use g++ for linking, is to use a dummy .cpp file, so autotools will automatically choose g++. something like: snip nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif /snip It would be worth trying: LD=$CXX http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries That solution at the bottom of that page looks easy but a bit odd. I suppose its the 'official' way. Patco, do you think you can try to get that working? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet Mistrust authority - promote decentralization. - the hacker ethic -- Patrice Colet Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
Hmm, that sounds like progress. Perhaps removing CC=g++ and then adding something like this would work: if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif .hc On Jul 5, 2011, at 7:04 AM, Patrice Colet wrote: I've removed this in configure.ac: # ASIO is a C++ library, so if its included, then use g++ to build CC=g++ compiles fine, only pd.exe is not working but pd.dll is fine, everything is built. from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC. - Hans-Christoph Steiner h...@at.or.at a écrit : On Jul 3, 2011, at 3:31 AM, Patrice Colet wrote: - Hans-Christoph Steiner h...@at.or.at a écrit : Ah, right, supporting LTLIBRARIES would be a bigger reorg. Any luck with the LD=$(CXX) option? Still same error, this is exactly like this one: http://lists.puredata.info/pipermail/pd-cvs/2010-08/020963.html the only solution that is working so far is about using CC to compile portaudio, I don't know if I could get time to reorg the build system for libtool conveniences. I tried changing the if ASIO section in pd/Makefile.am to this: if ASIO EXTRA_SUBDIRS += asio # automake hack to force linking with g++ lib_LTLIBRARIES = libdummy.la libdummy_la_SOURCES = # Dummy C++ source to cause C++ linking. nodist_EXTRA_libdummy_la_SOURCES = dummy.cxx endif And it did indeed switch to using g++, but for compiling too, and that triggers the same issue. It seems that you can't compile portaudio WMME with g++, and the current build system is using g++ by default. So I think we actually need the opposite than that solution. If we include the ASIO files, automake switches to g++. So we need to force portaudio to always be built using gcc. Anyone have any ideas there? .hc .hc On Jul 2, 2011, at 7:01 AM, Patrice Colet wrote: I've found the odd part of that page is that they use LTLIBRARIES variable while pd/src/Makefile.am doesn't. On Fri, 01 Jul 2011 19:36 +0200, IOhannes m zmölnig On 07/01/2011 06:24 PM, Hans-Christoph Steiner wrote: the trick to use g++ for linking, is to use a dummy .cpp file, so autotools will automatically choose g++. something like: snip nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif /snip It would be worth trying: LD=$CXX http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html#Libtool-Convenience-Libraries That solution at the bottom of that page looks easy but a bit odd. I suppose its the 'official' way. Patco, do you think you can try to get that working? .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet Mistrust authority - promote decentralization. - the hacker ethic -- Patrice Colet Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs -- Patrice Colet [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Jul 11, 2011, at 5:08 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-05 13:04, Patrice Colet wrote: I've removed this in configure.ac: # ASIO is a C++ library, so if its included, then use g++ to build CC=g++ compiles fine, only pd.exe is not working but pd.dll is fine, everything is built. from all I've read in gnu manuals, automake automatically set g++ for cpp files so there is no need to set CC. this what i have been suggesting (i think) attached is a diff against upstreams Pd that should use g++ for linking when using ASIO (it might use g++ for all linking, but that should be ok as well), by letting automake choose (rather than forcing it to use a special linker like g++ (which hardcodes the compiler name...uähh)) it works on linux :-) We have the opposite problem than that automake hack is trying to solve. When ASIO is including, then everything including portaudio is built and linked using g++. Portaudio fails to build with g++, so we need to find a way to make only ASIO build with g++, while the rest build with gcc. I think automake will still choose g++ for linking since its choosing g++ for ASIO. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Jul 11, 2011, at 1:06 PM, Patrice Colet wrote: - Patrice Colet colet.patr...@free.fr a écrit : The problem I'm encountering on win32 with makefile.am is that pd.dll is not built following this doc page: http://serghei.net/docs/programming/autobook-1.1/dlls20with20libtool.html I've added those lines in makefile.am: if WINDOWS LIBS += -lwsock32 -lwinmm -lole32 pd_CFLAGS += -DUSEAPI_MMIO -DPD_INTERNAL pd_SOURCES += s_audio_mmio.c s_midi_mmio.c lib_LTLIBRARIES = libpd.la libpd_la_SOURCES = $(pd_sources) libpd_la_LDFLAGS = -no-undefined pd_LDADD = libpd.la bin_SCRIPTS = endif it's getting closer because dll building is initiated: Creating library file: .libs/libpd.dll.a pd.dll isn't a libtool standard file but the linker complains: pd-m_sched.o:m_sched.c:(.text+0x1514): undefined reference to `_imp__pthread_mutex_lock' pd-m_sched.o:m_sched.c:(.text+0x1528): undefined reference to `_imp__pthread_mutex_unlock' pd-m_sched.o:m_sched.c:(.text+0x1920): undefined reference to `_imp__pthread_mutex_trylock' pd-s_loader.o:s_loader.c:(.text+0x233): undefined reference to `dlopen' pd-s_loader.o:s_loader.c:(.text+0x247): undefined reference to `dlsym' pd-s_loader.o:s_loader.c:(.text+0x4a7): undefined reference to `dlerror' pd-d_soundfile.o:d_soundfile.c:(.text+0x27f): undefined reference to `_imp__pthread_mutex_lock' try changing: LIBS += -lwsock32 -lwinmm -lole32 to: LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl .hc snip it's seems closer - IOhannes m zmoelnig zmoel...@iem.at a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-11 17:59, Hans-Christoph Steiner wrote: We have the opposite problem than that automake hack is trying to solve. When ASIO is including, then everything including portaudio is built and linked using g++. Portaudio fails to build with g++, so we need to find a way to make only ASIO build with g++, while the rest build with gcc. I think automake will still choose g++ for linking since its choosing g++ for ASIO. ah thanks for clarifying the problem. however: automake will chose the _compiler_ on a file-per-file basis; so forcing the _linker_ to be CXX for pd, should have no effect on the compilining portaudio (and creating the portaudio library) fgamdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4bIPIACgkQkX2Xpv6ydvTdYwCfUlNGwDybirLriNT1O6UwV8v1 j68AnjgGtdThIklLxRGBSN9vK4anSbjx =HAmS -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 10.6 64bit autobuild computer will be inaccessible until monday
As long as there is a build tonight, which there should be, we should have a working 10.6 build, so its fine by me. Thanks for the update! .hc On Jul 11, 2011, at 6:28 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dear devs, chaos.medien.uni-weimar.de will most probably have downtime until sunday because it's the final week in the semester and we'll transform the room into an exhibition space. I can't say when exactly it will start, maybe tomorrow or on thursday but service will be restored on monday. sorry for the inconvenience. max -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk4beRkACgkQ3EB7kzgMM6LAagCfQ+uQUe8+8JDzrHtgaUnXvAqD WGAAmQHOG6vAHYFDk3cl+JW7anCBNAPQ =V9Fg -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Tue, 12 Jul 2011 09:22 +0200, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-07-11 19:37, Hans-Christoph Steiner wrote: That makes me think so ./configure is finding libdl find, and then setting HAVE_LIBDL, and then the code in s_loader.c is going to do both HAVE_LIBDL and the MSW section below it. So I guess we should force this build system to not use HAVE_LIBDL on Windows, or fix the define to be something like: shouldn't it be more like trying all available dylib loading mechanisms? e.g. if HAVE_LIBDL than try using dlopen, if that fails fall back to the w32 native LoadLibrary. and finally, Pd should probably still be able to compile even if no dylib mechanism is present (think iOS). if the system cannot loading libraries, than Pd won't be able to load externals, but internals and abstractions will continue to work. Yes, defiitely. Here's how I am thinking (also attached): --- a/src/s_loader.c +++ b/src/s_loader.c @@ -178,8 +178,7 @@ gotone: } makeout = (t_xxx)dlsym(dlobj, symname); /* fprintf(stderr, symbol %s\n, symname); */ -#endif -#ifdef MSW +#elif defined(_WIN32) sys_bashfilename(filename, filename); ntdll = LoadLibrary(filename); if (!ntdll) @@ -189,6 +188,8 @@ gotone: return (0); } makeout = (t_xxx)GetProcAddress(ntdll, symname); +#else +# warning No dynamic loading mechanism specified, libdl or WIN32 required for loading externa #endif if (!makeout) diff --git a/src/s_loader.c b/src/s_loader.c index c3e2d3a..9456031 100644 --- a/src/s_loader.c +++ b/src/s_loader.c @@ -178,8 +178,7 @@ gotone: } makeout = (t_xxx)dlsym(dlobj, symname); /* fprintf(stderr, symbol %s\n, symname); */ -#endif -#ifdef MSW +#elif defined(_WIN32) sys_bashfilename(filename, filename); ntdll = LoadLibrary(filename); if (!ntdll) @@ -189,6 +188,8 @@ gotone: return (0); } makeout = (t_xxx)GetProcAddress(ntdll, symname); +#else +# warning No dynamic loading mechanism specified, libdl or WIN32 required for loading externals! #endif if (!makeout) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] replace spaces in list class names with hyphens
On Jul 15, 2011, at 4:18 AM, IOhannes m zmölnig wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
I've got a working tooltip prototype going, and I just noticed that
all the list classes screw up things on the tcl side, because with
list append (for example) it suddenly looks like there is one
more arg to the proc.
Are there any other objects that have a space in the creator name?
If not, could we just make it official that creator names can't
have spaces, and change all the list foo creators objects to
list-foo?
This would be transparent to the user*, since they can still type
list foo and list_new will instantiate the right class.
(Although going forward I would suggest using list-foo as it is
the standard for all the listabs abstractions.)
while i was always opposed to using object names with spaces [1], i
don't think that we should forbid it at all. i would rather have the
GUI
side have an idea of what is the object name and what are the
arguments
(e.g. create {list split} {1} rather than text list split 1)
than to
add arbitrary limitations.
some externals use proxy objects for full-fledged non-first inlets,
and those proxies tend to have hard to type names as well. how do
your
tooltips deal with those?
I have to agree. Though it is more work, I think we should support
object names with any character in them. Tcl can definitely do it
without much difficulty, as long as the details aren't ignored.
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] replace spaces in list class names with hyphens
Besides [list], what are other exceptions to the rule of the class
being all characters before the first space? It might just be easier
to code in an exception for [list].
.hc
On Jul 15, 2011, at 1:41 PM, Miller Puckette wrote:
THere isn't a 1-to-1 correspondence between the string that invokes an
object and its class -- hence, list can give rise to several
different
classes, but also, there are sometimes multiple classes in Pd that
have
the same class name, like select. The string was originally only
there to help in pringing out error messages, (i.e. human readable),
not
as a way to disamiguate anything.
I think the only way to know everything relevant is to know the whole
argument list and parse it, ouch...
cheers
Miller
On Fri, Jul 15, 2011 at 09:46:38AM -0700, Jonathan Wilkes wrote:
--- On Fri, 7/15/11, IOhannes m zmölnig zmoel...@iem.at wrote:
From: IOhannes m zmölnig zmoel...@iem.at
Subject: Re: [PD-dev] replace spaces in list class names with
hyphens
To: pd-dev@iem.at
Date: Friday, July 15, 2011, 10:18 AM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
I've got a working tooltip prototype going, and I just
noticed that all the list classes screw up things on the tcl
side, because with list append (for example) it suddenly
looks like there is one more arg to the proc.
Are there any other objects that have a space in the
creator name? If not, could we just make it official
that creator names can't have spaces, and change all the
list foo creators objects to list-foo?
This would be transparent to the user*, since they can
still type list foo and list_new will instantiate the
right class. (Although going forward I would suggest
using list-foo as it is the standard for all the listabs
abstractions.)
while i was always opposed to using object names with
spaces [1], i
don't think that we should forbid it at all. i would rather
have the GUI
side have an idea of what is the object name and what are
the arguments
(e.g. create {list split} {1} rather than text list
split 1) than to
add arbitrary limitations.
some externals use proxy objects for full-fledged
non-first inlets,
and those proxies tend to have hard to type names as
well. how do your
tooltips deal with those?
So if object foo has a 2nd inlet controlled by a proxy object
bar, which class is referred to by t_object *ob of glist_drawio
in g_text.c: foo or bar?
gfmasdr
IOhannes
[1]
https://sourceforge.net/tracker/index.php?func=detailaid=1544083group_id=55736atid=478072
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
=XO7J
-END PGP SIGNATURE-
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[T]he greatest purveyor of violence in the world today [is] my own
government. - Martin Luther King, Jr.
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] source repo for pd_l2ork
Is there any source repo like git or SVN for pd_l2ork? Having that would make collaboration much easier. If there isn't already something, I'd recommend starting a git repo for the 'pd' core part based on the pure-data git starting at 0.42.6. That'll also have the benefit of making it much easier for pd_l2ork to merge in changes from pure-data and pd-extended git. .hc If you are not part of the solution, you are part of the problem. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] amd64 pdextended nightly-builds
This is great, Pierre! The first part is easy, I added your IP to the 'hosts allow' list for uploaders. Next time the script runs, it should upload. One minor glitch, the dates are based on NYC/Eastern time, so you have to make sure your auto-build doesn't try to upload before midnight Eastern (-6 from CET). The 'debian-squeeze-amd64' part comes from the hostname. Yours will be tagged with whatever hostname your server has, then I'll put a little cron'd script to rename it. I did this for Andras' Ubuntu 64- bit builds. .hc On Jul 24, 2011, at 6:02 PM, Pierre Mersadier wrote: Hi list, it could be nice to provide more 64bits builds of pd-extended, I've just compiled pdextended on my webserver online 24/7, a debian squeeze amd_64 and it seams that all went fine. For this I've used the pd-extended-auto-builder.sh script that does all the job, and I have also added a cron job to run this script 1 time per day. So I have somes questions : a) how to share this debian package ? Because the final uploading procedure of pd-extended-auto-builder.sh fail... (for now I can host the packages on this webserver : http://88.191.140.38/ ) b) the final name of the debian package I have is : Pd-0.43.1-extended-20110724.deb which is not as significant as Pd-0.43.1-extended-debian-squeeze-amd64.deb so how to improve that ? Edit the Makefile in pd-extended/packages/linux_make ? rename it by hand... ? Pierre ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Access to computers should be unlimited and total. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Jul 17, 2011, at 8:59 PM, Patrice Colet wrote: - Patrice Colet colet.patr...@free.fr a écrit : I've got asio linking with g++ working, this is explained in here: http://www.mail-archive.com/libtool@gnu.org/msg11308.html # ASIO needs to go after PORTAUDIO in order for it to link properly if ASIO # automake hack to force linking with g++ SUBDIRS = ../asio # Dummy C++ source to cause C++ linking. nodist_EXTRA_libpd_la_SOURCES = dummy.cxx pd_LDADD += ../asio/libasio.la pd_LINK = $(CXXLINK) endif if WINDOWS lib_LTLIBRARIES += libpd.la libpd_la_SOURCES = $(pd_sources) libpd_la_LDFLAGS = -no-undefined LIBS += -lwsock32 -lwinmm -lole32 -lpthreadGC2 -ldl pd_CFLAGS += -DUSEAPI_MMIO -DPD_INTERNAL pd_SOURCES += s_audio_mmio.c s_midi_mmio.c pd_LDADD += libpd.la bin_SCRIPTS = endif now how can we fix startup/libdir.dll? when starting pd, console shows: C:/msys/1.0/home/patko/pd-extended/0.43/packages/win32_inno/build/ startup/libdir: can't load startup library'! I've tried in packages make install command after doing this into packages/win32_inno/Makefile: --- Makefile.old2011-07-18 00:55:45 + +++ Makefile2011-07-18 00:20:44 + @@ -57,14 +57,14 @@ @echo win32_inno install succeeded! build_pd: - cd $(pd_src)/src $(MAKE) -f makefile.mingw + $(MAKE) -C $(packages_src) $(DEST_PATHS) PD_NAME=Pd pd_install: build_pd # the autoconf/MinGW setup doesn't compile the extras yet # $(MAKE) -C $(pd_src)/src $(DEST_PATHS) bin # -$(MAKE) -C $(pd_src)/src $(DEST_PATHS) install - $(MAKE) -C $(pd_src)/src -f makefile.mingw $(DEST_PATHS) install + $(MAKE) -C $(packages_src) $(DEST_PATHS) install # install notes.txt into the help browser install -d $(DESTDIR)$(manualsdir)/$(PD_NAME) install -p $(pd_src)/src/notes.txt $(DESTDIR)$(manualsdir)/$ (PD_NAME) the build system stops after popping this error: ln -s ../extra/libdir/libdir.dll \ /home/patko/pd-extended/0.43/packages/build/startup/ libdir.dll ln: creating symbolic link `/home/patko/pd-extended/0.43/packages/ build/startup/libdir.dll' to `../extra/libdir/libdir.dll': No such file or directory make: *** [pd_install] Error 1 That should work since that happens every night when building with the makefile.mingw. I'll try that once we get the other changes into the git. Do you want to make a git patch for the fixes you've done so far? That way you're name will be in the git history, so you'll get credit. .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
Hey Katya, I'm very happy you're working on this, I think its a big and very valuable step for Pd for many reasons. For me, things like accessing large arrays and also working with UNIX timestamps and other large integers directly, make Pd a lot easier in cases that touch on those limitations. It brings Pd 99% to the goal of having a generic number type that handles all the floats and ints that are used with any frequency. Sounds like you've done a fair amount of testing. I think the big question that needs to be answered before this gets included is: can this be done without majoring impacting 32-bit operation? It sounds like you've covered that already. As for 64-bit floats to output, a quick hack to get things working is to just hammer samples down to 32- bits... .hc On Jul 27, 2011, at 3:39 AM, katja wrote: Hello, Triggered by a recent thread (http://lists.puredata.info/pipermail/pd-dev/2011-07/017022.html ) I've written alternative code for Pd classes like phasor~, osc~, and vcf~, in preparation for double precision builds of Pd. These classes currently employ Hoeldrich's method, a fascinating type punning trick for optimization of phase-wrapping jobs. Considering available data types in C, this method can not be translated to double precision input/output format. Phasor~ and osc~ are typically used by the dozens in Pd setups, and even a modest performance loss could be a show stopper for setups which are on the limit of acceptable CPU load. Fortunately it was possible to define double-ready versions without performance loss, by tedious elimination of redundancy instead of fancy bit hacking. How often must a phase be wrapped? Even at high frequencies like half the Nyquist rate, only one in four iterations goes out of bounds. On average it proves efficient to do the phase wrapping conditionally. Phasor~ profits most, being up to three times faster than before, at moderate frequencies. The others did not speed up so much, but at least none of them is slower than the original version, when both are compared within the same Pd build. Also, the alternative versions do not suffer from phase drift, like the Hoeldrich versions do. I have tested this on OSX / IntelMac for single and double precision builds. Performance may be different on other platforms / architectures. Macro PD_BIGORSMALL was redefined to work with arbitrary precision. A Pd running with PD_FLOATTYPE double immediately shouted at me that there's a lot more work to do. The audio API (PortAudio in this case) couldn't handle 64 bit output samples from dac~. Vectors are apparently read as type float, and maximum level digital noise is the useless output. I've not delved into this yet. Internally things seems to work well, for what I've seen so far. Ah, almost forgot to mention the pro's of a double precision Pd, if it will ever work: - indexing of large audio buffers with ample resolution for interpolation - accurate sine and sinc of small angles, useful for things like fractional delay - FFT with frames larger than 2^17, I hope - long sine sweeps without artifacts - probably many more of such meticulous dsp jobs, you name them If you're interested in double precision Pd, please find the attached pd_doubletest.zip with C code and test-patches. Let me know if you have test results on different platforms, or if you find stupid bugs in my code. Is anyone working on other aspects of double precision Pd? I'd like to join forces. Katja Vetter pd_doubletest.zip___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] amd64 pdextended nightly-builds
On Jul 28, 2011, at 7:39 AM, Pierre Mersadier wrote: Hi HansChristoph, Le mardi 26 juillet 2011 à 14:04 -0400, Hans-Christoph Steiner a écrit : Ok, its posting now on the auto-builds page :) .hc I now trying to work with pbuilder which seems to be a very good tool to build debian packages for differents versions of debian/ubuntu distributions, my goal is to provide multiples x86_64 builds for ubuntu natty/maverick/etc/... and debian stable/unstable/etc/... all these builds could be done on the same 64bits computer. From what I understand it is really doable with pbuilder, I did some tests this morning. somes questions/remarks : A) is there some debian rules for the whole pdextended source tree ? 'pd-extended/pd' contains './debian 'but if I run pdebuild it seems it build only pd and not all the externals... see logs : http://pastebin.com/EK8MhaDj B) alsoI had to delete pd/debian/patches/* because pdebuil wasn't able to apply patches to the source tree : snip... quilt --quiltrc /dev/null push -a || test $? = 2 Applying patch 01_big_endian.diff patching file src/s_audio_alsa.c Hunk #1 FAILED at 469. Hunk #2 FAILED at 581. 2 out of 2 hunks FAILED -- rejects in file src/s_audio_alsa.c Patch 01_big_endian.diff does not apply (enforce with -f) dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2 returned exit code 1 make: *** [build] Error 25 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting /var/cache/pbuilder/ccache filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//10491 and its subdirectories So, on my free time I'll continue to test/learn because these tools seems very powerfull ! This would be really awesome to have all those builds. pbuilder is a very powerful tool, but sadly, the Pd-extended package is a big hack and not created in a way that'll let you use pbuilder, as far as I know. Instead, I've been setting up chroots with debootstrap. The build scripts can already handle many chroots as long as they are in / var/chroot. Do you go to the pdcon 2011 in weimar ? My wife and I just had a baby one week ago, so I can't go this year. I've been to every other, and almost nothing else would have made me miss the PdCon. Its always been a great time and immersive experience. .hc The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] amd64 pdextended nightly-builds
On Jul 29, 2011, at 4:44 AM, Pierre Mersadier wrote: Le jeudi 28 juillet 2011 à 19:42 -0400, Hans-Christoph Steiner a écrit : On Jul 28, 2011, at 7:39 AM, Pierre Mersadier wrote: Hi HansChristoph, Le mardi 26 juillet 2011 à 14:04 -0400, Hans-Christoph Steiner a écrit : Ok, its posting now on the auto-builds page :) .hc I now trying to work with pbuilder which seems to be a very good tool to build debian packages for differents versions of debian/ubuntu distributions, my goal is to provide multiples x86_64 builds for ubuntu natty/maverick/etc/... and debian stable/unstable/etc/... all these builds could be done on the same 64bits computer. From what I understand it is really doable with pbuilder, I did some tests this morning. somes questions/remarks : A) is there some debian rules for the whole pdextended source tree ? 'pd-extended/pd' contains './debian 'but if I run pdebuild it seems it build only pd and not all the externals... see logs : http://pastebin.com/EK8MhaDj B) alsoI had to delete pd/debian/patches/* because pdebuil wasn't able to apply patches to the source tree : snip... quilt --quiltrc /dev/null push -a || test $? = 2 Applying patch 01_big_endian.diff patching file src/s_audio_alsa.c Hunk #1 FAILED at 469. Hunk #2 FAILED at 581. 2 out of 2 hunks FAILED -- rejects in file src/s_audio_alsa.c Patch 01_big_endian.diff does not apply (enforce with -f) dh_quilt_patch: quilt --quiltrc /dev/null push -a || test $? = 2 returned exit code 1 make: *** [build] Error 25 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package I: unmounting /var/cache/pbuilder/ccache filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//10491 and its subdirectories So, on my free time I'll continue to test/learn because these tools seems very powerfull ! This would be really awesome to have all those builds. pbuilder is a very powerful tool, but sadly, the Pd-extended package is a big hack and not created in a way that'll let you use pbuilder, as far as I know. Instead, I've been setting up chroots with debootstrap. The build scripts can already handle many chroots as long as they are in / var/chroot. Ok, I can try the chroot method, in fact I have already have a chrooted env for ubuntu on this server, but the way pbuilder works is just great (a one line command for build !). Build in a chroot environment seems to me much harder, as I dont know how to tell cron to run the comand inside the chrooted env... The build script already changes to each chroot. You just need to cron the ~pd/auto-build/pd-extended/scripts/auto-build/run-automated- builder build script, then it'll look into ~pd/auto-build for builds to run (in the form of named folders, i.e. pd-extended). And it'll run the pd-extended-auto-builder.sh in each chroot it finds in /var/chroot. (Also I understand that the only thing that pbuilder/pdebuild miss is ./debian folders (rules, changelog, etc) in each project (every externals and pd)... Maybe it is not a big deal as we can provide empty or fake infos to satisfy pdebuild ??) There is no debian/rules for that package. My guess is that it would be a fair amount of work, but I could be wrong. Plus if that approach is more interesting to you, that'll probably mean that more work that's interesting is better than less annoying work. .hc Do you go to the pdcon 2011 in weimar ? My wife and I just had a baby one week ago, so I can't go this year. I've been to every other, and almost nothing else would have made me miss the PdCon. Its always been a great time and immersive experience. I understand what you mean, I have 2 boys : 2 and 9 years old, and they take a loot of time and energy, but hey! I love them ! :D we keep in touch, pierre Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] menu checkbutton
Hmm, I think the grey85 was an attempt to match the default menu background. I don't quite remember. It seems to have no effect on Mac OS X. I'd be fine with black or default, I suppose. .hc On Jul 31, 2011, at 1:12 AM, Jonathan Wilkes wrote: Hi, What is the reason the Editmode menu checkbutton is changed to green on TRUE and has option -selectcolor grey85 instead of just a default black check? I tried making a demo menu with a checkbutton in wish (8.5) and didn't see any obvious bugs in MacOS Lion, WinXP, or Fedora15 with Gnome Shell. Additionally I could just set the variable associated with the widget, and the menu checkbutton would update correctly. -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev There is no way to peace, peace is the way. -A.J. Muste ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] tracker spam
How about turning off anonymous posting on the bug/patch/feature trackers? The spam rate is increasing, and the anonymous bug reports are either people who forgot to login, or otherwise quite low quality. .hc Begin forwarded message: From: SourceForge.net nore...@sourceforge.net Date: August 4, 2011 11:56:29 PM EDT To: SourceForge.net nore...@sourceforge.net Subject: [PD-dev] [ pure-data-Feature Requests-3386499 ] uftRFrmaytPSaihNksG Feature Requests item #3386499, was opened at 2011-08-05 03:56 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478073aid=3386499group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: abstractions Group: Next Release (example) Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: uftRFrmaytPSaihNksG Initial Comment: 2xRW1g a href=http://jbznfbwwzzwq.com/;jbznfbwwzzwq/a, [url=http://jrrefggrwqmn.com/ ]jrrefggrwqmn[/url], [link=http://hvlfkmizxyyi.com/]hvlfkmizxyyi[/ link], http://yvlthgsufwvc.com/ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478073aid=3386499group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tracker spam
On Aug 5, 2011, at 11:35 AM, IOhannes zmölnig wrote: On 08/05/2011 05:08 PM, Hans-Christoph Steiner wrote: How about turning off anonymous posting on the bug/patch/feature trackers? The spam rate is increasing, and the anonymous bug reports are either people who forgot to login, or otherwise quite low quality. i don't see a point in doing so. the spam rate is really low. there are 8 spam issues in all 3 trackers, 4 of which have been posted in 2011, and 4 have been posted in 2010. i wouldn't call that excessive. you have deleted for of them, i deleted the rest, so the main work was on my side :-) so please leave the bug tracker open. If the spam was the only issue, then I would be fine with leaving it anonymous. The other issues are perhaps more important, and the spam just serves as a reminder. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme and checkbutton_free, and every single destroy subcommand, I still get a tcl error when sending a bang or float to a [checkbutton] that's in a subpatch with no window mapped: (Tcl) INVALID COMMAND NAME: invalid command name .x252a690.c.widget25272b0 while executing .x252a690.c.widget25272b0 cget -onvalue (uplevel body line 2) invoked from within uplevel #0 $cmd_from_pd Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
On Aug 17, 2011, at 6:23 PM, Jonathan Wilkes wrote: How does your private git branch differ from what's currently in svn? I pushed my git to github, my latest work is in the 'newentry' branch. I basically focused on the [entry] widget to see if I could get it going with this new approach. https://github.com/pd-projects/tkwidgets One thing I'd like to point out is that your tkwidgets suffer from the same problem tot/widget did -- by handling all the widget state in tcl you make it impossible to use your objects inside a subpatch/ abstraction that doesn't have a visible canvas (because the widget no longer exists). I was considering create a master widget as a child of the main window and sync it to the widget drawn on the canvas, but that seems like a lot of trouble. Is there some other workaround? That is true, but tkwidgets are all about using Tk widgets in Pd as easily as possible. If the Tk widget is not drawn to the screen, then the Tk widget is not involved. What is the problem in particular? You want to change its state while its not visible? I think the idea there is to have the state stored in the standard struct as a dump from the Tk widget. So when its not visible, store the state-changes, when it becomes visible, dump the state to the Tk widget. Another thing: to get Pd-style interaction, bind $canvas EditMode to a proc that sets -state to disabled for all tkwidgets in that $canvas when editmode == 1. That way you don't end up triggering the widget when you want to edit it. Yeah, tkwidgets was mostly written about the same time as I starting the pd-gui-rewrite. As I rewrote a lot of pd-gui, I realized I should wait on tkwidgets since I could fix a lot of things in pd-gui first. The EditMode message is one example. tkwdigets is not complete yet, so this is not fully in there. I think the [entry] in github does this kind of stuff. .hc Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 2:54 PM Subject: Re: tkwidgets Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme and checkbutton_free, and every single destroy subcommand, I still get a tcl error when sending a bang or float to a [checkbutton] that's in a subpatch with no window mapped: (Tcl) INVALID COMMAND NAME: invalid command name .x252a690.c.widget25272b0 while executing .x252a690.c.widget25272b0 cget -onvalue (uplevel body line 2) invoked from within uplevel #0 $cmd_from_pd Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tkwidgets
On Aug 17, 2011, at 8:17 PM, Jonathan Wilkes wrote: The problem is for a subpatch that isn't vis'd: [inlet] | [checkbutton] | [outlet] Will give an error on bang because checkbutton_bang has: sys_vgui(%s invoke\n, x-widget_id-s_name); That could be solved by using a -variable option, but then that limits you because the nonzero value cannot be changed.* So yeah, the best solution is stored state in the struct so you can access it in the c functions without caring about the vis state of the obj. Is that the idea behind the options_binbuf? Yeah, options_binbuf is related to dumping/setting the Tk configuration for the widget. Once the resizing, Tk configuration saving, interaction technique, etc. is settled, then we can nail down details like what needs to happen when the Tk widget does not exist but the object receives a message. * also note that checkbutton's default behavior is the opposite from tgl: tgl: zero = off, nonzero = on checkbutton: onvalue = on, everything else = off One of the goals of tkwidgets is to have the Tk widgets represented in Pd as directly as possible. Then the Tk docs apply, for example. And it will hopefully be easier to manage more complicated configurations if there isn't a layer of abstraction between Tk and Pd. If you are interested in working on tkwidgets, that would be great! I think the easiest place to start would be to make a 'label' object based on the Tk label widget. .hc From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 7:24 PM Subject: Re: tkwidgets On Aug 17, 2011, at 6:23 PM, Jonathan Wilkes wrote: How does your private git branch differ from what's currently in svn? I pushed my git to github, my latest work is in the 'newentry' branch. I basically focused on the [entry] widget to see if I could get it going with this new approach. https://github.com/pd-projects/tkwidgets One thing I'd like to point out is that your tkwidgets suffer from the same problem tot/widget did -- by handling all the widget state in tcl you make it impossible to use your objects inside a subpatch/ abstraction that doesn't have a visible canvas (because the widget no longer exists). I was considering create a master widget as a child of the main window and sync it to the widget drawn on the canvas, but that seems like a lot of trouble. Is there some other workaround? That is true, but tkwidgets are all about using Tk widgets in Pd as easily as possible. If the Tk widget is not drawn to the screen, then the Tk widget is not involved. What is the problem in particular? You want to change its state while its not visible? I think the idea there is to have the state stored in the standard struct as a dump from the Tk widget. So when its not visible, store the state-changes, when it becomes visible, dump the state to the Tk widget. Another thing: to get Pd-style interaction, bind $canvas EditMode to a proc that sets -state to disabled for all tkwidgets in that $canvas when editmode == 1. That way you don't end up triggering the widget when you want to edit it. Yeah, tkwidgets was mostly written about the same time as I starting the pd-gui-rewrite. As I rewrote a lot of pd-gui, I realized I should wait on tkwidgets since I could fix a lot of things in pd-gui first. The EditMode message is one example. tkwdigets is not complete yet, so this is not fully in there. I think the [entry] in github does this kind of stuff. .hc Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-dev List pd-dev@iem.at Sent: Wednesday, August 17, 2011 2:54 PM Subject: Re: tkwidgets Hey Jonathan, I'm cc'ing pd-dev since this is a topic that could interest others and others could contribute to. I've started a private git branch of tkwidgets that I intent to push once I get somewhere with it. The idea is to try out a new idea for how GUI objects can work. Basically, I think I can make it so that Tcl handles more of the interaction with the user, minimizing on pd-gui -- pd communications, and making it easier to write GUI objects. Its not trivial to do, but should be doable. .hc On Aug 17, 2011, at 12:26 PM, Jonathan Wilkes wrote: Never mind, I see it now inside canvas_vis... too bad canvas' window subcommand doesn't have something like pack's -in option... But I guess I could make a toplevel checkbutton widget and just manually clone it. -Jonathan From: Jonathan Wilkes jancs...@yahoo.com To: Hans- Christoph Steiner h...@at.or.at Sent: Wednesday, August 17, 2011 3:14 AM Subject: tkwidgets Hi Hans, Do I have it right that your tkwidgets get destroyed when the containing patch is vis'd 0? If so, any hints on how this happens? Specifically, I'm playing around with [checkbutton], and even if I comment out everything in eraseme
Re: [PD-dev] Pdextended 0.43.1 and vista
I tried these patches a bit but haven't fully tested them yet. But I did just finish updating the MinGW setup, there have been big improvements in the last 2 years since I looked last. The nicest is 'mingw-get' for installing packages :) Here's the documentation on the whole setup, it now includes ffmpeg with many codecs, but gmerlin-avdecoder didn't build. It also includes a pthread DLL that can be linked using only -lpthread like all other platforms (i.e. libpthread-2.dll). I left in -lpthreadGC2 for backwards compatibility: http://puredata.info/docs/developer/WindowsMinGWGet/ .hc On Aug 20, 2011, at 5:06 PM, Patrice Colet wrote: Thank you for answering fast autogen.sh ./configure make works good with all the PD__CHECK, I've been running autoconf instead, so now I can submit the patches to the tracker without breaking anything. notice that the compiled files aren't the same as the ones made by makefile.mingw: $ ls pd/src/.libs/ libpd-0.dll libpd.lai pd.exe pdsend.exe libpd.a lt-pd.c pd_ltshwrapper pdsend_ltshwrapper libpd.dll.a lt-pdreceive.c pdreceive.exe libpd.la lt-pdsend.c pdreceive_ltshwrapper and it needs libpthread-2.dll, so the package script would need some changes. I'll try TortoiseGIT :) - IOhannes m zmölnig zmoel...@iem.at a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2011 08:33 PM, Patrice Colet wrote: hello, I've attached the patches that make working libtools with msys, but there is something I couldn't resolve, all the PD__CHECK shows synthax errors so those lines are under comments, maybe you could help with this? which syntax errors? did you run autogen.shh (or equivalent) to get the macros in m4/ included in your aclocal.m4? the diff is made with files from git repository, could you also suggest an easy git manager, or an url to find some documentation for windows, thank you. i found TortoiseGIT very easy to use (esp. if you are used to TortoiseSVN and the like) please also note, that there is no makefile.am in Pd's tree, there is only Makefile.am: many filesystems are case-sensitive mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5P7XoACgkQkX2Xpv6ydvRqMgCdE0DEwwEjjJMLVyIrOQziKypW Qd8AoNc/mwbgq85LQ2hY7anKFciwqtMT =C1L9 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Status of GUI rewrite?
Hey Stephen, The pd-gui-rewrite effort has been entirely folded into Miller's pure- data.git and is included in the 0.43 release. The dev/PdGuiRewrite page is there for historical interest. You can find out more about one big feature of this effort in the GUI Plugins section of the docs: http://puredata.info/docs/guiplugins The look and feel of Pd is a very personal issue, so now we can customize it a lot using GUI plugins. For example, I think that straight cords are much more readable than bezier curved cords. As for bugs, please do make bug reports, you can get to the bug report form from the Help menu in Pd. .hc On Aug 21, 2011, at 5:02 AM, Stephen Lavelle wrote: Hi - I was just tinkering around with some of the graphics in puredata, before noticing that there's a GUI rewrite project underway ( http://puredata.info/dev/PdGuiRewrite ). Could someone tell me what the status of this is? I've been tinkering around a little in the code myself, https://lh6.googleusercontent.com/-SKz32YaPs3U/TlBQKiAHtyI/Adk/_mjg3TRA-GE/Screen%2BShot%2B2011-08-21%2Bat%2B01.23.36.png but see that some of the things I had in mind to do are on their to- do list, and I may have some other usability suggestions as well. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Status of GUI rewrite?
On Aug 21, 2011, at 1:35 PM, Stephen Lavelle wrote: Oh, hey - Thanks for bringing me up to date : ) The pd-gui-rewrite effort has been entirely folded into Miller's pure-data.git and is included in the 0.43 release. Oh, ok - I hadn't stumbled across the gui plugin setup yet - that's cool : ) The look and feel of Pd is a very personal issue, so now we can customize it a lot using GUI plugins. To some extent it is. The big problem for me is the inlet/outlet size - the precision required isn't something I can comfortably manage on a touchpad. I'm a more than a little overwhelmed with just getting to grips with pure-data and compiling the code - from what I can tell in the source code, the inlet/outlet drawing is totally hard-coded. If someone could tell me whether or not this would be possible to do with the gui plugin system, or if it already exists (based on an earnest search, it does not), I would appreciate it : ) You can increase the font size which will make the boxes bigger. Also, you might like the new inlet/outlet highlighting that's in Pd- extended 0.43 and pd-l2ork. The inlets and outlets are tagged using Tk tags, so you should be able to change their size using the Tk canvas commands 'coords' or 'itemconfigure -width', etc. I've never tried tho. As for bugs, please do make bug reports, you can get to the bug report form from the Help menu in Pd. I'm a little confused - I didn't mention anything about bugs. I consider usability problems bugs. .hc Thanks : ) S For example, I think that straight cords are much more readable than bezier curved cords. As for bugs, please do make bug reports, you can get to the bug report form from the Help menu in Pd. .hc On Aug 21, 2011, at 5:02 AM, Stephen Lavelle wrote: Hi - I was just tinkering around with some of the graphics in puredata, before noticing that there's a GUI rewrite project underway ( http://puredata.info/dev/PdGuiRewrite ). Could someone tell me what the status of this is? I've been tinkering around a little in the code myself, https://lh6.googleusercontent.com/-SKz32YaPs3U/TlBQKiAHtyI/Adk/_mjg3TRA-GE/Screen%2BShot%2B2011-08-21%2Bat%2B01.23.36.png but see that some of the things I had in mind to do are on their to- do list, and I may have some other usability suggestions as well. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Aug 21, 2011, at 10:34 AM, Martin Peach wrote: On 2011-08-20 21:21, Hans-Christoph Steiner wrote: I tried these patches a bit but haven't fully tested them yet. But I did just finish updating the MinGW setup, there have been big improvements in the last 2 years since I looked last. The nicest is 'mingw-get' for installing packages :) Here's the documentation on the whole setup, it now includes ffmpeg with many codecs, but gmerlin-avdecoder didn't build. It also includes a pthread DLL that can be linked using only -lpthread like all other platforms (i.e. libpthread-2.dll). I left in -lpthreadGC2 for backwards compatibility: http://puredata.info/docs/developer/WindowsMinGWGet/ That looks very nice, I need to try it (usually something sticks because I can't find the right version of something, the MinGW people seem to randomly change what's in their packages) but I see you have the lines: svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.41/ cd 0.41/pd/src make -f makefile.mingw Are Windows folks doomed to live in the past or is it possible to build 0.43 with MinGW the same way? Martin I updated the page and put it as the official one. I'm moving into place on the build server now. http://puredata.info/docs/developer/WindowsMinGW Patco has been working on the final bugs that have prevented the new autotools builds system from working on MinGW, that's what this thread is about. It would be great if you could contribute as well, Martin, since you have more Windows knowledge and experience than say, me. But yes, the only pd/src/makefile.mingw should still work on 0.43, but the plan is to make it obsolete so we only have one build system for all platforms. .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Status of GUI rewrite?
On Aug 21, 2011, at 6:55 PM, Stephen Lavelle wrote: You can increase the font size which will make the boxes bigger. Also, you might like the new inlet/outlet highlighting that's in Pd- extended 0.43 and pd-l2ork. The inlets and outlets are tagged using Tk tags, so you should be able to change their size using the Tk canvas commands 'coords' or 'itemconfigure -width', etc. I've never tried tho. Their hitboxes aren't though - canvas_doclick in g_editor.c has hard- coded numbers. Arg, yes, that's true... sigh... but I find the inlet/outlet highlighting helps a lot. .hc As for bugs, please do make bug reports, you can get to the bug report form from the Help menu in Pd. I'm a little confused - I didn't mention anything about bugs. I consider usability problems bugs. :) .hc Thanks : ) S For example, I think that straight cords are much more readable than bezier curved cords. As for bugs, please do make bug reports, you can get to the bug report form from the Help menu in Pd. .hc On Aug 21, 2011, at 5:02 AM, Stephen Lavelle wrote: Hi - I was just tinkering around with some of the graphics in puredata, before noticing that there's a GUI rewrite project underway ( http://puredata.info/dev/PdGuiRewrite ). Could someone tell me what the status of this is? I've been tinkering around a little in the code myself, https://lh6.googleusercontent.com/-SKz32YaPs3U/TlBQKiAHtyI/Adk/_mjg3TRA-GE/Screen%2BShot%2B2011-08-21%2Bat%2B01.23.36.png but see that some of the things I had in mind to do are on their to-do list, and I may have some other usability suggestions as well. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish.-William Carlos Williams [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
Oops, I just noticed one unneeded line in the patch I sent you: +#pd_LINK = $(CXXLINK) There is no need to add a line of code that is comment out :) .hc On Aug 21, 2011, at 10:29 PM, Hans-Christoph Steiner wrote: Hey patco, I boiled down your patch set into this stripped down version, and fixed the error while trying to build pd~ (pd~ doesn't work on Windows). Its best to make sure patches only include the changes that are absolutely necessary, and not any whitespace changes or cosmetic changes. This patch builds and runs for me on MinGW, but I don't really have a good way to test ASIO audio. If you want to submit it as a git patch, here's what you can do in a clean, up-to- date git: cd pure-data git reset --hard (watch out, this wipes changes) patch -p1 mingw.patch git commit configure.ac src/Makefile.am extra/Makefile.am -m a real msg git format-patch -n1 mingw.patch .hc On Aug 20, 2011, at 5:06 PM, Patrice Colet wrote: Thank you for answering fast autogen.sh ./configure make works good with all the PD__CHECK, I've been running autoconf instead, so now I can submit the patches to the tracker without breaking anything. notice that the compiled files aren't the same as the ones made by makefile.mingw: $ ls pd/src/.libs/ libpd-0.dll libpd.lai pd.exe pdsend.exe libpd.a lt-pd.c pd_ltshwrapper pdsend_ltshwrapper libpd.dll.a lt-pdreceive.c pdreceive.exe libpd.la lt-pdsend.c pdreceive_ltshwrapper and it needs libpthread-2.dll, so the package script would need some changes. I'll try TortoiseGIT :) - IOhannes m zmölnig zmoel...@iem.at a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2011 08:33 PM, Patrice Colet wrote: hello, I've attached the patches that make working libtools with msys, but there is something I couldn't resolve, all the PD__CHECK shows synthax errors so those lines are under comments, maybe you could help with this? which syntax errors? did you run autogen.shh (or equivalent) to get the macros in m4/ included in your aclocal.m4? the diff is made with files from git repository, could you also suggest an easy git manager, or an url to find some documentation for windows, thank you. i found TortoiseGIT very easy to use (esp. if you are used to TortoiseSVN and the like) please also note, that there is no makefile.am in Pd's tree, there is only Makefile.am: many filesystems are case-sensitive mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5P7XoACgkQkX2Xpv6ydvRqMgCdE0DEwwEjjJMLVyIrOQziKypW Qd8AoNc/mwbgq85LQ2hY7anKFciwqtMT =C1L9 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Status of GUI rewrite?
On Aug 22, 2011, at 8:50 AM, Stephen Lavelle wrote: You can increase the font size which will make the boxes bigger. Also, you might like the new inlet/outlet highlighting that's in Pd- extended 0.43 and pd-l2ork. The inlets and outlets are tagged using Tk tags, so you should be able to change their size using the Tk canvas commands 'coords' or 'itemconfigure -width', etc. I've never tried tho. Their hitboxes aren't though - canvas_doclick in g_editor.c has hard-coded numbers. Arg, yes, that's true... sigh... but I find the inlet/outlet highlighting helps a lot. If I were to try make a patch, what do you think the appropriate place to expose it? It feels like it would sit well beside the font size options... If you're modifying the C code, then I think the best approach would be to expose the settings in a way that people could change them via Tcl i.e. a GUI plugin. Then people can play around with all sorts of behaviors. Its going to be the kind of thing where it'll be difficult to change the existing behavior because so many people expect it to work like that. So it needs to be something customizable. .hc Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Aug 22, 2011, at 11:54 AM, Patrice Colet wrote: - Hans-Christoph Steiner h...@at.or.at a écrit : Oops, I just noticed one unneeded line in the patch I sent you: +#pd_LINK = $(CXXLINK) There is no need to add a line of code that is comment out :) Hi Hans, I had to add this line for linking asio with G++, I'm trying out right now if asio are ok without it, hope to find it out as soon as possible, my internet connection is actually very very slow. Oops, sorry, yeah, it looks like that line is needed after all. I've looked at you patch, and there is something I didn't figured out before, the git sources you are using aren't pd-extended but pd-anything ^^ It's not specificated anywhere in docs. maybe that's why I couldn't build libdir.dll? For generating patches, I usually work with Miller's pure-data repo. That's essential if its a patch to submit to Miller. .hc .hc On Aug 21, 2011, at 10:29 PM, Hans-Christoph Steiner wrote: Hey patco, I boiled down your patch set into this stripped down version, and fixed the error while trying to build pd~ (pd~ doesn't work on Windows). Its best to make sure patches only include the changes that are absolutely necessary, and not any whitespace changes or cosmetic changes. This patch builds and runs for me on MinGW, but I don't really have a good way to test ASIO audio. If you want to submit it as a git patch, here's what you can do in a clean, up-to- date git: cd pure-data git reset --hard (watch out, this wipes changes) patch -p1 mingw.patch git commit configure.ac src/Makefile.am extra/Makefile.am -m a real msg git format-patch -n1 mingw.patch .hc On Aug 20, 2011, at 5:06 PM, Patrice Colet wrote: Thank you for answering fast autogen.sh ./configure make works good with all the PD__CHECK, I've been running autoconf instead, so now I can submit the patches to the tracker without breaking anything. notice that the compiled files aren't the same as the ones made by makefile.mingw: $ ls pd/src/.libs/ libpd-0.dll libpd.lai pd.exe pdsend.exe libpd.a lt-pd.c pd_ltshwrapper pdsend_ltshwrapper libpd.dll.a lt-pdreceive.c pdreceive.exe libpd.la lt-pdsend.c pdreceive_ltshwrapper and it needs libpthread-2.dll, so the package script would need some changes. I'll try TortoiseGIT :) - IOhannes m zmölnig zmoel...@iem.at a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2011 08:33 PM, Patrice Colet wrote: hello, I've attached the patches that make working libtools with msys, but there is something I couldn't resolve, all the PD__CHECK shows synthax errors so those lines are under comments, maybe you could help with this? which syntax errors? did you run autogen.shh (or equivalent) to get the macros in m4/ included in your aclocal.m4? the diff is made with files from git repository, could you also suggest an easy git manager, or an url to find some documentation for windows, thank you. i found TortoiseGIT very easy to use (esp. if you are used to TortoiseSVN and the like) please also note, that there is no makefile.am in Pd's tree, there is only Makefile.am: many filesystems are case-sensitive mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5P7XoACgkQkX2Xpv6ydvRqMgCdE0DEwwEjjJMLVyIrOQziKypW Qd8AoNc/mwbgq85LQ2hY7anKFciwqtMT =C1L9 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Patrice Colet If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. -- Patrice Colet We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] New Windows/MinGW Build setup
I just finished rebuilding the MinGW/MSYS setup on the Windows build server using the new mingw-get utility and the latest MinGW and MSYS. There has been big improvements in MinGW in the past couple of years, so its getting a lot easier to set everything up. You can do it yourself here: http://puredata.info/docs/developer/WindowsMinGW One big notable change is that this now uses gcc 4.5 rather than gcc 3.4. Also built and installed are: - libdl - -lpthread and -lpthreadGC2 - Tcl/Tk 8.5.10 - freetype 2.4.6 - fftw 3.3 double - fftw 3.3 float - libmad - ogg - vorbis - speex - flac (but doesn't seem to always work) - libsndfile - lua 5.1 - lame (but doesn't seem to always work) - theora - libjpeg - libtiff - libpng - libxvidcore - a52dec - libdca - faac - flite - x264 (untested) - openjpeg (but doesn't seem to always work) - ffmpeg (untested) - libgavl - ladspa.h .hc [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Aug 22, 2011, at 6:20 PM, Patrice Colet wrote: - Hans-Christoph Steiner h...@at.or.at a écrit : Oops, I just noticed one unneeded line in the patch I sent you: +#pd_LINK = $(CXXLINK) There is no need to add a line of code that is comment out :) .hc I've successfully compiled with asio without this line, so you were right, in fact it was just some garbage from everything I've tried, and forgot to test compilation without it. I think we are done :). Yee haw! So do you want to post the proper git format-patch -n1 to the patch report you already posted? Then I'll include it in Pd- extended, and you're name will be in the git history. If you are looking for a new challenge, perhaps you could get gmerlin- avdecoder building on MinGW. Then we'll have readanysf~ for Windows. :) .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
On Aug 22, 2011, at 8:28 PM, Patrice Colet wrote: - Hans-Christoph Steiner h...@at.or.at a écrit : On Aug 22, 2011, at 6:20 PM, Patrice Colet wrote: - Hans-Christoph Steiner h...@at.or.at a écrit : Oops, I just noticed one unneeded line in the patch I sent you: +#pd_LINK = $(CXXLINK) There is no need to add a line of code that is comment out :) .hc I've successfully compiled with asio without this line, so you were right, in fact it was just some garbage from everything I've tried, and forgot to test compilation without it. I think we are done :). Yee haw! So do you want to post the proper git format-patch -n1 to the patch report you already posted? Then I'll include it in Pd- extended, and you're name will be in the git history. Okay, I just have to make sure again that I'm not mistaken, it happens too many times, and I'll send the patch. If you are looking for a new challenge, perhaps you could get gmerlin- avdecoder building on MinGW. Then we'll have readanysf~ for Windows. :) I've already done it ^^ it's in the pd-list archives and here: http://megalego.free.fr/pd/externals/readanysf~-win32-0.42.zip but there is a problem with libiconv, could you give a try with the attached makefile? maybe I didn't compiled properly libgalv, libiconv makes pd crashing on mp3 encoded with lame... MinGW now includes iconv, so that should be easy. I couldn't get gmerlin-avdecoder to build, libgavl is built, as is ffmpeg and a number of codecs. also the external works if we put the DLL's with the external, and I don't know how to make it working with having the DLL's into system32 or pd/bin, maybe some libtools magicks? I think the DLLs should just be included with the external, like we do it on Mac OS X. Basically, you make a readanysf~ folder, and put the readanysf~ DLL and all the others in that folder. .hc I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] X paste fix breaks copy-paste within Pd
Hey Miller, I was just checking out your recent commits. The X-paste fix does indeed fix selection click-pasting, but it breaks regular old copy-pasting with in Pd. For example: 1. make an object box with foo in it 2. select foo and hit Ctrl-C or Edit-Copy 3. create a blank object box 4. hit Ctrl-V or Edit-Paste Nothing gets pasted. The problem lies in the difference between Tcl's clipboard and selection; clipboard is Ctrl-C/Ctrl-V and selection is X-paste. Your commit converted [clipboard get] to [selection get]. I think the solution is to revert the X-paste commit and then add separate logic for [selection get] to get X-pasting working. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] LibraryTemplate on 10.6.8
Hey Louis-Philippe, Pd-extended is built every night on 10.6.8, and there are many libs that are included that are built using the Library Template. You can see the build log from today here, that's single arch: http://autobuild.puredata.info/auto-build/2011-08-24/logs/2011-08-24_10.11.51_darwin_macosx106-x86_64_pd-extended.txt On Wed, 24 Aug 2011 16:13 -0400, Louis-Philippe defa...@spiralix.org wrote: Hi all, has any one already solved the errors the plain LibraryTemplate emits on macosx 10.6.8 w/xcode4? the first one I had: llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin10-llvm-gcc-4.2': execvp: No such file or directory was solved by adding a CC=gcc inside the osx if block in the makefile the other, only seems to happens when compiling for multiple arch (ppc,i386,x86_64): lipo: can't figure out the architecture type of: /var/folders/mC/mCxAOxLoFCuWvYmrR7CGNE+++TI/-Tmp-//cckjQBZR.out as soon as I compile for only one arch the error disapear. When compiling manually, it also works and builds multi-arch. I have seen this error before, but not with the Library Template. I can't remember what triggers it. also, when linking against the pd lib (inside the pd.app) it complains only one arch is present (i386 at the moment). anyone has a Mach-O pd with multi arch recipe? If you mean this: ld: warning: in /Applications/Pd-extended.app/Contents/Resources/bin/pd, file was built for i386 which is not the architecture being linked (x86_64) This warning can be safely ignored. It basically wants to check the linking for each arch, but the symbols are the same for all arches on all Pd libraries that use the Library Template (that I know of, at least), so checking against one arch works fine. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iemlib help patch revisions
On Aug 28, 2011, at 1:23 PM, Jonathan Wilkes wrote: From: IOhannes zmölnig zmoel...@iem.at To: pd-dev@iem.at Sent: Sunday, August 28, 2011 8:15 AM Subject: Re: [PD-dev] iemlib help patch revisions On 08/28/2011 12:31 AM, Jonathan Wilkes wrote: Hi, I have revised the iemlib help patches to include the [pd META] subpatch. Who do I give them to to commit? Or do I just do it myself? please do not commit yourself. instead, please send the revised patches to thomas musil. I sent themto him over a month ago at: mu...@iem.at Is that the correct email address? I think your best bet is to add it to the patch tracker, assign it to Thomas Musil, and then email him. .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Xcode 4: Debug pd-external
I don't use Xcode, so I don't know specifics. My guess is that you have to also add 'pd' itself. Pd is two processes 'pd-gui' and 'pd'. On Mac OS X, the 'pd-gui' process is represented by Pd-extended.app (in Contents/MacOS/Pd-extended). You probably need to also add 'pd', which is Pd-extended.app/Contents/Resources/bin/pd What ever you figure out, it would be great if you could add a Debugging section to this wiki page: http://puredata.info/docs/developer/PdExternalsInXcode .hc On Tue, 2011-08-30 at 15:20 +0200, Patrick Gampp wrote: Hi, I tried to debug my puredata external with Xcode4. What I did so far is: 1) In the 'edit scheme'-menu, I added in the 'Executable'-list: Pd-extended.app. 2) Build configuration is Debug 3) Debugger is GDB. 4) I set some breakpoints in my source file. When I hit Run, pd starts and I open my patch, where the external is, which I want to debug. The patch runs, but Xcode does not stop at the given breakpoints. Do you know what I am doing wrong here? Thanks, Patrick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Xcode 4: Debug pd-external
With 0.42.5, most of the command line flags were fixed in Pd-extended, in 0.43 its definitely fixed. .hc On Tue, 2011-08-30 at 22:53 +0200, Thomas Grill wrote: Hi, i haven't used Xcode4 yet. For older versions i don't define the application bundle as executable, but rather the unix program, which is in e.g. /Applications/Pd-0.43-0.app/Contents/Resources/bin/pd My experience is that pd-extended won't take any command-line parameters (which is very useful for debugging), as opposed to pd-vanilla. gr~~~ Am 30.08.2011 um 15:20 schrieb Patrick Gampp: Hi, I tried to debug my puredata external with Xcode4. What I did so far is: 1) In the 'edit scheme'-menu, I added in the 'Executable'-list: Pd-extended.app. 2) Build configuration is Debug 3) Debugger is GDB. 4) I set some breakpoints in my source file. When I hit Run, pd starts and I open my patch, where the external is, which I want to debug. The patch runs, but Xcode does not stop at the given breakpoints. Do you know what I am doing wrong here? Thanks, Patrick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev -- Thomas Grill http://g.org +43 699 19715543 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-extended 0.43 release push
I was thinking that now would be a good time to start a release cycle for Pd-extended 0.43. There is a ton of really useful new stuff in the editor with the new gui, plugins, etc. So I'm thinking I'll delay some of the library work I've been doing, and revert to the 0.42.5 behavior of loading a bunch of libraries by default at startup. But I personally be dropping my support for a number of included libraries, but anyone is welcome to pick them up if they want to see them stay in Pd-extended. You can see the state of things here: http://puredata.info/docs/LibrariesInPdExtended This can be a trial run of the new process of keeping things in Pd-extended. Basically, I need to reduce my maintenance load, I just can't keep up any more. So I am proposing that the new process for getting things into a Pd-extended release. First, the new release branch will be a copy of the previous release branch. Each library/doc has a maintainer, listed on the LibrariesInPdExtended page. It is that maintainer's job to update their libraries/docs into the pd-extended release branch, otherwise the version will be the same as the previous version. Each version of a library included in Pd-extended needs to a fully released version with a proper version number and a release posted on its own page in the http://puredata.info/downloads section, and ultimately uploaded to Debian/testing (I'm happy to sponsor people's packages for upload to Debian once they are ready). The full process is documented here: http://puredata.info/docs/developer/GettingIntoPdextended Comments, feedback, concerns? I'd like to make this a much more open and participatory process. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended 0.43 release push
The nightly builds are on a separate server: http://autobuild.puredata.info/auto-build/ .hc On Tue, 2011-09-13 at 16:54 +, Marc D. Demers wrote: Hi Hans, I will be glad to tried out the new PD-extended version but I've been unable to connect to the PD site for the past three days... The link seems broken... Regards, Marc From: h...@at.or.at To: pd-dev@iem.at Date: Tue, 13 Sep 2011 12:06:45 -0400 Subject: [PD-dev] pd-extended 0.43 release push I was thinking that now would be a good time to start a release cycle for Pd-extended 0.43. There is a ton of really useful new stuff in the editor with the new gui, plugins, etc. So I'm thinking I'll delay some of the library work I've been doing, and revert to the 0.42.5 behavior of loading a bunch of libraries by default at startup. But I personally be dropping my support for a number of included libraries, but anyone is welcome to pick them up if they want to see them stay in Pd-extended. You can see the state of things here: http://puredata.info/docs/LibrariesInPdExtended This can be a trial run of the new process of keeping things in Pd-extended. Basically, I need to reduce my maintenance load, I just can't keep up any more. So I am proposing that the new process for getting things into a Pd-extended release. First, the new release branch will be a copy of the previous release branch. Each library/doc has a maintainer, listed on the LibrariesInPdExtended page. It is that maintainer's job to update their libraries/docs into the pd-extended release branch, otherwise the version will be the same as the previous version. Each version of a library included in Pd-extended needs to a fully released version with a proper version number and a release posted on its own page in the http://puredata.info/downloads section, and ultimately uploaded to Debian/testing (I'm happy to sponsor people's packages for upload to Debian once they are ready). The full process is documented here: http://puredata.info/docs/developer/GettingIntoPdextended Comments, feedback, concerns? I'd like to make this a much more open and participatory process. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-extended 0.43 release push
Hey Joe, This is a great idea that has been talked about in the past every now and then. The big missing piece has always been someone who wants to do the work to implement it. Personally, I've been moving my own Pd packaging work to be based out of Debian. And I've been trying to make a similar process for Pd-extended (see GettingIntoPdextended from the original email) You can see the libraries I maintain because they are (almost) all in Debian: http://qa.debian.org/developer.php?login=h...@eds.org We know have a lot of the pieces in place to make this task a lot easier. For example, the libraries all have *-meta.pd files which contain meta information about the library. Jonathan Wilkes has been doing some great work around the meta data, but the more people working on this stuff, the more that gets done :) .hc On Tue, 2011-09-13 at 17:36 +0100, Joe White wrote: Hey, Forgive me if this is not totally on topic but I had an idea a while ago a wondered what the feasibility of it was. I don't really have a great knowledge of the Pd extended package but how possible would it be to have each library versioned (say on github) as individual repositories that then get pulled in the build. Maybe you could see when certain libraries have been changed and update them on your own machine. Along the idea of how macports works. Again, apologies if this is a really stupid question. Cheers, Joe On 13 September 2011 17:06, Hans-Christoph Steiner h...@at.or.at wrote: I was thinking that now would be a good time to start a release cycle for Pd-extended 0.43. There is a ton of really useful new stuff in the editor with the new gui, plugins, etc. So I'm thinking I'll delay some of the library work I've been doing, and revert to the 0.42.5 behavior of loading a bunch of libraries by default at startup. But I personally be dropping my support for a number of included libraries, but anyone is welcome to pick them up if they want to see them stay in Pd-extended. You can see the state of things here: http://puredata.info/docs/LibrariesInPdExtended This can be a trial run of the new process of keeping things in Pd-extended. Basically, I need to reduce my maintenance load, I just can't keep up any more. So I am proposing that the new process for getting things into a Pd-extended release. First, the new release branch will be a copy of the previous release branch. Each library/doc has a maintainer, listed on the LibrariesInPdExtended page. It is that maintainer's job to update their libraries/docs into the pd-extended release branch, otherwise the version will be the same as the previous version. Each version of a library included in Pd-extended needs to a fully released version with a proper version number and a release posted on its own page in the http://puredata.info/downloads section, and ultimately uploaded to Debian/testing (I'm happy to sponsor people's packages for upload to Debian once they are ready). The full process is documented here: http://puredata.info/docs/developer/GettingIntoPdextended Comments, feedback, concerns? I'd like to make this a much more open and participatory process. .hc ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
