Pd-dev November 2007

pd-dev@lists.iem.at

27 participants
161 discussions

Shell and long-term instability
by B. Bogart 21 Dec '07

21 Dec '07

Hey all, I realized that [shell] seems to be doing some strange things, once I have removed it from my PD the patch runs much better now. I realized this due to a very high chance that a crash would happen just after a shell command is issued. Has anyone else seen this? I would not cause it a crash per-se, but I can say that oprofile says that no-vmlinux is using 97% CPU, and both PD and X are stalled. I don't have time to investigate further now, but I'm wondering if other people have seen stability issues with shell on linux for long-term installations? Thanks all. FYI I'm back to my 480000 item message... things going ok so far... ;) .b.

4 3

compile pd with cygwin
by Patrice Colet 17 Dec '07

17 Dec '07

I've found some hints in here: http://lists.puredata.info/pipermail/pd-cvs/2004-10/001658.html and it resolves many problems (Thanks to Thomas Grill), why those modifications have been removed? I've built many modules but compilation has stopped with an error on s_midi.c, there are indefined references to "sys_putmidibyte" and other stuff from s_stuff.h, why s_stuff.h isn't included? Here is the begining of s_midi.c I've modified: #include "m_pd.h" #include "s_stuff.h" #include "m_imp.h" #if defined(UNISTD) || defined (_CYGWIN_) #include <unistd.h> #include <sys/time.h> #ifdef HAVE_BSTRING_H #include <bstring.h> #endif #endif #ifdef MSW #include <winsock.h> #include <sys/types.h> #include <sys/timeb.h> #include <wtypes.h> #endif #include <string.h> #include <stdio.h> #include <signal.h> ----snip---- and here is the begining of the successfully compiled s_file.c I've also modified: #include "m_pd.h" #include "s_stuff.h" #include <string.h> #include <stdlib.h> #include <stdio.h> #include <errno.h> #if defined(UNIX) || defined(__CYGWIN__) #include <sys/types.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #endif #ifdef MSW #include <windows.h> #include <tchar.h> #endif int sys_defeatrt; t_symbol *sys_flags = &s_; void sys_doflags( void); #if defined(UNIX) || defined(__CYGWIN__) static char *sys_prefbuf; ---snip--- Thanks for any hint.

5 41

SQLite for PD v0.0
by Mike McGonagle 04 Dec '07

04 Dec '07

Hello all, Ok, I got some preliminary things to test. As far as I can tell, everything works using the message input method. There are still some issues to resolve for the 'text' widget entry method. As it still contains the Amagamated version of SQLite, the archive that I have is about 800K. I posted the stuff on an FTP server. The login info is... User: fsr Password: puredata There is a darwin external for PPC in the archive. You don't need to have a database, as the test program will allow you to create one, and add a table, and some data. Mike -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician

2 8

request for access to cvs as pd developer
by Rich E 01 Dec '07

01 Dec '07

lets see if i can ask correctly this time... I'd like to be added as a pd developer so I can commit externals and patches I have been using. These mainly include: - [sdiflists] - an external for reading sdif files - [SDIF-1TRC] - a patch for buffering SDIF 1TRC files (sinusoidal tracks, usually retreived from Spear or Loris) in Pd's data structures, as well as a rough way to visualize the data. - [oscbank~] - an external for synthesizing sinusoidal tracks using an oscillator bank. The use of sinusoidal models has produces some amazing sounds for me, it would be great to see if others can find useful ways of manipulating the data (I also have some patches that manipulate short SDIF files, which I call 'Trax', that are still quite buggy, but can produce amazing sounds that are very realistic). I would also like to help Hans with the organization of Pd-extended; hence the discussion on getting the dollar sign patch into pd-extended auto-builds. About my history with Pd, I was introduced to it while at UCSD in the music department. I took several classes in developing audio plug-ins, which started with pd externals. I soon began using pd for live performances because, as everyone here knows, it gives you great freedom when manipulating sound. I've spent the last 4 years or so learning to operate linux, program in C/C++/pd, and using these systems to create electronic music (the last part seems to get the least amount of attention so far). regards, rich

2 3

Re: [PD-dev] [PD] hex loader
by IOhannes m zmoelnig 30 Nov '07

30 Nov '07

