Bugs item #3489547, was opened at 2012-02-20 03:00
Message generated for change (Tracker Item Submitted) made by angelfaraldo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489547&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.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ángel faraldo (angelfaraldo)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: clicks when using portaudio
Initial Comment:
Pd-0.43.1-extended-20120220
Macbook pro 2.66GHz Intel Core 2 Duo, OSX 10.6.8
built-in sound & RME Fireface 800
Irregular clicks when using portaudio (not when using jack). Other portaudio applications (i.e. Audacity) work perfectly fine.
identical tests on Pd-0.42.5-extended work without any problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489547&group_…
The PdLab Jenkins server is back up and running:
https://macosx105-i386.pdlab.puredata.info
I just got it a proper CAcert.org TLS certificate, so
If you want to build your software on the jenkins server, please post a request here on pd-dev. I'd like to be able to support all pd devs using it, but that means people have to handle issues with their builds themselves, and not touch the configuration, or anyone else's builds.
.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
Hi,
A recent thread on Pd Everywhere suggests that the function
rtext_senditup in g_rtext.c sometimes divides by a font width. This
causes occasional crashes because the font width may be 0 when running
with the nogui flag:
http://noisepages.com/groups/pd-everywhere/forum/topic/any-issues-with-subp…
This raises a couple of questions: First, why does any part of the
code look at font properties at all when nogui is set? Second, how do
we fix this?
I suppose the best solution would be to make sure that font properties
are never queried when nogui is set. In the meantime, a quick fix
might be to modify the initialization of sys_fontlist (s_main.c, lines
126-128), setting fi_hostfontsize, fi_width, and fi_height equal to
one. Any thoughts would be appreciated!
Cheers,
Peter
He means that the latest extended-debian-testing-amd64 builds are only
1.8K, and indeed they are.
http://autobuild.puredata.info/auto-build/
Andras
On Sat, Feb 18, 2012 at 21:00, Hans-Christoph Steiner <hans(a)at.or.at> wrote:
>
> I don't quite understand. That one worked for you, or didn't? Which
> build has a problem?
>
> .hc
>
> On Feb 18, 2012, at 2:51 PM, patrick wrote:
>
> > hi hans,
> >
> > Pd-0.43.1-extended-debian-testing-amd64.deb 18-Feb-2012 06:53
> 1.8K
> >
> > there's surely a problem with the autobuild system
> > thank for all the work
> >
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> "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(a)iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
Patches item #3485016, was opened at 2012-02-06 08:38
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&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: feature
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: (Win) allow externals to load DLLs from the same folder
Initial Comment:
In order to have objects like readanysf~ and purest_json work on Windows, they need to include DLLs for libraries like ffmpeg and curl. In order for the DLLs of the objects to load other DLLs from that same folder, SetDllDirectory() needs to be set first. This requires a minimum of Windows XP SP1 (10 years old at this point).
There are three patches included, the first sets up the new build system for this, the second sets up makefile.mingw for this. The third is the actual change to s_loader.c. I think MSVC sets WINVER automatically, but just be sure its set to 0x0502 for this to work.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-02-19 18:19
Message:
drat, the "zip" file attached looks like empty HTML glueball.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3485016&group_…
Patches item #3481846, was opened at 2012-01-30 17:41
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&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: 8
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] on start, the Pd window doesn't always show msgs
Initial Comment:
Sometimes, when Pd starts, it only writes a portion of the stored ::pdwindow::logbuffer to the Pd Window. This tiny patch fixes that by waiting for the event loop before printing the logbuffer to the Pd window.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-02-19 17:57
Message:
Hmm, the attached file doesn't look loke a patch file (some HTM trash
instead)???
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&group_…
Bugs item #3489433, was opened at 2012-02-19 11:38
Message generated for change (Tracker Item Submitted) made by megrimm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489433&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.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: megrimm (megrimm)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: Excesive Spacing Between Logs In PD Window
Initial Comment:
Pd-Extended 0.43.1 - most recent 10.5 autobuild
osx 10.7
When changing "Log" numbers from the drop down Log window there is either excessive spacing between items or not enough spacing.
For example, If Log 2 is chosen and there are several "...couldn't create"'s there is no spacing between items. If Log 2 is chosen there is excessive spacing between log items. If for example log 4 is then chosen, those spaces are filled in.
I guess this is not detrimental to functionality but more of an aesthetic bug.
Ideally no matter what log mode is chosen the viewable items should all be single spaced, no?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489433&group_…
Bugs item #3489348, was opened at 2012-02-19 02:17
Message generated for change (Tracker Item Submitted) made by angelfaraldo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489348&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.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ángel faraldo (angelfaraldo)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: cputime not working
Initial Comment:
Pd version pd-0.43.1-extended-20120218-macosx105-i386
Mac OSX 10.6.8/Intel
[cputime] doesn't produce any output, although it doesn't report an error in the pd window.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489348&group_…
Bugs item #3489062, was opened at 2012-02-18 10:10
Message generated for change (Tracker Item Submitted) made by jmmmp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489062&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: João Pais (jmmmp)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: problem with audio (asio?)
Initial Comment:
In XP pd-ext 0.43 (build from yesterday), I get audio problems: trying to run with asio (as I always do with 0.42), the audio is very noisy. It sounds as if the audio isn't synced to the system card, or something. The sinus in the audio test patch has lots of irregular clicks, almost as if they would be dropouts.
This is with asio. With standard audio (MMIO) the result is much worse, but similar. Sometimes it sends messages as "can't synch audio".
Audio options are -asio -audioindev 2 -audiooutdev 2 -channels 2 -midiindev 1 -midioutdev 1 -audiobuf 40, and they always worked with previous versions of pd-ext.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3489062&group_…
On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann
<peter.brinkmann(a)googlemail.com> wrote:
>
> Hi Chuck,
> Check out the early bits of this thread --- various use cases already came
> up along the way:
> http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html. The short
> version is that libpd is being used in such a wide range of settings that
> you can come up with legitimate use cases for pretty much anything (single
> Pd instance shared between several threads, multiple Pd instances in one
> thread, and anything in between). At the level of the audio library, it's
> impossible to make good assumptions about threading.
Hi Peter
That's the part I really don't understand, and I don't really have a
clear picture of how you want to be able to control/choose between
those cases.
I can also see how there could be more capabilities tied to having
multiple threads generally. Â Â But specifically, I can't say. Â I have
no clue.
>> I remember a conversation with IOhannes in August about
>> multi-threading audio via sub-canvas user interface object (propose
>> thread~ akin to block~). Â If all you're after is audio
>> multi-threading--there's no need for multiple instances of Pd.
>> Threads could be used to start a portion of the dsp chain, running
>> asynchronously, and then join/synchronize with Pd when finished.
>
>
> I don't think a patch is the place where decisions about threading should be
> made. Threading is an implementation detail that users shouldn't have to
> worry about, and besides, whether you have anything to gain from threading
> will depend on a number of factors that users won't necessarily be able to
> control or even know about.
I have a different view. Â Every sort of use for Pd is like writing a
program--you should assume Pd users are writing programs with every
sort of tool you give them--the flipside to having to control
threading explicitly is that you get to control how finely grained the
threading is. Â Putting it on the patching level is just the user
interface--and it can work out nicely for grouping. Â Even if you have
some automatic tools, you may still want to have explicit control
through another available interface (e.g. for debugging).
>> What this would look like: Â Add a thread_prolog, thread_epilog, and
>> thread_sync function. The thread_prolog function that occurs before
>> block_prolog, starts a thread running the portion of dsp chain
>> cointained within, and returns the pointer to the function following
>> the thread_epilog. Â The thread_epilog function that occurs after
>> block_epilog--waits for synchronization and returns.
>>
>>
>> What's the difficult part: You would need to have a good ordering of
>> the dsp chain to take advantage of concurrency--each subcanvas having
>> a thread~ object needs to kick off as early as possible, followed by
>> objects that have no dependence on its output. Â Secondly, you'd need
>> to put thread_sync on the dsp chain immediately before you will
>> encounter functions with data dependencies.
>
>
> I believe it's much simpler than that. It should be enough to just do a
> topological sort of the signal processing graph; that'll tell you which
> objects are ready to run at any given time, and then you can parallelize the
> invocation of their perform functions (or not, depending on how many
> processors are available). I don't think there's any need to explicitly
> synchronize much; tools like OpenMP should be able to handle this
> implicitly.
> Cheers,
> Â Â Â Â Peter
For that--the dspchain (an array of int*) makes a very bad structure.
So, you'll want to re-write a handful of functions and data structures
around having multiple concurrent branches of computations. Â I
actually really like this problem :D Â I can picture a linked list of
dspchains to do this. Â But... the description of the sort algorithm
really will determine what the data structure ought to be.
Re-writing dsp_tick() is nearly sacrilege to me... beautiful bit of
code there, but that would have to be done according to whatever you
do to dspchain.
Chuck