Patches item #3589133, was opened at 2012-11-22 04:18
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3589133&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: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jamie Bullock (postlude)
Assigned to: Miller Puckette (millerpuckette)
Summary: Patcher windows always open on "primary" monitor
Initial Comment:
Pd version tested with: 0.43.3 Vanilla
Steps to reproduce:
- connect a second monitor
- open Pd
- create a new patch and move it to the second monitor
- create a subpatch
Expected behaviour:
- the subpatch window opens on the same monitor as the parent patch
Actual behaviour:
- the subpatch window opens on the primary monitor
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 15:04
Message:
I didn't see the need to place the wondw over the object (patch number 2)
but applied the
first one to vanilla. Will mark this 'pending' pending...
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-12-14 18:36
Message:
The code was just always placing the new subpatch windows in the top left
corner of the main screen. I did two things in Pd-extended:
1. made the window placement logic aware of the full desktop size, not just
the main screen
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended…
2. made the window of new subpatches open near where the object was
placed.
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3589133&group_…
Patches item #3587384, was opened at 2012-11-14 21:06
Message generated for change (Settings changed) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3587384&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: Pending
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Miller Puckette (millerpuckette)
Summary: Replacing deprecated functions
Initial Comment:
vexp_fun.c currently uses the old BSD-style functions drem and finite. These functions have been removed from XCode 4.4 and later, so that the expr~ family of externals fails to compile now. This patch replaces drem with remainder and finite with isfinite, which should work everywhere.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-12-15 08:53
Message:
your title got my hopes on with instant goldBy Coolmatt701 electronic
2009-09-01
[url=http://diablo3goldok.smartlog.dk/]Arianne Parmentier's inexpensive
market[/url]
<a href="http://diablo3goldok.smartlog.dk/" title="Arianne Parmentier's
inexpensive market">Arianne Parmentier's inexpensive market</a>
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-03 20:32
Message:
accepted for 0.44
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-11-20 12:34
Message:
Makes sense to me. remainder() is the C99 replacement for drem(), and
isfinite() is the C99 replacement for finite(). C99 marks drem() and
finite() as deprecated.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3587384&group_…
Patches item #3585461, was opened at 2012-11-08 13:09
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585461&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: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: [readsf~] loops some files
Initial Comment:
some wav-files get looped when played back via [readsf~].
it seems that the problem is dues to the soundfile fitting exactly into the fifobuffer, thus the EOF (signalled by the read-thread) drain never really starts in the perform routine.
(fifohead==fifosize, so the test for (!x_eof && x_fifohead >= x_fifotail && x_fifohead < x_fifotail + wantbytes-1) never triggers, resulting in a continuous drain of the entire buffer.
the attached soundfile triggers this behaviour.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 14:38
Message:
applied for 0.44
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-11-08 13:11
Message:
attached is a simplistic attempt to fix the problem: if the
fifohead==fifosize, we wrap it to 0 even if we just read the last byte.
(originally this was only done if !EOF)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585461&group_…
Patches item #3575521, was opened at 2012-10-08 09:40
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3575521&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: Pending
>Resolution: Accepted
Priority: 7
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: remove pdtk_array.tcl, its dead unused code
Initial Comment:
pdtk_array.tcl was never used in any production code, but it slipped into the pure-data.git. Everything in pdtk_array.tcl is unused, old duplicates of dialog_array.tcl. This patch removes pdtk_array.tcl.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 14:19
Message:
applied for 0.44
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3575521&group_…
Patches item #3584286, was opened at 2012-11-05 10:14
Message generated for change (Settings changed) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3584286&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: None
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Miller Puckette (millerpuckette)
Summary: Win32: fix mouse wheel scrolling by setting the scroll incr
Initial Comment:
Instead of scrolling step by step it goes directly to the end of the canvas (using the mousewheel).
That is true for vanilla and ext releases of pd0.43 (windows). Worked in pd0.42.5
Bye
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 14:16
Message:
I applpied this even though it said 'fixed' - hope this is OK. Leaving
open for now just in case.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-12-14 20:27
Message:
Win32: fix mouse wheel scrolling by setting the scroll increment. For some
crazy reason, win32 mousewheel scrolling is in units of 120, and this
forces Tk to interpret 120 to mean 1 scroll unit.
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3584286&group_…
Patches item #3584286, was opened at 2012-11-05 10:14
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3584286&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: None
Group: None
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Miller Puckette (millerpuckette)
Summary: Win32: fix mouse wheel scrolling by setting the scroll incr
Initial Comment:
Instead of scrolling step by step it goes directly to the end of the canvas (using the mousewheel).
That is true for vanilla and ext releases of pd0.43 (windows). Worked in pd0.42.5
Bye
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 14:16
Message:
I applpied this even though it said 'fixed' - hope this is OK. Leaving
open for now just in case.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-12-14 20:27
Message:
Win32: fix mouse wheel scrolling by setting the scroll increment. For some
crazy reason, win32 mousewheel scrolling is in units of 120, and this
forces Tk to interpret 120 to mean 1 scroll unit.
http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3584286&group_…
Patches item #3469773, was opened at 2012-01-05 03:05
Message generated for change (Settings changed) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3469773&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: Closed
>Resolution: Out of Date
Priority: 1
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: update version in configure.ac
Initial Comment:
the (new) configure.ac has a notion of the current version, which is passed via the AC_INIT() command.
in Pd-0.43.1 this version is still set to 0.43.0, which looks a bit weird when compiling (as the wrong version shows up)
given that this version is not really used anywhere, the attached patch is purely cosmetic (and outdated whenever applied :-)
nevertheless it would be nice if the versions could be kept in sync.
it would be even nicer if somebody could provide a bit of code that fills the AC_INIT() version into m_pd.h
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3469773&group_…
Patches item #3438338, was opened at 2011-11-15 07:17
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438338&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: Pending
>Resolution: Accepted
Priority: 7
Private: No
Submitted By: Katja (katjav)
Assigned to: Miller Puckette (millerpuckette)
Summary: change float to t_float in Pd 'extra'
Initial Comment:
0001-change-float-to-t_float-in-Pd-extra.patch converts instances of 'float' to 't_float' in all classes of vanilla Pd's 'extra'. Also, a few constants and literals are defined with more decimals, and some float suffixes removed. The patch is intended for Pd-043.1test5.
Type 't_float' is already used in most of pd core code. The changes in the 'extra' classes would make them compliant with the core in this sense.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 13:56
Message:
applied for 0.44
----------------------------------------------------------------------
Comment By: Katja (katjav)
Date: 2011-11-16 02:28
Message:
I've checked the case of bonk~ once more because the difference was
remarkable there (that is, in terms of a test situation). It is fully due
to a more precise definition of pi, 3.141592653589793 instead of 3.14159.
Since a literal without float suffix is a double anyway, 3.14159 for pi is
a waste of precision even when t_float is float. And even when this waste
is considered unimportant, a more precise definition can not spoil the
intended calculation result.
So to answer IOhannes' question: the differences can be considered an
improvement (albeit probably an unimportant one) of the situation. In
practice, no one will be dependent on an exact output of bonk~, it is even
quite hard to create a reproducible test situation. The same holds for
fiddle~ and sigmund~. In this sense, the patch can be safely applied as
is.
By the way, the test patches can be opened to see results in detail,
they're not dependent on a script to run them.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-11-16 00:41
Message:
i guess the question is: are the differences an _improvment_ of the
situation (e.g. because [bonk~] historically produced slightly "off" values
and the patch now fixes that)?
in this case i think one could argue, that your patch is fixing a minor
bug, and should be applied, even if it breaks 100% compatibility (and then:
if somebody relies on an exact value output in float-domain, they should
re-think their patch anyhow)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-11-15 21:14
Message:
That answers my somewhat stupid question: your unittest patch will show the
differences.
----------------------------------------------------------------------
Comment By: Katja (katjav)
Date: 2011-11-15 11:50
Message:
The more precise constants and removal of float suffixes originate from my
attempts to make Pd work in single and double precision. Maybe I should
make a patch file without these changes for the moment, till I've reviewed
them better.
Hans I do not understand your question 'how can we see what those
differences are?' If you build a patched Pd-0.43.1test5 and run the tests
which are also attached below, you'll see that the differences are in the
analysis objects, notably bonk~.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-11-15 09:20
Message:
These changes would complete the t_float/t_sample clean up that happened
with the core back in 0.42 (I think). I think it should be included in
0.43 if possible.
Katya, how can we see what those differences are?
----------------------------------------------------------------------
Comment By: Katja (katjav)
Date: 2011-11-15 07:36
Message:
correction: the reference for the unit test patches was pd-0.43.0 vanilla
release
----------------------------------------------------------------------
Comment By: Katja (katjav)
Date: 2011-11-15 07:33
Message:
Accompanying the patch file, I've produced unit test patches. The reference
was pd-043.1 vanilla release. The tests indicate slightly altered output
for some of the classes, probably due to more precise constants and removal
of float suffixes. See attached 'unittests-pdextras.zip'.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438338&group_…
Patches item #3432654, was opened at 2011-11-03 02:53
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3432654&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-dev
Group: bugfix
>Status: Pending
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: pkg-config improvement
Initial Comment:
with the new autotools-based build system, Pd also generates a pkg-config [1] file (it's pd.pc, generated from pd.pc.in).
the purpose of this file is to sease compilation of externals in a standardized way, by providing information on where to find header files (e.g. /usr/include/pd) and which libraries we need to link too (e.g. link against pd.lib" on w32, but not on other platforms)
unfortunately i was a bit too eager, when i first created this file, adding lots of flags and bells and whistles, which have turned out to be more confusing than helping.
attached patch therefore simplifies the generated pd.pc to only hold the relevant information (see in-patch description for more details)
[1]
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 13:30
Message:
Not sure what to do with this - it looks like it might still be useful but
it doesn't apply cleanly and
I don't know y way around configure.ac to fix it.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3432654&group_…
Patches item #3426630, was opened at 2011-10-20 19:30
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3426630&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: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Alex Norman (alexnorman)
Assigned to: Miller Puckette (millerpuckette)
Summary: Increasing maximum size of alsa midi input
Initial Comment:
I've made the input size configurable and the default size larger so that we can accept much larger messages, very useful for sysex input.
Essentially taken from desire data I think, quite a while ago.
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-12-15 13:26
Message:
No idea why 512... but sounds better than 20:)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-10-21 10:12
Message:
looks good to me, included in Pd-extended 0.43
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3426630&group_…