Mathieu Bouchard wrote: > On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote: > >> i don't like matju's suggestion to provide an API, > > Ideally, hexloader should be merged into the core and the API would be a > single function shared by the loader and the parts of the internals that > do the same thing as the hexloader does (the symbol mangler). yes and no. the hexloader is a bit less strict when it comes to filename mangling (as certain characters are allowed in filenames but not in c-functionnames); one yould of course use the strictest character set, but i think it adds to readability (in your console (or file-browser, if you insist); not in the patch) to use a larger set of characters if possible. > > I'm not really advocating that an external exposes an API otherwise than > as pd objects and methods... but then, this is also what Gem need to do > if some externals are not linked directly into Gem... so it must not be > that ugly. GridFlow will also have to do it eventually. I just think > that doing it for one function is a waste. ok, so we are have the same idea here. i have no problem with a "Gem external" (or "GF external" or whatever) to depend on another external (Gem, or GF, or whatever), because that's what they are: extensions to a certain external and not extensions to Pd. i think most of the loaders aim to be extensions to Pd rather than extensions of the hexloader. but anyhow, i think we agree. > Anyway, because virtually the same code is already in the core, it makes > sense to have that shared function in the core, so the issue of linking > to an external should be moot. > >> as this would require to have hexloader be loaded before all other >> externals that rely on that API. > > Not if the linker knows about it. (The problem is how to tell the linker > about it) well yes; but _i_ don't know how to tell the linker about it :-) > >> what might be a better solution is to tell Pd to try to load a >> different class instead (kind of recursively calling the loading stuff). > > I don't understand. very simple, let's have an example: let's assume we have a pdlua-class ">~" within a file "0x3e0x7e.lua" the loaders loaded are: odlua, hexloader A. (this is how it is happening now) pd is told to create [>~] which it doesn't know about yet. it calls sys_load_lib(c, ">~") which it turn calls all the loader: 1. it runs sys_do_loadlib, which tries to load the external ">~.l_i386", and fails. 2. it runs pdlua, which tries to load ">~.pdlua" and fails. 3. it runs hexloader, which tries to load "0x3e0x7e.l_i386" and "0x3e0x7e.pd", and fails B: this is how i think it might work. pd is told to create [>~] which it doesn't know about yet. it calls sys_load_lib(c, ">~") which it turn calls all the loader: 1. it runs sys_do_loadlib, which tries to load the external ">~.l_i386", and fails. 2. it runs pdlua, which tries to fin ">~.pdlua" and fails. 3. it runs hexloader, which tries to load "0x3e0x7e.l_i386" and "0x3e0x7e.pd", and fails 4. hexloader now calls sys_load_lib(c, "0x3e0x7e") 4.1. it runs sys_do_loadlib, which tries to load the external "0x3e0x7e.l_i386", and fails. 4.2. it runs pdlua, which tries to load "0x3e0x7e.pdlua" and succeeds. btw, all this slows down loading of abstractions considerably. fgmasdr. IOhannes

2 1

cygwin build (was:Re: [PD] pdlua compiling on mac)
by Patrice Colet 30 Nov '07

30 Nov '07

Hans-Christoph Steiner a Ã©crit : > > If you want to build Pd and externals with Cygwin, you'll have to add > some stuff to the build system. No one has done it before. Pd-extended > is built with MinGW/msys on Windows. I've built pd and some externals with mingw, it needs makefile.mingw for pd, but it would be nice if the main makefile would do the job... Anyway, I'm more interested about using cygwin for some reasons, it's easy to install it and all dependances, and we can use Qt/X11 inside.... > On Nov 28, 2007, at 7:20 PM, Patrice Colet wrote: >> makefile.dependencies >> d_osc.c:39:2: #error No byte order defined >> d_array.c:527:2: #error No byte order defined >> make: *** [makefile.dependencies] Erreur 1 I've just added #include <sys/param.h> into d-osc.c and d_array.c to resolve this because this is where BYTE_ORDER is defined. Now I get another error, API_DEFSTRING from s_main.c:359 isn't declared, I could find out how to resolve this and juste removed the variable to go further... and got another error: statbuf isn't declared as well. It seems that the build system misses something like "#ifdef CYGWIN" somewhere, but I couldn't figure out what to do with it.

2 1

[ pure-data-Bugs-1830767 ] Slide bars don't update automatically
by SourceForge.net 30 Nov '07

30 Nov '07

Bugs item #1830767, was opened at 2007-11-12 19:09 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1830767&group_… 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: pd-extended Group: v0.40.2 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: João Miguel Pais (jmmmp) Assigned to: Nobody/Anonymous (nobody) Summary: Slide bars don't update automatically Initial Comment: If you copy some object let's say on the lower right corner of a window and paste it on a fresh window - or any window small enough for the copied object to be outside of it - the newly pasted object will be outside the area being viewed. Before the sliders would appear automatically, but now they only come up if the window gets resized (or something?) Joao ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-11-30 13:13 Message: Logged In: YES user_id=27104 Originator: NO This bug is fixed by these patches (1551825, 1833178), so I am closing this bug. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-11-13 02:28 Message: Logged In: YES user_id=27104 Originator: NO this is caused by patch #1551825 ---------------------------------------------------------------------- Comment By: João Miguel Pais (jmmmp) Date: 2007-11-12 19:12 Message: Logged In: YES user_id=1523458 Originator: YES by the way, on XP with pd-ext .39.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1830767&group_…

