pd devel_0_39 did also set the DAZ/FTZ flags, which affect
the denormal
handling on the sse unit, but that was never merged into
vanilla pd
I see there's a new pd_devel branch. I should check it out.
i doubt, that the new pd_devel branch shares anything with the old
pd_devel except for the
On 08/15/2009 11:42 PM, Ed Kelly wrote:
Once again, I personally would like to have this implemented in the PD core,
since denormals are a real pain in the ass and often cause CPU pegging. This
limits the real-time uses of PD, since there are some performance patches
that are realizable but
hi all,
attached you find a series of two patches against the pd-extended branch
to compile pd extended on the x86_64 architecture:
0001-pd-extended-build-fix-for-x86_64.patch:
passes -fPIC to the cyclone build system
0002-iem_tab-x86_64-fixes.patch
compile fixes for the iem_tag library
best,
Thanks for the patches. But they don't seem to be attached. The best
thing to do would be to post them to the patch tracker as separate
items, since they are patches for different people's code.
i submitted my patches to the tracker ... the 0.41 part of the
pd-extended branch now
not really ... [delay 0] will schedule the outlet during the next dsp
tick in the pd thread ...
i'm pretty sure that this is _not_ true.
a [delay 0] will schedule the message within the same tick.
rescheduling a timer interrupt from a second thread, there is no such
thing as the `same
Mathieu Bouchard wrote:
On Wed, 18 Mar 2009, Tim Blechmann wrote:
The problem is that I've approached all the gphoto calling functions the
same, but one particular function (listconfig) segfaults when I use PD
functions, in particular outlet_symbol().
when calling pd's api functions from
Afaik, this will do the rough equivalent of a [delay 0] across threads, so
that your (Ben's) thread's execution is inserted between two t_clock
events ([delay], [metro], etc.)
not really ... [delay 0] will schedule the outlet during the next dsp
tick in the pd thread ...
uh, i haven't read
I was just merging 0.41 vanilla into pd-extended 0.40 and noticed
something worthwhile to point out. It seems there isn't a patch
submitted for this, but it is quite simple. Basically, in s_inter.c,
'seteuid()' is used to lose setuid privileges. As far as I understand
it, seteuid() allows
As for implementing substantial changes to soundfiler, I think the way
to do it is not to try to get the modifications into Pd-vanilla, there
are so many issues of backwards compatibility. Instead make a new
object, even if it is largely just a modified version of the original.
[sndfiler] is
hi damien,
i would like to
implement multithreaded [soundfiler] read,
did you have a look at my sndfile external? a threaded soundfiler has to
face two issues:
- read the file in a separate thread
- synchronize the buffers
while the first issue is trivial, the second one requires some
So, i'd like to know it i'm to much optimistic, or if work on thread
with pd will be obsolet when pd 0.42 will be out.
i didn't check the sources, but from the description in miller's icmc
paper, pd~ introduces a pipelined approach, i.e. adding one block of
latency when audio data is passed
On Mon, 2007-12-10 at 17:59 +0100, Frank Barknecht wrote:
And why does gcc not complain on native Linux using practically
the same command line?
iirc, the windos binary of pd uses a dll, exposing the public api, while
on linux, all symbols are exposed by the pd binary
(-Wl,--export-dynamic)
t
The hard thing for me with patches is that I feel
I should understand the patch fully and believe it both works and that
it won't make future trouble. For the last month or more I've been
working on HC's font patch, trying to adapt it so that it's bug-free
but still accomplishes HC's aim.
I don't know much about git, but what I have read this would defenitely
be an option.
Then also synching developer and millers version should be easier if I
understood that correctly ?
What do the others think ?
i recently started using git for nova, it is really an extremely
powerful
On Tue, 2007-10-23 at 11:56 -0400, Hans-Christoph Steiner wrote:
A distributed repository sounds interesting, but given Linus
Torvald's love of KDE, constant dissing of usability, and the fact
that git has 119 commands, this gives me pause.
in order to evaluate git, one should maybe give
My experience is that Linus is
super focused on issues that affect him and pretty much totally
ignores other issues that don't affect him. Also, he approaches
things with arrogance. So chances are, that effects the software he
writes.
i am not sure whether one should judge the
On Tue, 2007-08-28 at 11:40 -0700, Ken Restivo wrote:
In particular, I'd like metro object to be synced with JACK.
i have once written an external that is running as jack transport
client, because i needed to sync pd and ardour for a composition ...
it's available from the sf cvs
On Tue, 2007-07-24 at 11:08 -0700, Miller Puckette wrote:
On Mon, Jul 23, 2007 at 12:20:33PM +0200, Tim Blechmann wrote:
Now for the hard part: in Pd, 32-bit floating point tables are stored as
64-but 'atoms' for a 50% hit in memory efficiency. Something Must Be
Done;
but what
i did some benchmarks of pd's phasor~ code against a straight-forward
implementation on my pentium-m, when implementing the objects for
nova.
the straight-forward implementation ran about 20 to 30 % faster
than the
pd-style implementation.
Do you still have the code from the
On Thu, 2007-02-15 at 13:55 +0100, Georg Holzmann wrote:
Of course we would loose the possibility that everyone can quickly
fix
a bug everywhere, but then, I don't see this as such a big problem.
There still would be trusted core developers with access to almost
everything - or maybe we
On Sun, 2007-02-11 at 12:42 +0100, Frank Barknecht wrote:
What the patch is doing is deleting an object. The message causing
the
deletion was triggered by (a message that was triggered by[...])
that
object, so what?
There's nothing semantically incorrect in doing that.
There is. You
mark the object as deletable, if the messaging is happening, wait
for
the object to return from the message function, then it can be
safely
deleted.
implementing it shouldn't be difficult as it is completely
compatible
with pd's synchronous architecture.
If I understand it right,
On Sun, 2007-02-11 at 23:27 +0100, Frank Barknecht wrote:
Hallo,
Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i'm not splitting the logical step, i just change the interpreter state
in a totally predictable way.
I don't know Pd's internals nearly as good as you, but still it seems
On Mon, 2006-12-18 at 12:46 -0500, Mathieu Bouchard wrote:
of course the only real way to vote for this would be write the
code -
i think i'll wait for PNPD instead.. :)
pnpd is currently supporting both hashed symbols and full-featured
string ;) however, there are no objects for
of course the only real way to vote for this would be write the code -
i think i'll wait for PNPD instead.. :)
pnpd is currently supporting both hashed symbols and full-featured
string ;)
however, there are no objects for handling strings, yet
t
--
[EMAIL PROTECTED]ICQ: 96771783
On Thu, 2006-11-30 at 03:39 +, Mathieu Bouchard wrote:
Update of /cvsroot/pure-data/pd
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20618
Removed Files:
Tag: devel_0_39
SConstruct
Log Message:
bye.
--- SConstruct DELETED ---
was SConstruct a desire-related
one thing, that you people need to realize: open source software
development doesn't work, if you don't care, what other people are
doing.
Why did you start pnpd?
as you might now, the pnpd core and the pd core follow different design
concepts.
and how i see the current situation no
On Wed, 2006-11-29 at 17:24 +0100, IOhannes m zmölnig wrote:
Tim Blechmann wrote:
On Tue, 2006-11-28 at 12:31 +0100, Thomas Grill wrote:
Hi all,
would it be possible to exclude the autobuild results from this
digest, like e.g. by making a separate mailing for that.
It's has become
wonderful ...
matju/chun on desire, thomas on devel, miller on vanilla, me on pnpd ...
that makes 5 devs for 3 branches and one rewrite ... what a wonderful
waste of resources ...
no please cool down ... one thing, that you people need to realize: open
source software development doesn't work,
On Tue, 2006-11-28 at 12:31 +0100, Thomas Grill wrote:
Hi all,
would it be possible to exclude the autobuild results from this
digest, like e.g. by making a separate mailing for that.
It's has become absolutely impossible to track the cvs changes.
it's possible to switch off the digest mode
On Tue, 2006-11-28 at 09:42 -0500, Hans-Christoph Steiner wrote:
My the same measure, I find it difficult to track changes when the
CVS checkins from the forks are also included. But I am not
suggesting they be removed from the list because I am willing to
tolerate that if it means
I really doubt that the gcc devs put a lot of effort into something
that has no effect. Perhaps not for Pd, that may be true. But they
are talking about vectorizing loops, it may not be the best thing to
vectorize, but there are definitely vectorizable loops in Pd.
the problem is not
On Thu, 2006-11-16 at 16:28 -0500, Hans-Christoph Steiner wrote:
Debian/testing now uses gcc 4.1 as its default compiler. I just
noticed when doing the apt-get upgrades. Has anyone tried the auto-
vectorization stuff? Is it worthwhile with Pd?
you might want to check the archives:
On Fri, 2006-11-17 at 09:10 -0500, Hans-Christoph Steiner wrote:
On Nov 17, 2006, at 7:01 AM, Tim Blechmann wrote:
On Thu, 2006-11-16 at 16:28 -0500, Hans-Christoph Steiner wrote:
Debian/testing now uses gcc 4.1 as its default compiler. I just
noticed when doing the apt-get upgrades
Incidentally, I also think this highlights the need for a poll of the
Pd list at some point so we can get some idea of what users are using
what externals, abstraction sets, libraries, etc. I would love to see
the numbers, and it would probably be useful for Miller to see
what is
On Wed, 2006-09-27 at 03:05 -0400, Mathieu Bouchard wrote:
On Tue, 26 Sep 2006, Tim Blechmann wrote:
On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote:
IMO this step should wait until we have the equivalent to Python's
from pdcore import * or C++'s using namespace std
sorry
On Tue, 2006-09-26 at 23:21 +0200, Frank Barknecht wrote:
I should add, the next key step is to remove as many classes as
possible from the root namespace (i.e. compiled into Pd).
IMO this step should wait until we have the equivalent to Python's
from pdcore import * or C++'s using
hi vincent ...
That implies a primary work on architecture and a cooperation of all
devs (commit often, criticize, propose, improve, test, submit
patches, ...).
I'll develop on architecture on other posts soon, but I want to first
focus on making the best out of what we have today.
well,
1. Does communication imply collaboration?
does collaboration work without communication?
2. Does collaboration imply everybody on the same branch?
a-b = ¬b-¬a
the diff between devel and vanilla are several thousand lines of code
... and still increasing, mainly because of the
39 matches
Mail list logo
