Patches item #3494768, was opened at 2012-02-26 08:10
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&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: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: verbose() leaves blank lines when filtered out in Pd window
Initial Comment:
When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this:
verbose(3, "three");
verbose(4, "four");
verbose(3, "three");
Setting the log level to four will show:
three
four
three
Setting the log level to 3 will show:
three
three
When it should show:
three
three
I'm assigning this to IOhannes because I think he wrote the current verbose() function.
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-08-31 17:10
Message:
applied (0.44)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-02-27 06:32
Message:
That was quick. The solution makes sense to me. But I think its a bad
idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s
custom level numbering the same, or make it the same as the Pd window,
error(), logpost(), etc.. I still really think the +4 on the loglevel
doesn't make sense.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:57
Message:
attached is a fix for the problem (thus changing Tracker to 'Patches' and
assigning to miller)
it also closes the gap between verbose() and post() by applying a
loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is
following post() (loglevel=2) immediately.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:52
Message:
the problem comes from the use of endpost() to terminate the message.
endpost() doesn't know anything about log-levels, so it tags all LFs as
"normal".
i can think of 2 ways to fix this:
- don't use endpost() to terminate a message, but instead append the "\n"
to the message itself (which get's tagged with the log-level)
- make endpost() aware of the last used loglevel and terminate any message
using this level
i'd rather go for the 1st solution, as it doesn't require any global
state...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…
Patches item #3494768, was opened at 2012-02-26 08:10
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&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: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: verbose() leaves blank lines when filtered out in Pd window
Initial Comment:
When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this:
verbose(3, "three");
verbose(4, "four");
verbose(3, "three");
Setting the log level to four will show:
three
four
three
Setting the log level to 3 will show:
three
three
When it should show:
three
three
I'm assigning this to IOhannes because I think he wrote the current verbose() function.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2012-10-04 02:01
Message:
very nice article and idea
http://www.cheaplouisvuittonreplica2012.com/replica-louis-vuitton-monogram-…
----------------------------------------------------------------------
Comment By: Miller Puckette (millerpuckette)
Date: 2012-08-31 17:10
Message:
applied (0.44)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2012-02-27 06:32
Message:
That was quick. The solution makes sense to me. But I think its a bad
idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s
custom level numbering the same, or make it the same as the Pd window,
error(), logpost(), etc.. I still really think the +4 on the loglevel
doesn't make sense.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:57
Message:
attached is a fix for the problem (thus changing Tracker to 'Patches' and
assigning to miller)
it also closes the gap between verbose() and post() by applying a
loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is
following post() (loglevel=2) immediately.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-02-27 04:52
Message:
the problem comes from the use of endpost() to terminate the message.
endpost() doesn't know anything about log-levels, so it tags all LFs as
"normal".
i can think of 2 ways to fix this:
- don't use endpost() to terminate a message, but instead append the "\n"
to the message itself (which get's tagged with the log-level)
- make endpost() aware of the last used loglevel and terminate any message
using this level
i'd rather go for the 1st solution, as it doesn't require any global
state...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…
Bugs item #3573542, was opened at 2012-10-01 14:49
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3573542&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: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: GUIs not updating well on parent patch
Initial Comment:
Hi there. Please check my abstraction patches as an example. I have my old PhaseVocoder patches (PhaseVoc.zip) from 2010 and a more elaborate new uptade to thos (Brane-e.zip). Both do not run well on Pd 0.43 (Vanilla or Extended).
Get the examples at:
https://docs.google.com/folder/d/0B3AoiT0xk8fnNFBxWDFNeDZ6Y1E/edit
Lets first check what happens with the PhaseVoc examples (which are 2: PVoc & LPvoc). Pvoc works fine, but LPVoc is very critical, it doesn't update well the GUI values, like number boxes or the sliders. Start recording on in and you will see. But the, it works fine on Pd 0.42
As for Brane-e, it will be the same kind of trouble when you're recording into the buffer. But i Pd 0.42 it works like a charm.
I tried other operational systems and got the same kind of problems. I'm runing a macbook air i7 1.8GHz on Mac Os 10.7.4
Cheers
Alex
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3573542&group_…
Feature Requests item #3573226, was opened at 2012-09-30 09:24
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3573226&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
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: show # of [s]/[r]'s in subpatch on subpatch
Initial Comment:
Hey,
Here is another idea..
Since pd is a graphical programing software, why not make the "wlan-cables" :) visible as well.
Personally, I tend to not use [s]/[r]'s if possible, since one (at least me) forgets, where the objects have been placed, especially if one has highly "nested" structures. ..But having nested structures is the only time when one rather needs [s]/[r]'s.
So, what's about indicating if there are [s]/[r]s somewhere inside the subpatch, on the subpatch-object or in the subpatch (on the subpatch-canvas)??
..Maybe something like a "shown-on-demand" list containing the [s]/[r]'s names.
..Or at least just a symbol (the letters "s" and/or "r" or a dot or whatever). Better than nothing!!!
PS: This sounds so easy, if I only could access some sort of savefile of a patch, without the need to save it (like in memory, or something - I'm not a hardcore-programmer) I could even analyse the file with pd itself, and draw something on the appropriate canvas via "dynamic-patching"...
Bye & I'd like to read of any resopnse... (just for the motivation)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3573226&group_…
hi all,
i would like to introduce myself and kindly request for an SVN write access
to pd repository.
My name is Antoine Villeret and i'm working with pd since i met Cyrille
Henry last year.
I'm mainly working on computer vision.
At the very beginning i'm a musician and sound technician then
I started computer vision in 2008 by turning a bodhrán into a touchscreen
during my master thesis.
After that, I worked with Cyrille on a dynamic video mapping system to
project video on moving objects on stage.
It is used in the show *Les Fuyantes *by the French circus company Les
Choses de Rien.
You can have a small overview of the the work here :
http://vimeo.com/37387879
For that work i have to add some features to pix_opencv that are already on
the repository like pix_opencv_calibration, pix_opencv_warpperspective...
(commited by Cyrille).
But i've made some others externals and also corrected lots of bugs.
I also made some examples on how to use my externals.
Moreover I've planned to develop an OpenCL based object mainly to do binary
texture readback.
And I will be happy to share my work with the community :-).
Actually i've already made a copy of the SVN repository on my github
account but it's quite experimental and only used in my personal projects.
I saw that pd, pd-extended and Gem have already migrated to git but about
externals repository ? and mainly pix_opencv ? is it planned to switch to
git too ?
My SF username is : avilleret
Kind regards
antoine
--
do it yourself
http://antoine.villeret.free.frhttp://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour
me contacter
Bugs item #3571255, was opened at 2012-09-24 09:42
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3571255&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: Open
Resolution: None
Priority: 5
Private: Yes
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Put' Number
Initial Comment:
Number box will not allow me to edit the number. it stays at 0.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3571255&group_…
Bugs item #3571088, was opened at 2012-09-23 17:59
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3571088&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: Graph-On-Parent
Group: v0.43
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: gops invisible / win32 intel
Initial Comment:
abstractions with gop-subpatches / abstraction itself: no gop / open first abstraction: all fine; second abstraction: some gops disappeared
(Tcl) UNHANDLED ERROR: bad screen distance "nan"
while executing
".xb01ec8.c create line \
41 nan \
54 nan \
68 nan \
81 nan \
94 nan \
108 nan \
121 nan \
134 nan \
148 nan \
161 nan \
174 nan \
188 nan \
201 nan \
..."
("uplevel" body line 147)
invoked from within
"uplevel #0 $cmds_from_pd"(Tcl) UNHANDLED ERROR: bad screen distance "nan"
while executing
".xb01ec8.c create line \
41 nan \
54 nan \
68 nan \
81 nan \
94 nan \
108 nan \
121 nan \
134 nan \
148 nan \
161 nan \
174 nan \
188 nan \
201 nan \
..."
("uplevel" body line 147)
invoked from within
"uplevel #0 $cmds_from_pd"(Tcl) UNHANDLED ERROR: bad screen distance "nan"
while executing
".xb01ec8.c create line \
41 nan \
54 nan \
68 nan \
81 nan \
94 nan \
108 nan \
121 nan \
134 nan \
148 nan \
161 nan \
174 nan \
188 nan \
201 nan \
..."
("uplevel" body line 147)
invoked from within
"uplevel #0 $cmds_from_pd"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3571088&group_…
Feature Requests item #3568997, was opened at 2012-09-18 08:57
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568997&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
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: fixed arrays
Initial Comment:
Just a second one...:
What's about "fixed arrays".
Generally there are two types: "display-arrays" and "interactive-arrays". I guess the names say it all, but one is just showing something, the other requires user-interaction.
But in pd there only is the "interactive-array"-type.
Again this becomes more confusing, if one uses more arrays of different types, in one graph.
One workaround would be to always/periodically refresh a "display-array". But that, in contrast to "make-it-non-interactive" really is a workaround! ..And depending on the arraysize and tcl/tk uses lots of CPU per array. ...And one even wasted one's time drawing the wrong array...
..I guess that's it for now...
thx $bye
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568997&group_…
Feature Requests item #3568992, was opened at 2012-09-18 08:46
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568992&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
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Colored arrays
Initial Comment:
Hey,
what do you (whoever reads this) think of colored arrays?
It's a nice thing to be able to put several arrays into one graph, but it quickly gets confusing. Since it is all black, one does not know which array one drags, or what belongs where (especially if one selects to "draw as points")...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568992&group_…