1 0

[ pure-data-Bugs-1841758 ] setitimer invalid timeval
by SourceForge.net 30 Nov '07

30 Nov '07

Bugs item #1841758, was opened at 2007-11-30 14:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1841758&group_… 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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: setitimer invalid timeval Initial Comment: Pd's scheduler seems to have a bug regarding setitimer, which leads to messages in the system log: setitimer: pd (pid = 3401) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000 (with a clock delaytime of 1000ms) man setitimer says: ----8<---- POSIX.1-2001 says that setitimer() should fail if a tv_usec value is specified that is outside of the range 0 to 999999. However, Linux does not give an error, but instead silently adjusts the corresponding seconds value for the timer. In the future (scheduled for March 2007), this non-conformance will be repaired: existing applications should be fixed now to ensure that they supply a properly formed tv_usec value. ----8<---- This is with pd-0.40-3 from Miller's site, on GNU/Linux Debian Etch, but I've noticed this issue on various other Linux distros. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1841758&group_…

1 0

[ pure-data-Patches-1841002 ] Add format string error checking, and fix related errors
by SourceForge.net 30 Nov '07

30 Nov '07

Patches item #1841002, was opened at 2007-11-29 08:11 Message generated for change (Comment added) made by russellbryant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_… 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: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) Assigned to: Miller Puckette (millerpuckette) Summary: Add format string error checking, and fix related errors Initial Comment: This patch adds format string error checking for bug(), error(), verbose(), and pd_error(). It also fixes the errors in the pd core that were pointed out by this change. There are some other functions that take printf style format strings that would benefit from this same change, but I wanted to address pieces of it at a time. ---------------------------------------------------------------------- >Comment By: Russell Bryant (russellbryant) Date: 2007-11-30 07:33 Message: Logged In: YES user_id=1942915 Originator: YES File Added: format_string.patch2.txt ---------------------------------------------------------------------- Comment By: Russell Bryant (russellbryant) Date: 2007-11-30 07:32 Message: Logged In: YES user_id=1942915 Originator: YES I assume you meant seems "not" very likely to do any harm. :) Good point about MSVC. I am used to only caring about gcc. I have provided an updated patch that only uses the attribute if GNUC is in use. It is also implemented as a macro in one spot so that addressing it for other compilers in the future can be done in one spot. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-11-29 12:15 Message: Logged In: YES user_id=27104 Originator: NO Looks like the right thing to do, and seems very likely to do any harm. I'm going to try it in Pd-extended. The only concern I can think of is whether the __attribute__ stuff causes any problems when building with MSVC, since some people still build Pd with MSVC. This site seems to claim it does not: http://ocliteracy.com/techtips/gnu-c-attributes.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_…

1 0

[ pure-data-Patches-1841002 ] Add format string error checking, and fix related errors
by SourceForge.net 30 Nov '07

30 Nov '07

Patches item #1841002, was opened at 2007-11-29 08:11 Message generated for change (Comment added) made by russellbryant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_… 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: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) Assigned to: Miller Puckette (millerpuckette) Summary: Add format string error checking, and fix related errors Initial Comment: This patch adds format string error checking for bug(), error(), verbose(), and pd_error(). It also fixes the errors in the pd core that were pointed out by this change. There are some other functions that take printf style format strings that would benefit from this same change, but I wanted to address pieces of it at a time. ---------------------------------------------------------------------- >Comment By: Russell Bryant (russellbryant) Date: 2007-11-30 07:32 Message: Logged In: YES user_id=1942915 Originator: YES I assume you meant seems "not" very likely to do any harm. :) Good point about MSVC. I am used to only caring about gcc. I have provided an updated patch that only uses the attribute if GNUC is in use. It is also implemented as a macro in one spot so that addressing it for other compilers in the future can be done in one spot. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-11-29 12:15 Message: Logged In: YES user_id=27104 Originator: NO Looks like the right thing to do, and seems very likely to do any harm. I'm going to try it in Pd-extended. The only concern I can think of is whether the __attribute__ stuff causes any problems when building with MSVC, since some people still build Pd with MSVC. This site seems to claim it does not: http://ocliteracy.com/techtips/gnu-c-attributes.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev November 2007