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_…
Bugs item #3568989, was opened at 2012-09-18 08:38
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3568989&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: subpatch-audio (reblocked) out of sync
Initial Comment:
Hello,
I think I've found a rather fundamental (vanilla) bug.
Imagine the following (as the title says): One has a (subpatch with) blocksize=64. Inside there are 2 more subpatches with a blocksize=128. Now it can happen, that both are in sync to eachother, because both are in sync to the 1st 64 samples of the parent-patch. Or they are not in sync, because one sticks to the 1st 64, tho other one sticks to the 2nd 64 samples.
It would look like this:
Out of sync:
Parent: =_=_=_=_=_=_=_=_=_=_... <-BS=64
Sub1..: ===_===_===_===_===_... <-BS=128
Sub2..: =_===_===_===_===_==... <-BS=128
Sync:
Parent: =_=_=_=_=_=_=_=_=_=_... <-BS=64
Sub1..: ===_===_===_===_===_... <-BS=128
Sub2..: ===_===_===_===_===_... <-BS=128
I won't paint it, but one can imagine that there is even more potential chaos if the blocksize-ratio is biger than 2 (=128/64).
This is the only part in pd, that really is not deterministic! Because this behavior, the "relative block-position" ("sync/no sync") can change with each dsp-switching. ..At least I couldn't find a way to make it do what I want..
To think of a more complicated version: Imagine one wants to sync subpatches, which are not in the same parent...
I don't know what it would be good for to have blocks not be synced, but there may even be an application for that.
So wouldn't it be a good idea to let the user decide how they sync??
...Maybe via some initial subpatch-parameters... Something like "1/2 or 2/2" for a BS-ratio=2. (1/8, 2/8, 3/8,..., 7/8, 8/8 for a BS-ratio=8) ...just as with a sequencer...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3568989&group_…
Feature Requests item #3568987, was opened at 2012-09-18 08:35
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568987&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: subpatch-audio (reblocked) out of sync
Initial Comment:
Hello,
I think I've found a rather fundamental (vanilla) bug.
Imagine the following (as the title says): One has a (subpatch with) blocksize=64. Inside there are 2 more subpatches with a blocksize=128. Now it can happen, that both are in sync to eachother, because both are in sync to the 1st 64 samples of the parent-patch. Or they are not in sync, because one sticks to the 1st 64, tho other one sticks to the 2nd 64 samples.
It would look like this:
Out of sync:
Parent: =_=_=_=_=_=_=_=_=_=_... <-BS=64
Sub1..: ===_===_===_===_===_... <-BS=128
Sub2..: =_===_===_===_===_==... <-BS=128
Sync:
Parent: =_=_=_=_=_=_=_=_=_=_... <-BS=64
Sub1..: ===_===_===_===_===_... <-BS=128
Sub2..: ===_===_===_===_===_... <-BS=128
I won't paint it, but one can imagine that there is even more potential chaos if the blocksize-ratio is biger than 2 (=128/64).
This is the only part in pd, that really is not deterministic! Because this behavior, the "relative block-position" ("sync/no sync") can change with each dsp-switching. ..At least I couldn't find a way to make it do what I want..
To think of a more complicated version: Imagine one wants to sync subpatches, which are not in the same parent...
I don't know what it would be good for to have blocks not be synced, but there may even be an application for that.
So wouldn't it be a good idea to let the user decide how they sync??
...Maybe via some initial subpatch-parameters... Something like "1/2 or 2/2" for a BS-ratio=2. (1/8, 2/8, 3/8,..., 7/8, 8/8 for a BS-ratio=8) ...just as with a sequencer...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568987&group_…
Feature Requests item #3568612, was opened at 2012-09-17 15:12
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568612&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: autobuilds gone! why?
Initial Comment:
I want the autobuilds back. What happened?
What happend to the double-builds and all that?
...little off topic, sorry...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3568612&group_…