Bugs item #1845770, was opened at 2007-12-06 12:15
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1845770&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: stereopticon (stereopticon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PiDiP ascii renderer eats mac hard disks
Initial Comment:
...iknow, it sounds like a tabloid headline.
I'm running OSX 10.4.11 on a Macbook Pro 2.16 GHz Intel Core 2 Duo. I upgraded to pd 0.39.3-extended-rc5 recently and began messing around with the PiDiP ascii renderer. Early in a day of testing I loaded an 11-second, 640x480 quicktime clip compressed with the H.264 codec into pdp_ascii-help.pd and gotâŠnothing. The patch became completely unresponsive to mouse clicks and I ended up having to quit and relaunch pd and X11. I eventually discovered that pdp_ascii works with the Sorenson video 3 codec and spent a happy hour turning bits of things into ascii art.
Then I noticed something strange. The hard drive was nearly full. As I watched in shock, it filled up completely. A couple of minutes of searching found the culprit: my console log file for the session was 36 gigs. Turns out that all that space was taken up by a single message, âskipping corrupted frameâ, spit out over and over again at the ridiculous rate of 4 megs/sec. Trying to load the H.264 quicktime is what initiated the loop. Iâve been able to replicate it and came up with the following info: the bug runs independent of pd and X11, hogs 80% of the CPU, and since for some reason the process is tied to the OSX loginwindow process I was only able to kill it by logging out.
Cheers,
Michael
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-05-25 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-11 06:45
Message:
Logged In: YES
user_id=27104
Originator: NO
Is this still a problem on 0.40.3-extended test releases? It is
reproducable?
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-04-07 02:40
Message:
Logged In: YES
user_id=564396
Originator: NO
stupid me, but is the console log file part of os-x, pd-extended or did
you add it manually?
(imho, writing things (even if there are lots of things) to the console
does not really qualify as a bug)
furthermore, the log-message is likely not being emitted by pidip, but
rather by the underlying decoding library (libquicktime);
so the bug report should probably go there instead of here
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1845770&group_…
Patches item #1930733, was opened at 2008-03-31 21:02
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Invalid
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Thomas Grill (xovo)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 17:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 19:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1930733, was opened at 2008-03-31 21:02
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Invalid
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
>Assigned to: Thomas Grill (xovo)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 17:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 19:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1971585, was opened at 2008-05-24 17:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1971585&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: 5
Private: No
Submitted By: davigoli (davigoli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Path and Startup dialogs
Initial Comment:
Enhanced the Path and Startup dialogs to use Tk listbox widgets.
Ran into frustration with a max of 10 total startup paths and 10 total startup commands, as well as general low level of usability for these controls. Since they haven't been significantly changed in about 5 years or more, they seem to warrant an update.
These dialogs now support an arbitrarily long list of startup paths and commands. Other features include drag-and-drop reordering of path/startup items, consolidation of "Save all settings" button into the "apply" function, path browser for locating startup paths, and keyboard bindings for easy editing (Enter to change, Delete to delete, up and down arrows for navigation).
Before submitting, I vetted this project with members of the Pd community, and it received a sound approval from everyone who tried it. I also incorporated feedback as it was given. Please consider this patch for addition into the pd "vanilla" trunk. Thank you!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1971585&group_…
Bugs item #1970490, was opened at 2008-05-23 15:42
Message generated for change (Comment added) made by stffn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&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: externals
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: stffn (stffn)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: apple/sms don't work on macbook
Initial Comment:
This is Mac OS X.4.11. Macbook 1st. gen.
It outputs (43,0,93) no matter how i tilt the computer.
----------------------------------------------------------------------
>Comment By: stffn (stffn)
Date: 2008-05-24 20:42
Message:
Logged In: YES
user_id=1658640
Originator: YES
It seams my sms if fried too. I should have tested that prior to posting -
i'm sorry.
Hence i've changed the status to "closed".
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-24 00:06
Message:
Logged In: YES
user_id=27104
Originator: NO
I get the same result on my MacBook Pro 3rd gen, so I tried other software
that accesses the accelerometer, and it didn't work either. It seems that
my accelerometer is broken. I tested this on two or three other computers,
and it worked there.
Have you tried other apps?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&group_…
Bugs item #1772720, was opened at 2007-08-12 12:05
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1772720&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.39.2
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: marius schebella (mariusschebella)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pd crash with tabsend~ $0-array
Initial Comment:
Hi,
in Pd-0.39.3-extended-rc5 the attached patch crashes on closing when I make some changes and then klick on 'discard changes'.
Pd-0.39.3-extended-rc5 is the only version where this happens. and it happens only with arrays which have $0 in the name and only when dsp is running.
(on intel mac)
marius
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-05-23 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-09 13:05
Message:
Logged In: YES
user_id=27104
Originator: NO
Could not reproduce on Pd-extended 0.40.3-20080504 on Windows XP SP2,
Pd-extended 0.40.3-20080502 on Mac OS X 10.4.11/Intel, and Pd-vanilla
0.41-4 on Mac OS X 10.4.11/Intel.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-10-15 05:19
Message:
Logged In: YES
user_id=1658640
Originator: NO
I can reproduce.
This does crash Pd-extended 0.39.3 version 13-10-07 on intel core-duo
macbook but doesn't crash Pd-vanilla 0.40-2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1772720&group_…
Bugs item #1815044, was opened at 2007-10-17 06:52
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1815044&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: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: boonier (boonier)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: blosc~ not instantiating (0.39.3)
Initial Comment:
I have to physically rename the external from "blosc.pd_darwin" to "blosc~.pd_darwin" to get it working
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-23 18:49
Message:
Logged In: YES
user_id=27104
Originator: NO
this should work in Pd-extended 0.40.3-20080524
----------------------------------------------------------------------
Comment By: boonier (boonier)
Date: 2007-10-17 17:36
Message:
Logged In: YES
user_id=1915214
Originator: YES
Machine Name: PowerBook G4 17"
Machine Model: PowerBook5,1
CPU Type: PowerPC G4 (3.3)
Number Of CPUs: 1
CPU Speed: 1 GHz
L2 Cache (per CPU): 256 KB
L3 Cache (per CPU): 1 MB
Memory: 1 GB
Bus Speed: 167 MHz
Boot ROM Version: 4.6.2f1
Serial Number: ˇˇˇˇˇˇˇˇMVZ
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1815044&group_…
Bugs item #1970490, was opened at 2008-05-23 09:42
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&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: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: stffn (stffn)
>Assigned to: Hans-Christoph Steiner (eighthave)
Summary: apple/sms don't work on macbook
Initial Comment:
This is Mac OS X.4.11. Macbook 1st. gen.
It outputs (43,0,93) no matter how i tilt the computer.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-23 18:06
Message:
Logged In: YES
user_id=27104
Originator: NO
I get the same result on my MacBook Pro 3rd gen, so I tried other software
that accesses the accelerometer, and it didn't work either. It seems that
my accelerometer is broken. I tested this on two or three other computers,
and it worked there.
Have you tried other apps?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1970490&group_…
If you really want to get into realpath():
https://www.securecoding.cert.org/confluence/display/seccode/FIO02-A.
+Canonicalize+path+names+originating+from+untrusted+sources
.hc
> On May 22, 2008, at 10:06 PM, Hans-Christoph Steiner wrote:
>
>>
>> To quote the whole text:
>>
>> Avoid using this function. It is broken by design since (unless
>> using the non-
>> standard resolved_path == NULL feature) it is impossible to
>> determine a suitable
>> size for the output buffer, resolved_path. According to POSIX a
>> buffer of size
>> PATH_MAX suffices, but PATH_MAX need not be a defined constant,
>> and may have to
>> be obtained using pathconf(). And asking pathconf() does not
>> really help, since
>> on the one hand POSIX warns that the result of pathconf()
>> may be huge and
>> unsuitable for mallocing memory. And on the other hand pathconf
>> () may return -1
>> to signify that PATH_MAX is not bounded.
>>
>> I think whoever wrote that man page is really splitting hairs
>> there, the FreeBSD/Mac OS X man page has no complaints about it.
>> They are complaining that PATH_MAX _might_ not be defined. But on
>> GNU/Linux, MinGW, and FreeBSD/Mac OS X, FILENAME_MAX _is_
>> defined. So just use FILENAME_MAX to allocate the buffer that
>> realpath() uses (which was already happening anyway in s_main.c,
>> but with MAXPDSTRING instead). It's a widely implemented POSIX
>> function, how much more standard do you want? ;)
>>
>> I think that Pd should give reliable information in the publically
>> defined API (ok, s_stuff.h, but still). For example, it makes
>> life easier in a lot of ways if you can count on sys_libdir being
>> an absolute path, rather than making every other bit of code that
>> might every use a path that is based on sys_libdir check to make
>> sure that it is indeed absolute. The vast majority of the time,
>> sys_libdir is an absolute path, and AFAIK, on Windows it is always
>> an absolute path.
>>
>> .hc
>>
>>
>> On May 22, 2008, at 9:44 PM, Miller Puckette wrote:
>>
>>> I finally realized realpath() is a pre-existing function. (I
>>> imagined
>>> it was sitting in another source file that didn't make it to the
>>> patch)
>>>
>>> but.. "man realpath" says "Avoid using this function. It is
>>> broken by design..."
>>> so I'm sceptical of the idea. Anyway, why can't [import] just
>>> make the
>>> call if it needs it?
>>>
>>> cheers
>>> M
>>>
>>>
>>> On Thu, May 22, 2008 at 09:33:14PM +0200, Hans-Christoph Steiner
>>> wrote:
>>>>
>>>> The only real change to s_main.c in that path is the addition of
>>>> realpath(). It seems that the function there is just copying the
>>>> strings back and forth between sbuf and sbuf2, so I just added one
>>>> more iteration of that back and forth for realpath().
>>>>
>>>> .hc
>>>>
>>>> On May 22, 2008, at 9:25 PM, Miller Puckette wrote:
>>>>
>>>>> I might have missed it, but I didn't see that realpath() itself
>>>>> made it into
>>>>> the patch... ?
>>>>>
>>>>> M
>>>>>
>>>>> On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner
>>>>> wrote:
>>>>>>
>>>>>> The realpath() is definitely related. If you start Pd using a
>>>>>> relative path, like I do when doing dev work (e.g. make && ../
>>>>>> bin/
>>>>>> pd), then sys_libdir will be a relative path. That means it is
>>>>>> impossible to make absolute paths using sys_libdir, which is
>>>>>> what I
>>>>>> need to do to make [import] work, or loading libdirs with
>>>>>> [declare -
>>>>>> lib] and the libdir loader.
>>>>>>
>>>>>> I can't see any problems that realpath() might cause.
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
>>>>>>
>>>>>>> OK, I took most of the patch (not the "realpath()" call which
>>>>>>> seems
>>>>>>> unrelated) and uploaded to SVN, unless I'm mistaken.
>>>>>>>
>>>>>>> cheers
>>>>>>> Miller
>>>>>>>
>>>>>>> On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I was looking into this a bit more, and from what I can
>>>>>>>> tell, the
>>>>>>>> canvas-local path (ce_path) is always relative to the path
>>>>>>>> of the
>>>>>>>> parent patch. Here's the commit for pd-extended that adds
>>>>>>>> support
>>>>>>>> for absolute paths:
>>>>>>>>
>>>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data?
>>>>>>>> view=rev&revision=9862
>>>>>>>>
>>>>>>>> Also, I submitted a patch:
>>>>>>>>
>>>>>>>> http://sourceforge.net/tracker/index.php?
>>>>>>>> func=detail&aid=1917574&group_id=55736&atid=478072
>>>>>>>>
>>>>>>>> .hc
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think I fixed the full paths bug, here's the commit:
>>>>>>>>>
>>>>>>>>> http://pure-data.svn.sourceforge.net/viewvc/pure-data?
>>>>>>>>> view=rev&revision=9856
>>>>>>>>>
>>>>>>>>> .hc
>>>>>>>>>
>>>>>>>>> On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think this issue is pretty clear, and the languages that
>>>>>>>>>> I know
>>>>>>>>>> would fall along the lines of "each patch/abstraction has
>>>>>>>>>> its own
>>>>>>>>>> namespace" or in other words "#include only affects the
>>>>>>>>>> one .c
>>>>>>>>>> file", "import only affects the one .py file", etc. So I
>>>>>>>>>> agree
>>>>>>>>>> with Frank. Global settings are global, and canvas-local
>>>>>>>>>> settings
>>>>>>>>>> are local to the original file.
>>>>>>>>>>
>>>>>>>>>> The "semi-functional" part is the full paths that Marius
>>>>>>>>>> mentioned.
>>>>>>>>>>
>>>>>>>>>> Then the other question is how to use something like "#X
>>>>>>>>>> declare"/
>>>>>>>>>> canvas_savedeclarationsto() in externals. I'd like to
>>>>>>>>>> create an
>>>>>>>>>> [import] modelled after Python's import does, so I'd like
>>>>>>>>>> to use
>>>>>>>>>> "#X declare"/canvas_savedeclarationsto() with it.
>>>>>>>>>>
>>>>>>>>>> .hc
>>>>>>>>>>
>>>>>>>>>> On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I use 'declare' all the time.. don't think it's
>>>>>>>>>>> semifunctional at
>>>>>>>>>>> all.
>>>>>>>>>>> I think the questions about how declares should act inside
>>>>>>>>>>> abstractions
>>>>>>>>>>> are hard to resolve; in my own usage (and in the way I
>>>>>>>>>>> suggest
>>>>>>>>>>> others might
>>>>>>>>>>> want to use declare) it's always in the main patch, as a
>>>>>>>>>>> way to
>>>>>>>>>>> show the
>>>>>>>>>>> patch what libraries, etc, it needs.
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>> Miller
>>>>>>>>>>>
>>>>>>>>>>> On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph
>>>>>>>>>>> Steiner
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hey,
>>>>>>>>>>>>
>>>>>>>>>>>> So I am diving into the whole canvas-local namespace and
>>>>>>>>>>>> [declare]
>>>>>>>>>>>> issue these days. I like the new "#X declare"/
>>>>>>>>>>>> canvas_savedeclarationsto() functionality, I think it
>>>>>>>>>>>> could be
>>>>>>>>>>>> useful
>>>>>>>>>>>> for a lot of things. I was thinking of making an API to
>>>>>>>>>>>> use
>>>>>>>>>>>> it in
>>>>>>>>>>>> externals, something like sys_register_loader(). I have
>>>>>>>>>>>> two
>>>>>>>>>>>> questions, first, how entrenched is the current behavior of
>>>>>>>>>>>> [declare]? It currently is only semi-functional, and I
>>>>>>>>>>>> think few
>>>>>>>>>>>> people use it.
>>>>>>>>>>>>
>>>>>>>>>>>> The second is how to structure this for general use. I
>>>>>>>>>>>> have
>>>>>>>>>>>> thought
>>>>>>>>>>>> of two ways:
>>>>>>>>>>>>
>>>>>>>>>>>> - make "declare" the key word and allow other
>>>>>>>>>>>> objectclasses to
>>>>>>>>>>>> have
>>>>>>>>>>>> their own custom "#X declare" data.
>>>>>>>>>>>>
>>>>>>>>>>>> - allow objectclasses to register their own declaration key
>>>>>>>>>>>> words,
>>>>>>>>>>>> like [import] could have "#X import".
>>>>>>>>>>>>
>>>>>>>>>>>> The first would mean changing the behavior of [declare],
>>>>>>>>>>>> the
>>>>>>>>>>>> second
>>>>>>>>>>>> could lead to a big mess...
>>>>>>>>>>>>
>>>>>>>>>>>> .hc
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -----------------------------------------------------------
>>>>>>>>>>>> ----
>>>>>>>>>>>> --
>>>>>>>>>>>> --
>>>>>>>>>>>> -----
>>>>>>>>>>>> ----
>>>>>>>>>>>>
>>>>>>>>>>>> Man has survived hitherto because he was too ignorant to
>>>>>>>>>>>> know
>>>>>>>>>>>> how to
>>>>>>>>>>>> realize his wishes. Now that he can realize them, he must
>>>>>>>>>>>> either
>>>>>>>>>>>> change them, or perish. -William Carlos Williams
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> PD-dev mailing list
>>>>>>>>>>>> PD-dev(a)iem.at
>>>>>>>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------------------------------------------------------------
>>>>>>>>>> ----
>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> -------
>>>>>>>>>>
>>>>>>>>>> News is what people want to keep hidden and everything
>>>>>>>>>> else is
>>>>>>>>>> publicity. - Bill Moyers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------
>>>>>>>>> ----
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> ------
>>>>>>>>>
>>>>>>>>> You can't steal a gift. Bird gave the world his music, and
>>>>>>>>> if you
>>>>>>>>> can hear it, you can have it. - Dizzy Gillespie
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> ----
>>>>>>>> --
>>>>>>>> ---
>>>>>>>> ----
>>>>>>>>
>>>>>>>> News is what people want to keep hidden and everything else is
>>>>>>>> publicity. - Bill Moyers
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> PD-dev mailing list
>>>>>>>> PD-dev(a)iem.at
>>>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>> ---
>>>>>> ----
>>>>>>
>>>>>> News is what people want to keep hidden and everything else is
>>>>>> publicity. - Bill Moyers
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -----
>>>> ----
>>>>
>>>> "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
>>>>
>>>>
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> -------
>>
>> If you are not part of the solution, you are part of the problem.
>>
>>
>
>
>
>
------------------------------------------------------------------------
----
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Patches item #1942258, was opened at 2008-04-14 10:19
Message generated for change (Comment added) made by reakin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1942258&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: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: jack fixes and enhancements
Initial Comment:
the jack-implementation in Pd has several flaws:
- maximum number of ports = 32 (hardcoded)
- Pd crashes when you request more than 32 channels
- jackd has to run before Pd is started
- Pd doesn't like jackd quitting
- maximum of 2 parallel Pd's connecting to jack
- ...
i believe that the attached patch fixes most of these issues:
- raises the maximum number of ports to 1024 (this is the maximum number of ports qjackctl allows me to select for the jackd)
- when initializing ports, Pd checks whether a port was successfully created; if not it doesn't add more ports but leaves this as the maximum it could get from jackd (no more crashes with high number of ports)
- Pd automatically starts a default jackd if none is running yet
- when the jackd quits while Pd is running, it sets the jack_client to 0, efficiently preventing hangs. jackd is restarted automatically when selected via the audio-settings
- Pd tests the return status when trying to connect to jackd; if it finds that the name is already given it tries alternative names; if initialization failed for other reasons, it just fails.
i have tested this on my debian unstable/testing system that provides libjack-dev 0.109.2-1.1
----------------------------------------------------------------------
Comment By: Rich E (reakin)
Date: 2008-05-23 12:13
Message:
Logged In: YES
user_id=1586621
Originator: NO
This patch makes pd unusable while running jack in realtime with the
following system:
Ubuntu Gusty,
r@pal:~$ uname -a
Linux pal 2.6.22-14-rt #1 SMP PREEMPT RT Tue Feb 12 09:57:10 UTC 2008 i686
GNU/Linux
any version of pd-extended autobuilds from April 16th onwards. Pd-vanilla
does not have the same problem.
Exact sound symptons are:
Periodic glitches in audio, which is occasionally corrected when another
application is attached to jack (probably resetting the audio chain), but
the glitches return shortly. It only occurs when running jack in real-time
mode.
Here is a posting on the pd-list where I was discussing this issue:
http://lists.puredata.info/pipermail/pd-list/2008-05/062449.html
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 14:29
Message:
Logged In: YES
user_id=27104
Originator: NO
checked this patch into branches/pd-extended/0.40:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=9702
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-04-14 10:21
Message:
Logged In: YES
user_id=564396
Originator: YES
i raised priority a bit, as the current implementation makes Pd unusable
with highly multichannel systems (e.g. using 64 channels) and jack
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1942258&group_…