Patches item #2977780, was opened at 2010-03-27 16:19
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2977780&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: bugfix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin Peach (mrpeach)
Summary: bugfixes for maxlib/netclient.c (pd-extended 0.42.5)
Initial Comment:
Fixes lack of reporting of disconnect through the right outlet and added safer way of reporting disconnect as it can be triggered by out-of-order events.
(there is still the issue of netserver not reporting socket info or ip address properly)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2977780&group_…
Bugs item #2957058, was opened at 2010-02-23 01:11
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&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: v0.43
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Jonathan Wilkes (jancsika1)
>Assigned to: Miller Puckette (millerpuckette)
>Summary: a pointer to [route] crashes; [route] lacks a 'pointer' type
Initial Comment:
[namecanvas foo]
[traverse foo, bang(
|
[pointer]
|
[route symbol]
|
[print]
1) a pointer message is erroneously routed as a symbol
2) this crashes Pd
3) [route pointer] doesn't route a pointer
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-04-13 02:01
Message:
Hans,
The crash is caused by any object which attempts to display the
output: the<crtl-4> symbol box, [set $1( -- [ ( both cause the crash as
well. The [route] object is outputting a symbol message with some mutant
value (I assume the selector is 'symbol' because if you hook [route] to a
[vsl], for example, you get "no method for 'symbol'"
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-12 23:31
Message:
There are a number of "types" in pd:
[symbol] [float] [list] [bang] [pointer]
[trigger symbol float list bang pointer]
[route] does [route symbol float list bang] so it is inconsistent that
[route pointer] would not route the "pointer" atom type, and instead route
based on the "pointer" as a symbolic selector. That right there is a bug
IMHO.
As for the crash, I could also reproduce it using Pd version
0.42.5-extended-20100410 or pd-gui-rewrite 0.43 on Mac OS X 10.5.8/Intel.
The crash is actually in the [print], not the [route]. When I remove the
[print], it doesn't crash.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-03-01 16:58
Message:
Oops, I didn't realize that when lists get distributed the atoms are
interpreted, just like the [list] object classes. E.g., I though the
following would output an error but it works fine:
[list one two(
|
[select symbol]
You know, since [route list] has different behaviors depending on whether
the first element is a float or symbol, the same could be done for [route
pointer]-- strip the selector off of anythings, pass gpointer messages
through unchanged. That way there is at least some consistency, in the
sense that the selector is always being matched.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2010-03-01 13:41
Message:
Hi Jonathan,
that's not really what I meant. You can use pointers in a list-message of
course ("list <pt1> <pt2> <pt3>") or [pack/unpack] many of them and so on.
Even [pipe] works with pointers and lists of pointers now.
But when you strip a lone pointer from it's selector then the pointer
itself could become the selector like: "list set 2"->[route list] becomes
"set 2" and this will call the "set"-method of the next object. If this is
a message box it will be set to "2".
But with a pointer you'd get "pointer <pt>" -> [route pointer] -> "<pt>",
so now it would try to use some "<pt>" method, which is probably
undefined. BTW: I guess that's what leads to the crash here. I think
selectors must be symbols.
So to make use of the pointless pointer (pun intended :) one probably has
to attach a selector again with [list] or [pointer] or something.
Anyway I guess we're now talking about the usefulness of route's
implementation, which is debatable and led to the development of several
nicer variants in GridFlow.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-03-01 12:48
Message:
Hi Frank,
Is it really useless? If you send a gpointer through the following,
it works:
[rewind $1(
|
[pointer]
That's a meta message consisting of a symbol-atom and a pointer-atom. And
the pointer atom gets sent successfully to the right inlet. However, I
can't currently find a way to test sending a single pointer-atom to the
left inlet. (If you try to strip it with list trim you always end up with
the "list" selector.)
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 07:16
Message:
I meant to write:
useless just like a "gem_state" stripped of its *selector*.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-03-01 07:15
Message:
First I have to correct myself: The selector of a pointer-message is indeed
"pointer", as can be seen with zexy's new rawprint object or by exploiting
the error message of an object like [select] when sent a pointer which is
"no method for 'pointer'".
So "route pointer" could or maybe should indeed route a "pointer"
meta-message just like it can route a "gem_state" message However as
[route] also strips off the selector you would be left with just the
pointer that is more or less useless just like a "gem_state" stripped of
its pointer cannot be used in the gem chain anymore.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-02-28 22:11
Message:
(pointer) with the g missing is what is specified in m_atom.c for
displaying a pointer atom. So I assume there's a difference between a
pointer message and a pointer atom.
There are two reasons to [route] pointer messages.
1) Didactic-- [route] is a common object people use to learn about the
behavior of messages in Pd. It would be nice to show all the predefined
message types going to different outlets, which can't currently happen
because [route] doesn't differentiate between pointers and anythings.
2) Because anythings and pointers aren't differentiated, this diminishes
the flexibility of an abstraction inlet. So a data-structure related
abstraction that wants to take "set," "flush", "clear", and pointer
messages to the left inlet and do something else with the right inlet has
to add an additional inlet. The [pointer] object can differentiate between
a pointer and "rewind," for example. An abstraction should be able to have
the same flexibility.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-02-25 11:37
Message:
Yep, a gpointer is not simply a message composed of "pointer" and some
actual pointer blob. I don't know the exact details myself and don't really
understand the source code, but they seem to be something very "special"
just like signals are. As you know, [print] shows them as a not very
helpful "(gpointer)", but if you pass a pointer to [list prepend set]-[list
trim] and into a message box: There pointers show up as "(pointer)" with
the "g" missing. Anyway don't bother trying [route (pointer)], it doesn't
work either. :)
In the end we probably have to accept that gpointers don't have a
"printable" selector, just like audio signals don't have one. Introducing a
print- and routable selector as "pointer" may be useful, or maybe it's not,
as some people may already use "pointer" as a meta-message in their
patches, for example to handle mouse-"pointer" events or so.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2010-02-25 00:54
Message:
Hm, I'm just not understanding something about gpointers-- I'd just assumed
when you send a pointer message it consists of the selector "pointer"
followed by the gpointer itself (gridflow's [display] seems to confirm
this). But clearly something else is going on because [route pointer]
doesn't currently work for gpointers, nor will [pointer] accept a gpointer
that has passed through [pointer $1( (though [route] will, without
crashing, and output a usable gpointer that has the selector "list").
It also seems like "pointer 1 2 3" is an unchecked case of "bad arguments
to message 'pointer'". So I guess I'm saying I agree that [route pointer]
should route according to the selector "pointer", I just don't understand
why a gpointer wouldn't match under those conditions.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2010-02-23 03:40
Message:
Hi Jonathan,
I raised the priority as crashes are really serious. I disagree with your
item 3), though. [route pointer] should not route GPointers, but
meta-messages starting with the symbol "pointer" e.g.
[pointer 1 2 3(
|
[route pointer]
|
It does that just fine.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2957058&group_…
Bugs item #2879422, was opened at 2009-10-14 20:14
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&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: Deleted
Resolution: Invalid
Priority: 5
Private: No
Submitted By: João Pais (jmmmp)
Assigned to: Nobody/Anonymous (nobody)
Summary: general audio meter
Initial Comment:
audio meters are very nice, but not 100% helpful. the sound level is connected to the actual sound volume of the system, and not to pd dac~ output (independently of how many there are). wouldn't the latter make more sense?
----------------------------------------------------------------------
Comment By: João Pais (jmmmp)
Date: 2010-04-13 04:07
Message:
I probably was high or drunk when I filed that report, then. (curious, I
remember double checking). I'll try to erase it and don't waste anyone's
time.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-04-13 03:56
Message:
those meters have not been added in 0.43; but have always been there
older implementations would just display the levels as numbers, whereas
the gui-rewrite gives you a (hopefully more appealing) graphical
representation.
anyhow, looking at the code, the levels are calculated in the code that
sends signals to the [dac~] (resp. fetches signals from the [adc~]), so no
system-levels are involved at all: whatever you see are numbers only
related to Pure data (which i think is the correct behaviour)
----------------------------------------------------------------------
Comment By: João Pais (jmmmp)
Date: 2010-04-13 03:30
Message:
Hi. Ooops, yes. I meant the audio meters of the Pd window, the ones added
in version 0.43.
Hmm, I just tested them again with 0.43.0-devel-20100315 windows, and it
doesn't behave as I say initially.
I can't test on ubuntu now, but either it got corrected, or I submitted a
false error.
Best,
João
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-12 23:43
Message:
I am not sure which audio meters you mean. As far as I know, the meters in
the Pd window are related to dac~ output, but I could be wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&group_…
Bugs item #2985017, was opened at 2010-04-10 09:40
Message generated for change (Comment added) made by irmaosaturno
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2985017&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: v0.42
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Paulo Casaes (irmaosaturno)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: popup not working in windows (with workaround)
Initial Comment:
Ben Bogart's popup is not working properly in windows (PD-Extended 0.41).
It loads fine but it does not output a selection nor does using its inlet work to change its selection. Whenever you try to do so it gives the error:
error: popup0xa4fda0: no such object
I tracked the problem down and it seems that in windows TK doesn't like it when the pointer reference in hex starts with 0x. This might actually be a problem with the TK provided in the windows version and not with popup itself. In Linux and OS X the reference has 0x in it and works just fine.
Here's a workaround that fixes the problem.
diff popup.c popup.c.orig
596,599d595
< #ifdef NT
< char buf2[256];
< char *buf2ptr;
< #endif
646,654d641
< #ifdef NT
< sprintf(buf2,"%p",x);
< buf2ptr = &buf2;
< if(strstr(buf2, "0x") == buf2ptr) {
< buf2ptr++;
< buf2ptr++;
< }
< sprintf(buf,"popup%s",buf2ptr);
< #else
656d642
< #endif
661,663d646
< #ifdef NT
< sys_vgui("proc popup_sel%x {index} {\n pd [concat popup%s output $index \\;]\n }\n",x,buf2ptr);
< #else
665c648
< #endif
---
>
Changes only in the popup_new function. It uses the NT preprocessing directive, in Linux and OS X it should remain unchanged. Basically it tests the pointer for 0x and removes it.
Paulo
----------------------------------------------------------------------
Comment By: Paulo Casaes (irmaosaturno)
Date: 2010-04-13 11:43
Message:
Just tested it (in windows). Works perfectly.
I had originally used %lx but figured it was "wrong" to cast a pointer to
an long unsigned int. Just checked out the source for pd, shows how what I
know :)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 11:21
Message:
good idea, I got rid of the warnings by casting:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…
----------------------------------------------------------------------
Comment By: Paulo Casaes (irmaosaturno)
Date: 2010-04-13 06:59
Message:
Changing %p to %lx does work but it gives off the warning:
popup.c:655: warning: format '%lx' expects type 'long unsigned int', but
argument 3 has type 'struct t_popup *'
when compiling. The Makefile has -Werror in the linux build, so that also
has to be changed.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 03:01
Message:
These commits should have fixed it:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2985017&group_…
Bugs item #2985017, was opened at 2010-04-10 08:40
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2985017&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: v0.42
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Paulo Casaes (irmaosaturno)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: popup not working in windows (with workaround)
Initial Comment:
Ben Bogart's popup is not working properly in windows (PD-Extended 0.41).
It loads fine but it does not output a selection nor does using its inlet work to change its selection. Whenever you try to do so it gives the error:
error: popup0xa4fda0: no such object
I tracked the problem down and it seems that in windows TK doesn't like it when the pointer reference in hex starts with 0x. This might actually be a problem with the TK provided in the windows version and not with popup itself. In Linux and OS X the reference has 0x in it and works just fine.
Here's a workaround that fixes the problem.
diff popup.c popup.c.orig
596,599d595
< #ifdef NT
< char buf2[256];
< char *buf2ptr;
< #endif
646,654d641
< #ifdef NT
< sprintf(buf2,"%p",x);
< buf2ptr = &buf2;
< if(strstr(buf2, "0x") == buf2ptr) {
< buf2ptr++;
< buf2ptr++;
< }
< sprintf(buf,"popup%s",buf2ptr);
< #else
656d642
< #endif
661,663d646
< #ifdef NT
< sys_vgui("proc popup_sel%x {index} {\n pd [concat popup%s output $index \\;]\n }\n",x,buf2ptr);
< #else
665c648
< #endif
---
>
Changes only in the popup_new function. It uses the NT preprocessing directive, in Linux and OS X it should remain unchanged. Basically it tests the pointer for 0x and removes it.
Paulo
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 10:21
Message:
good idea, I got rid of the warnings by casting:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…
----------------------------------------------------------------------
Comment By: Paulo Casaes (irmaosaturno)
Date: 2010-04-13 05:59
Message:
Changing %p to %lx does work but it gives off the warning:
popup.c:655: warning: format '%lx' expects type 'long unsigned int', but
argument 3 has type 'struct t_popup *'
when compiling. The Makefile has -Werror in the linux build, so that also
has to be changed.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 02:01
Message:
These commits should have fixed it:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2985017&group_…
Bugs item #2985017, was opened at 2010-04-10 09:40
Message generated for change (Comment added) made by irmaosaturno
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2985017&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: v0.42
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Paulo Casaes (irmaosaturno)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: popup not working in windows (with workaround)
Initial Comment:
Ben Bogart's popup is not working properly in windows (PD-Extended 0.41).
It loads fine but it does not output a selection nor does using its inlet work to change its selection. Whenever you try to do so it gives the error:
error: popup0xa4fda0: no such object
I tracked the problem down and it seems that in windows TK doesn't like it when the pointer reference in hex starts with 0x. This might actually be a problem with the TK provided in the windows version and not with popup itself. In Linux and OS X the reference has 0x in it and works just fine.
Here's a workaround that fixes the problem.
diff popup.c popup.c.orig
596,599d595
< #ifdef NT
< char buf2[256];
< char *buf2ptr;
< #endif
646,654d641
< #ifdef NT
< sprintf(buf2,"%p",x);
< buf2ptr = &buf2;
< if(strstr(buf2, "0x") == buf2ptr) {
< buf2ptr++;
< buf2ptr++;
< }
< sprintf(buf,"popup%s",buf2ptr);
< #else
656d642
< #endif
661,663d646
< #ifdef NT
< sys_vgui("proc popup_sel%x {index} {\n pd [concat popup%s output $index \\;]\n }\n",x,buf2ptr);
< #else
665c648
< #endif
---
>
Changes only in the popup_new function. It uses the NT preprocessing directive, in Linux and OS X it should remain unchanged. Basically it tests the pointer for 0x and removes it.
Paulo
----------------------------------------------------------------------
Comment By: Paulo Casaes (irmaosaturno)
Date: 2010-04-13 06:59
Message:
Changing %p to %lx does work but it gives off the warning:
popup.c:655: warning: format '%lx' expects type 'long unsigned int', but
argument 3 has type 'struct t_popup *'
when compiling. The Makefile has -Werror in the linux build, so that also
has to be changed.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 03:01
Message:
These commits should have fixed it:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=134…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2985017&group_…
Bugs item #2879422, was opened at 2009-10-15 02:14
Message generated for change (Comment added) made by jmmmp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&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: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: João Pais (jmmmp)
Assigned to: Nobody/Anonymous (nobody)
Summary: general audio meter
Initial Comment:
audio meters are very nice, but not 100% helpful. the sound level is connected to the actual sound volume of the system, and not to pd dac~ output (independently of how many there are). wouldn't the latter make more sense?
----------------------------------------------------------------------
>Comment By: João Pais (jmmmp)
Date: 2010-04-13 10:07
Message:
I probably was high or drunk when I filed that report, then. (curious, I
remember double checking). I'll try to erase it and don't waste anyone's
time.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-04-13 09:56
Message:
those meters have not been added in 0.43; but have always been there
older implementations would just display the levels as numbers, whereas
the gui-rewrite gives you a (hopefully more appealing) graphical
representation.
anyhow, looking at the code, the levels are calculated in the code that
sends signals to the [dac~] (resp. fetches signals from the [adc~]), so no
system-levels are involved at all: whatever you see are numbers only
related to Pure data (which i think is the correct behaviour)
----------------------------------------------------------------------
Comment By: João Pais (jmmmp)
Date: 2010-04-13 09:30
Message:
Hi. Ooops, yes. I meant the audio meters of the Pd window, the ones added
in version 0.43.
Hmm, I just tested them again with 0.43.0-devel-20100315 windows, and it
doesn't behave as I say initially.
I can't test on ubuntu now, but either it got corrected, or I submitted a
false error.
Best,
João
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 05:43
Message:
I am not sure which audio meters you mean. As far as I know, the meters in
the Pd window are related to dac~ output, but I could be wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&group_…
Bugs item #2879422, was opened at 2009-10-15 02:14
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&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: Invalid
Priority: 5
Private: No
Submitted By: João Pais (jmmmp)
Assigned to: Nobody/Anonymous (nobody)
Summary: general audio meter
Initial Comment:
audio meters are very nice, but not 100% helpful. the sound level is connected to the actual sound volume of the system, and not to pd dac~ output (independently of how many there are). wouldn't the latter make more sense?
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-04-13 09:56
Message:
those meters have not been added in 0.43; but have always been there
older implementations would just display the levels as numbers, whereas
the gui-rewrite gives you a (hopefully more appealing) graphical
representation.
anyhow, looking at the code, the levels are calculated in the code that
sends signals to the [dac~] (resp. fetches signals from the [adc~]), so no
system-levels are involved at all: whatever you see are numbers only
related to Pure data (which i think is the correct behaviour)
----------------------------------------------------------------------
Comment By: João Pais (jmmmp)
Date: 2010-04-13 09:30
Message:
Hi. Ooops, yes. I meant the audio meters of the Pd window, the ones added
in version 0.43.
Hmm, I just tested them again with 0.43.0-devel-20100315 windows, and it
doesn't behave as I say initially.
I can't test on ubuntu now, but either it got corrected, or I submitted a
false error.
Best,
João
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 05:43
Message:
I am not sure which audio meters you mean. As far as I know, the meters in
the Pd window are related to dac~ output, but I could be wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&group_…
Bugs item #2879422, was opened at 2009-10-15 02:14
Message generated for change (Comment added) made by jmmmp
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&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: None
Priority: 5
Private: No
Submitted By: João Pais (jmmmp)
Assigned to: Nobody/Anonymous (nobody)
Summary: general audio meter
Initial Comment:
audio meters are very nice, but not 100% helpful. the sound level is connected to the actual sound volume of the system, and not to pd dac~ output (independently of how many there are). wouldn't the latter make more sense?
----------------------------------------------------------------------
>Comment By: João Pais (jmmmp)
Date: 2010-04-13 09:30
Message:
Hi. Ooops, yes. I meant the audio meters of the Pd window, the ones added
in version 0.43.
Hmm, I just tested them again with 0.43.0-devel-20100315 windows, and it
doesn't behave as I say initially.
I can't test on ubuntu now, but either it got corrected, or I submitted a
false error.
Best,
João
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 05:43
Message:
I am not sure which audio meters you mean. As far as I know, the meters in
the Pd window are related to dac~ output, but I could be wrong.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2879422&group_…
Bugs item #2803995, was opened at 2009-06-10 10:20
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2803995&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: 1
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: PdX and Debian filesystem policy
Initial Comment:
PdX installs _all_ documentation into /usr/lib/pd/doc.
it does not install anything into /usr/share/doc/pd-extended, which is the natural place to look for help on a debian system. (as a matter of fact it is used so often, that it can be regarded as a "list of installed packages"; pd-extended does not show up here)
it would be nice if at least a note on where to find the "real" documentation would be placed into /usr/share/doc/pd-extended.
as stated in debian's policy http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile e"very package must be accompanied by a verbatim copy of its copyright and distribution license in the file /usr/share/doc/package/copyright".
PdX violates the debian policy in this regard.
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-04-13 09:15
Message:
this bug report is not about missing .pd files in /usr/share/doc/
it's about violating the debian policy by not installing _anything_ into
/usr/share/doc/pd-extended, namely copyright files.
and i repeat that it would be nice (think of this as a feature request) to
direct the user to the "interactive" help of Pd-patches.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-04-13 06:50
Message:
.pd files are not static files like HTML, they are more like .pl or .py
files. Therefore, it is perfectly appropriate for the help patches to go
into /usr/lib/pd. It would not be appropriate to include them in
/usr/share/doc/pd... since they are not really viewable using less, a text
editor, or a web browser. I discussed this at length during the Debian Bug
Squashing Party in NYC back at the end of January.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-06-10 17:52
Message:
yes, the packages need a lot of work, and I am sure there are tons of
policy violations, and I am a big beliver in Debian Policy. But there are
only so many hours in the day.
Anyone should feel free to do this since I probably won't get to it for a
while.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2803995&group_…