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 …
[View More]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.
[View Less]
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.…
[View More]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.
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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
…
[View More]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_…
[View Less]
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
…
[View More]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_…
[View Less]
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
…
[View More]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_…
[View Less]
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
…
[View More]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_…
[View Less]