Bugs item #2933148, was opened at 2010-01-15 23:17
Message generated for change (Tracker Item Submitted) made by reduzent
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933148&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-devel
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roman Haefeli (reduzent)
Assigned to: Nobody/Anonymous (nobody)
Summary: [pd-gui-rewrite] 'vis 1' to canvas moves window
Initial Comment:
When sending 'vis 0' and 'vis 1' repeatedly to a canvas, the window moves downwards with each cylce. The amount of the shift seems dependent on the height of the menu of the window. If the window is wide enough so that the whole menu fits into one line, the amount is significantly smaller (ca. 30px). With a narrow window and a menu splitted into three lines, the amount is bigger (ca. 60px).
Could it be, that the stored window position refers to the patching area, whereas when drawn by the window manager, the patching area is shifted by the menu?
I tested on Gnome and fluxbox. The shifting does not happen with pd-vanilla.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2933148&group_…
Bugs item #2932195, was opened at 2010-01-14 18:36
Message generated for change (Tracker Item Submitted) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2932195&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: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: this crashes pd extended
Initial Comment:
Sorry for the generic title but I really can't isolate the problem.
When I try to open this attached patch on Windows Vista, pd Extended immediately crashes. The patch has no loadbangs and does absolutely nothing without user input.
100% of the times I open it, it crashes.
Since it first crashed when I was trying to create a [print] object, I have tried to remove all [print]s with a text editor (changing them for [pd]s just to avoid messing up connections) and could open it without crash. However, if I then go on editing the patch, creating and deleting objects, it usually crashes in a few minutes.
I suspect the cause is in some of these objects:
[dirpanel]
[folder_list]
and/or, possibly,
[sys_gui]
because I tried creating a new fresh patch with none of these and play around and I couldn't have it crash - while if I create some of these objects and then keep editing the patch, chances are that it crashes very soon.
But it may be some generic problem with all externals...
Windows vista, pd-extended 0.41.4
I have been using pd Vanilla for a long time and never had such a problem.on the same machine
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2932195&group_…
Attached is a patch that should make flext buffer handling 64-bit compatible.
It adds new wrapper functions buffer::Peek(int index) and
buffer::Poke(int index, t_sample value) to access a buffer's data. New
externals should uses these instead of accessing the data array
directly, because with newer PDs that doesn't work. I've also updated
the buffer1 example to use the new API wrappers.
The issue is that arrays in PD are of type t_word, which is a union
that can contain a variety of data, including pointers. In 32-bit
architectures you can pretty much ignore that it's a union because
floats and pointers are the same size, but on 64-bit architectures
it's important to use the w_float member of the union to access stored
floats.
This patch shouldn't break any old externals unless they're used with
PD > 0.41 (but then they'd be broken, anyways). I don't have access to
an OS X machine or Max/MSP, so I've so far only tested this on 64-bit
linux/PD. YMMV.
Can someone explain to me why pd's arrays are arrays of t_word instead
of t_sample?
-s-
On Thu, Oct 1, 2009 at 10:41 AM, dmotd <dmotd(a)gmx.net> wrote:
> hi spencer,
>
> afaik there hasn't been any progress with
> the 64bit translation, i was going to
> attempt it last time i needed it but got
> distracted along the way - and i sent a
> similar message to thomas at the time, so
> its going to be on his todo list, but
> proabably not a priority.
>
> i'd be happy to test any changes you
> make, and collaborate time permitted.
>
> ciao,
>
> dmotd
>
> Spencer Russell wrote:
>> Thought this should probably go to the list:
>>
>> ---------- Forwarded message ----------
>> From: Spencer Russell <spencer.f.russell(a)gmail.com>
>> Date: Tue, Sep 29, 2009 at 11:13 AM
>> Subject: Re: fixing Flext for 64-bit?
>> To: Thomas Grill <gr(a)grrrr.org>
>>
>> >
>> > Am 29.09.2009 um 15:00 schrieb Spencer Russell:
>> >
>> >> Hi Thomas,
>> >>
>> >> I'm writing a Flext external to implement Iannis Xenakis's Dynamic
>> >> Stochastic Synthesis, and running into some problems with buffer
>> >> handling on my 64-bit system.
>> >>
>> >> It seems that currently flext uses the deprecated
>> >> garray_getfloatarray() function and t_sample arrays, instead of the
>> >> new garray_getfloatwords() function with t_word unions.
>> >>
>> >> Changing the code would make flext incompatible with older versions of
>> >> PD, but some other external developers are currently using an #ifdef
>> >> workaround to change to the newer API call for PD versions that
>> >> support it.
>> >>
>> >> I was going to get in there and see if i can't get it working in the
>> >> flext code, but I wanted to check with you first to see if you had
>> >> already done any work on that front. I'll of course send you the diffs
>> >> if i get it working. Shouldn't be that hard and i think it should
>> >> really only effect the buffer-handling code, but I don't know the
>> >> flext codebase that well so there  might be some hidden gotchas.
>> >>
>> >> -spencer
>>
>> On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill <gr(a)grrrr.org> wrote:
>> > Hi Spencer,
>> > i know that this is something i should work on, but my schedule is insanely
>> > tight and i don't get to it.
>> > So, if you can make any contributions and testing on 64-bit systems i'd be
>> > very grateful.
>> > I'd also go for the Pd API selecton by #ifdef statements.
>> > gr~~~
>> >
>>
>> As far as i can tell, PD since 0.41 changed arrays to be arrays of
>> t_words instead of t_samples or t_floats.
>>
>> On 32-bit architectures they're all the same size, but on 64-bit
>> architectures t_word is 64-bit, while t_sample and t_float are still
>> 32-bit.
>>
>> For a normal PD external, it's pretty easy to just modify the external
>> to use t_words, but I'm not sure the best way to modify flext to do
>> this without breaking compatibility for externals. One problem is that
>> when an external calls mybuffer.Data(), what should they receive? if
>> the system is PD newer than 0.41, they should receive a pointer to
>> t_word, but MAX or older PD should receive a pointer to t_sample.
>>
>> The other problem is that accessing an element for newer PD requires
>> accessing the w_float member of the t_word union, but the others just
>> use the element itself.
>>
>> There could be some sort of GetValue() wrapper for buffer elements
>> that could be made cross-platform, but would break compatibility with
>> existing flext externals, so that seems seriously sub-optimal.
>>
>> thoughts?
>>
>> -s-
>> _______________________________________________
>> http://grrrr.org/ext/flext
>>
>> flext mailing list
>> flext(a)grrrr.org
>> http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext
>
Bugs item #2921977, was opened at 2009-12-27 20:17
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921977&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-devel
Group: v0.43
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: max (maxn)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: multiple selections with shift
Initial Comment:
selecting multiple parts of a patch using the shift-key doesn't work any more with the gui-rewrite version
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2010-01-13 02:22
Message:
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: 2009-12-29 04:43
Message:
thanks for reporting, should be fix in this commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=128…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2921977&group_…
Hey IOhannes,
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=129…
Just checking out your commits. The ./pd-gui.tcl [[<host>:]<port>]
stuff looks interesting, but your commit removed that stringent test,
which might be needed if "wish pd-gui.tcl" is going to be able to
handle command line args like -stderr -open -verbose, etc. Just
something to test and look out for.
Also, what are the security implecations of this?
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody
gives their life for anything. We steal the lives of these kids. -
Admiral Gene LeRocque
Hey IOhannes,
Any reason not to use the "tkwait visibility .pdwindow.tcl.entry"
option? I think its preferable because it keeps things symmetic, i.e.
grab/ungrab. It'll only cause the GUI to pause, 'pd' will still keep
loading.
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-gui-rewri…
.hc
----------------------------------------------------------------------------
All information should be free. - the hacker ethic
Bugs item #2929975, was opened at 2010-01-11 13:39
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2929975&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: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: [pd-gui-rewrite] random crashes when starting from pd-gui
Initial Comment:
i get random crashes, when i start the pd-gui-rewrite as "pd-gui" with arguments
the "delme.pd" is a simple patch containing msgboxes and [print]s.
zmoelnig@ferrari:~/src/cvs/pure-data/pd-gui/src$ wish8.5 ./pd-gui.tcl delme.pd
::pd_connect::from_pd
Connection from 127.0.0.1:42400 registered
Error in startup script: grab failed: window not viewable
while executing
"grab set -global .pdwindow.tcl.entry"
(procedure "::pdtk_canvas::started_loading_file" line 4)
invoked from within
"::pdtk_canvas::started_loading_file [format "%s/%s" $basename $filename]"
(procedure "open_file" line 5)
invoked from within
"open_file $filename"
(procedure "open_filestoopen" line 3)
invoked from within
"open_filestoopen"
(procedure "main" line 43)
invoked from within
"main $::argc $::argv"
(file "./pd-gui.tcl" line 629)
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-01-12 14:38
Message:
tkwait visibility .pdwindow.tcl.entry' seems like the right idea, but I
moved it to the main proc, since it is only needed in the startup
procedure
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=129…
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-01-12 03:18
Message:
fixed with r12959;
it turned out that the pdwindow was not yet visible when the "grab"
command occured, which crashed.
on tk8.4, either the code is executed slower and thus the window is
already visible when the "grab" is called, or it simply behaves more rebust
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-01-11 13:41
Message:
debian (squeeze/sid) tcl/tk8.5 (probably 1/3 of my startups fail)
with tcl/tkl8.4 it seems to be more stable...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2929975&group_…
Bugs item #2930859, was opened at 2010-01-12 20:33
Message generated for change (Tracker Item Submitted) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2930859&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: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: [popen] 1st outlet doesn't work in Windows Vista
Initial Comment:
In windows vista (only platform I tested on), when you send a message to [popen], the output from the first outlet has an unpredictable behaviour.
Here's some of the things that happen (same test gives different results if repeated):
1) The expected output, i.e. the output generated by the command in the "shell", one symbol ber line
2) "sending <message>" where <message> is a verbatim copy of the message you have input
3) "sending <message><junk>" where <junk> is either a random sequence of unreadable characters, or a random slice of some previously input message
4) When the output of the command is mulltiline (e.g. "dir") you sometimes get only the first N lines (correctly output as multiple symbol messages, but not all the messages that the command actually produces in the shell, e.g. in the case of "dir" not the complete list of files)
These are the cases I've been able to observe.
By the way by "expected behaviour" I mean what I guess is the expected behaviour, as the help-patch totally lacks a description of what the external does.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2930859&group_…
Bugs item #2930741, was opened at 2010-01-12 11:54
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2930741&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-devel
Group: v0.43
>Status: Pending
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: max (maxn)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch size not saved
Initial Comment:
it seems pd-rewrite saves the position of patches and subpatches, but not their sizes.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-01-12 14:22
Message:
Using today's SVN on Mac OS X 10.5.8, running in both Aqua and X11, I can't
reproduce this. Both poistion and size are saved for me.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2930741&group_…
Bugs item #2930743, was opened at 2010-01-12 11:55
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2930743&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-devel
Group: v0.43
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: max (maxn)
>Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: patches off-screen not shown
Initial Comment:
patches with positions off the screen (fox ex. on a disconnected second monitor) aren't automatically shown on the present screen
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2010-01-12 13:59
Message:
works for me! nice algorithm, I like that! I expanded on it to also
handle width and height:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=129…
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-01-12 13:04
Message:
should be fixed with revision 12966;
please confirm whether it works or not
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2930743&group_…