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_…
Bugs item #3568605, was opened at 2012-09-17 14:47
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3568605&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: abstractions
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: no $0 in arrays resulting in name-conflicts
Initial Comment:
It seems I can't use "$0" in array-names. And if I rename an array including the "$0" and save it, the "$0" becomes eg. 1002 and can't be found anymore... if the patch uses eg "1004" for "$0".
One can't always use [table]-objects.
And one can't use arrays in GUI-abstractions it seems..
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3568605&group_…
Feature Requests item #3567328, was opened at 2012-09-13 03:56
Message generated for change (Tracker Item Submitted) made by charlesgg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3567328&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
Priority: 5
Private: No
Submitted By: Charles Goyard (charlesgg)
Assigned to: Nobody/Anonymous (nobody)
Summary: LN_S in Makefile templates
Initial Comment:
LN_S is an alias for ln -s. It could be ln -sf.
With ln -s, when rebuilding pd-extended, you are forced to make clean before, so everything is rebuilt.
With ln -sf, an existing symlink does not cause the build to fail.
Note some externals (zexy for example) hardcode ln -s instead of @LN_S@.
Thank you,
Charles
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3567328&group_…
Patches item #3566852, was opened at 2012-09-11 18:46
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3566852&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: feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: viagra pas cher
Initial Comment:
viagra pas cher
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3566852&group_…
Patches item #3566368, was opened at 2012-09-10 12:14
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3566368&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: documentation
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: cialis 20 mg
Initial Comment:
cialis 20 mg
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3566368&group_…