>> 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 excep
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
> 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 compi
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, t
>> 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 `sam
>>> 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,
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 out
> 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 a separate thread, make sure to
hold the global pd lock ...
tim
--
> 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() all
> 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
> >> 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,
> does anyone know where to fine this article?
i read it in the proceedings o
> 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
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 chan
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)
> 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
> 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 th
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
> 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
powerf
On Fri, 2007-09-28 at 04:12 +0200, Yves Degoyon wrote:
>
> yeah, pd was nice when it was free of normalisation and b***
... and people where polite and respecting each other ...
--
[EMAIL PROTECTED]ICQ: 96771783
http://tim.klingt.org
Cheat your landlord if you can and must, but do not
> Ah, ok, I didn't notice the switch. I've originally used the default
> Emacs settings for the indent. Now I think I now use stroustrup,
> because it was the closest to Miller's style that I found.
i generally avoid tabs in my source files with the following
before-save-hook:
(defun clean-co
On Mon, 2007-09-17 at 09:24 -0400, David Merrill wrote:
>
> to find the post online about wiring the clocks together from multiple
> sound cards, google: el cheapo howto
argh ... i'd somehow prefer the software solution :P
t
--
[EMAIL PROTECTED]ICQ: 96771783
http://tim.klingt.org
The pric
actually, i have never done it, but wouldn't you have to link the clocks
of both audio devices in order to avoid timing problems?
wini one told me that one can combine devices with alsa, which includes
some code, that actually synchronizes multiple audio-devices by
software, which includes resampl
i am not really a fan of removing people from a project, but maybe one
could distinguish between 'active' and 'retired' developers ... retired
developers should loose their cvs access, but still kept in the
sourceforge developer lists ...
best, tim
On Mon, 2007-09-10 at 16:42 -0400, Hans-Christo
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 (externals
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.
> 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?
split audio buffers and array-of-atoms? maybe this could include
rewriting the whole audio buffers with an asynchronous interface ...
On Sat, 2007-07-21 at 16:09 -0700, Miller Puckette wrote:
>
> Finally, 0.40 still isn't 64-bit safe; for that you'll need 0.41.
> This
> is a serious problem in some distributions of linux in which many
> libraries
> aren't available in 32-bit form in the 64-bit version of the OS. Just
> as
> a t
> > 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
hi miller,
On Wed, 2007-04-18 at 18:13 -0700, Miller Puckette wrote:
> Well, I measured the difference and didn't see significant speedup (on an
> imac recently)... eventually it might make a difference, of course. But
> certain bit-bashing code (the square root thing, but more importantly
> pha
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
> I probably misunderstood you: I thought, that as soon as the [symbol
> x] object was killed the reason to fire the "anything" outlet of the
> trigger was gone as well, so this outlet should *not* be allowed to
> fire.
if the pd language would have a notion of exceptions, this would make
sense, b
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
> > 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 understa
> Well, then how should Pd solve the logical pitfalls in your opinion?
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'
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.
>
> Ther
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 objec
> 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
http:/
> These flags are used in the standard build:
>
> -Os -funroll-loops -fomit-frame-pointer -mcpu=powerpc -mtune=7450 -
> mpowerpc-gfxopt
the standard build is optimized for size ???
> (fdn~ NOT vectorized; d_soundfile.c, d_ctl.c, m_sched.c vectorized)
have the _whole_ files been vectorized
On Wed, 2006-12-06 at 12:24 -0500, Mathieu Bouchard wrote:
> On Wed, 6 Dec 2006, Tim Blechmann wrote:
>
> > please note, that sndfiler is basically not clickfree, because it
> > requires resorting of the dsp chain, which is not trivial, if your patch
> > contains quite
> > Basically, I have two buffers with some sound in buffer #1. I'm planning
> > at some time in the future to start playing from buffer #2. I copy the
> > contents of buffer #1 to buffer #2 and then do all kinds of evil DSP to
> > the contents of buffer #2, all done asynchronously from the mai
> > after having a brief look at the hidio sources, you seem to use a
> > mutex
> > for synchronization with a child thread ... this is basically not save
> > and may lead to audio dropouts, when running with low latencies. i
> > know,
> > miller's portaudio implementation is not able to run un
hi hans,
> [comport] and [hid] both use the standard calls and both do not use
> threads at all, yet neither has problems with blocking I/O (or at
> least no one has been able to make a patch that causes it to
> happen). I am pretty sure they both use high priority queues in the
> kernel
On Mon, 2006-12-04 at 14:53 -0500, Hans-Christoph Steiner wrote:
>
> > I have no idea about the inner workings of hidio (is there a
> > separate low-priority thread for handling the HID requests?)
>
> This was bugging me so I have to respond to it. From what I've
> seen,
> I think handling H
On Mon, 2006-12-04 at 09:30 -0500, Hans-Christoph Steiner wrote:
> We are in the middle of trying to make [hidio] as robust as possible
> in terms of plugging and unplugging devices. One thing I noticed is
> that if I have Pd running only a sine wave, then I plug or unplug a
> USB device, I
> The other thing is that i guess it has to be straight C for Miller
> to
> accept it,
yes, possibly ...
> plus, older gcc versions have problems with intrinsics in c
> ++ code.
well, older gcc versions have problem with intrinsics in general. ;)
as for the license, it could be optional li
hi thomas,
> Once i started the new devel branch, i'll try to provide patches of
> the various extra features, which would save you from brwosing
> through the codebase. I'm wondering if we can find a way to even
> include SIMD, since i'm going to reimplement it without using
> assembly b
between pd
and pnpd, you are free to read my design docs or my dev blog or post
questions of the mailinglist.
i think, we can stop the flamewar, now
On Thu, 2006-11-30 at 11:10 -0500, Mathieu Bouchard wrote:
> On Thu, 30 Nov 2006, Tim Blechmann wrote:
>
> >>> one thing, t
> > 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 sit
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 desir
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, if
On Wed, 2006-11-29 at 11:09 -0500, Hans-Christoph Steiner wrote:
> Since Matju has stated that desire is a fork, I think it would be
> most beneficial to all of us, including the desire people, if it used
> its own repository.
do you want to restrict their access to the pd cvs? what would be
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
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 mean
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 m
On Sat, 2006-11-18 at 23:00 -0500, Hans-Christoph Steiner wrote:
> On Nov 18, 2006, at 8:07 PM, Thomas Grill wrote:
>
> >
> > Am 18.11.2006 um 22:16 schrieb Mathieu Bouchard:
> >
> >> On Sat, 18 Nov 2006, Hans-Christoph Steiner wrote:
> >>
> >>> I really doubt that the gcc devs put a lot of effort
> 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 no
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
> >>
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:
http
several ways to debug pd externals with gdb:
- crash the external (with asserts)
- declare pending breakpoint, that are resolved after the shared library
has been loaded
- set breakpoint after the dlopen stuff, when the symbols are available
- break manually after the external has been loaded and
On Sun, 2006-11-12 at 10:01 -0500, Hans-Christoph Steiner wrote:
> Hmm, never seen that. I just got the "pd" process. Which platform
> are you on?
did you ever have a look at m_pd.h?
> .hc
>
> On Nov 11, 2006, at 8:04 PM, Conor J Curran wrote:
>
> > Hi,
> > Tonight I was trying to hook up G
> >> 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
> >>
hi hans ...
> Also, since Pd is free software, it makes sense that it should be
> buildable with free software. Right now, Windows and ASIO are the
> the only non-free parts.
is coreaudio free?
> A ReactOS build would fix that.
concerning the wikipedia page of reactos (their website is c
> i have changed that before the autobuild-logs started.
> you can now turn off digest mode if you want to.
wonderful!
> >
> > i see two possibilities:
> > - switch off the forced digest mode for pd-cvs to make it possible to
> > automatically delete pd-extended mails
> > - send pd extended mai
hi hans, hi rest,
would it be possible to forward the pd extended autobuild notification
mails to another list than pd-cvs?
- i'm interested in the commit messages, not in the autobuild error
messages
- it's not possible to switch off digest mode for the pd-cvs list and
thus, i'm not able to filt
> Loading from a file shouldn't be too hard, the file could be loaded
> into memory, reordered as necessary, then executed. The hard part
> would be when inserting an [import] statement into a patch, if that
> is going to take effect immediately and reload objects based on that
> [import].
On Wed, 2006-09-27 at 12:00 +0200, IOhannes m zmoelnig wrote:
> Tim Blechmann wrote:
>
> > what makes you think, that this is similar in text-based languages?
>
> i think "script" language here did not mean "text-based" language
> (ignoring the etymol
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 im
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 "us
> 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
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.
wel
On Sun, 2006-08-13 at 21:29 -0400, Hans-Christoph Steiner wrote:
>
> Just an FYI: I set up the Debian/etch (testing) box to use gcc 4.1.
> Both pd-MAIN and Pd-extended are compiling fine with gcc 4.1. It
> would be nice to try some of the auto-vectorization features. Has
> anyone messed w
> > i am all for it, but: does sourceforge already implement some kind of
> > acl for svn? or can we live without acl's?
>
> According to the Site Docs, "no means is provided to limit access to a
> repository on a per-path basis" for Subversion. This seems to be
> planned, but as we know Sourcefor
72 matches
Mail list logo
