Hi,
two related thoughts to the tooltips:
- Using lots of multichannel audio I thought about a way to support
autoconnecting all outlets of multi-outlet objects with corresponding inlets of one or multiple objects. I'm sure, Miller has thought about that before. One thing which would help me tremendously would be to be able to make the id of an object visible by some ctl-shift-meta-alt-middle click on it. That way simple helper scripts like the one attached could be used to autoconnect (or disconnect) them.
- After getting audio dropouts in performances when closing windows
I'm in the process of restructuring my patches to have all audio in seperate real-time-audio-no-gui-pd-processes which are automatically started from the no-audio gui process. The two processes communicate via netsend/receive. It is quite cumbersome and timeconsuming to establish all the sends and receives to be tunneled through the net. Before I start porting my really complex patches, I'd like to know whether there are plans are to rework the graphics in the not-so-distant future. Miller said something about porting it to wxWindows some time ago if I remember correctly.
-- Orm
- After getting audio dropouts in performances when closing windows
I'm in the process of restructuring my patches to have all audio in seperate real-time-audio-no-gui-pd-processes which are automatically started from the no-audio gui process. The two processes communicate via netsend/receive. It is quite cumbersome and timeconsuming to establish all the sends and receives to be tunneled through the net. Before I start porting my really complex patches, I'd like to know whether there are plans are to rework the graphics in the not-so-distant future. Miller said something about porting it to wxWindows some time ago if I remember correctly.
- use yves patch of a threaded gui ... included in devel_0_37
- test miller's approach of limiting the size of messages sent to the
gui, implemented in 0.38 ... works fine for me ...
tim
Am 13. Dezember 2004, 15:44 Uhr (+0100) schrieb Tim Blechmann:
- test miller's approach of limiting the size of messages sent to the
gui, implemented in 0.38 ... works fine for me ...
I see. Maybe that's also the reason why I now (0.38-13) get a stack overflow much earlier than before. Reading out large datastructs I have to put a 'del 0' every 20th item or so. Before it could be more than 1000.
Has the stack size been decreased in favor of meeting audio deadlines?
-- Orm
Hi Orm, did you get these overflows also with other versions of 0.38 or the devel branch? I ask this because i introduced a more portable version of stack checking that keeps track of the recursion depth instead of the stack pointer. The old method was not compatible with e.g. Python which uses a lot of stack space. To my knowledge the default recursion depth is 1000. That basically means that a message can run through 1000 objects, but depending on the message handling of the object this can also be reduced by some small factor. I would suggest that the method of stack checking should be a compilation switch. Meanwhile you could try to uncomment "#define NEWSTACKMETH" in m_obj.c, line 13.
best greetings, Thomas
----- Original Message ----- From: "Orm Finnendahl" finnendahl@folkwang-hochschule.de To: pd-list@iem.kug.ac.at Sent: Monday, December 13, 2004 9:49 PM Subject: Re: [PD] making object ids visible
Am 13. Dezember 2004, 15:44 Uhr (+0100) schrieb Tim Blechmann:
- test miller's approach of limiting the size of messages sent to the
gui, implemented in 0.38 ... works fine for me ...
I see. Maybe that's also the reason why I now (0.38-13) get a stack overflow much earlier than before. Reading out large datastructs I have to put a 'del 0' every 20th item or so. Before it could be more than 1000.
Has the stack size been decreased in favor of meeting audio deadlines?
-- Orm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Hi Thomas,
Am 13. Dezember 2004, 22:32 Uhr (+0100) schrieb Thomas Grill:
Hi Orm, did you get these overflows also with other versions of 0.38 or the devel branch?
I used 0.38-test13 from Miller's site and applied the tooltip.diff patch.
I ask this because i introduced a more portable version of stack checking that keeps track of the recursion depth instead of the stack pointer. The old method was not compatible with e.g. Python which uses a lot of stack space. To my knowledge the default recursion depth is 1000. That basically means that a message can run through 1000 objects, but depending on the message handling of the object this can also be reduced by some small factor. I would suggest that the method of stack checking should be a compilation switch. Meanwhile you could try to uncomment "#define NEWSTACKMETH" in m_obj.c, line 13.
I don't really mind that much. It's basically just changing the modulo which stops the recursion by inserting the "del 0". Any stack will overflow sooner or later...
-- Orm
Tim Blechmann wrote:
- test miller's approach of limiting the size of messages sent to the
gui, implemented in 0.38 ... works fine for me ...
i missed this in the bustle, whats the strategy? not queing up too many gui operations to be done in one cycle?
- use yves patch of a threaded gui ... included in devel_0_37
- test miller's approach of limiting the size of messages sent to the
gui, implemented in 0.38 ... works fine for me ...
is this gui packet-size limit the reason you have to often open patches 2 or 3 times for them to actually draw all the way? i cant vouch for anything earlier than 0.36 but it happened ocasionally then, happened more often with impd 0.37 perhaps due to more GUI stuff...and happens even more in 0.38...
http://replic.net/~ix/pd/GrO/missing.PNG
my current strategy is open a small patch first, until everything settles down, then open the larger ones. many times however, the window doesnt even draw, rather than simply missing some stuff which minimizing and maximizing can sometimes fix..
can i just bump the packet size limit to 40,000. are there perhaps some packet size limit patches that havent made it into MAIN that i can apply, perhaps from devel or impd?
carmen
Hallo, ix hat gesagt: // ix wrote:
is this gui packet-size limit the reason you have to often open patches 2 or 3 times for them to actually draw all the way? i cant vouch for anything earlier than 0.36 but it happened ocasionally then, happened more often with impd 0.37 perhaps due to more GUI stuff...and happens even more in 0.38...
I see a [tot] here. I get this all the time with [tot], no idea, what's wrong there.
Ciao
Frank Barknecht _ ______footils.org__
hi Frank,
guess one: overloading of the transmit buffer guess two: an error in your tcl/tk code (use "catch", perhaps...)
Krzysztof
Frank Barknecht wrote: ...
I see a [tot] here. I get this all the time with [tot], no idea, what's wrong there.
i get these problems too. i also get this weird one:
http://eds.org/~joschi/temp/pd0.38test12-boxdrawbug.png
i opened a new patch window, hit ctl-1 to create a new blank object, and thats what it looks like.
ix wrote:
- use yves patch of a threaded gui ... included in devel_0_37
- test miller's approach of limiting the size of messages sent to the
gui, implemented in 0.38 ... works fine for me ...
is this gui packet-size limit the reason you have to often open patches 2 or 3 times for them to actually draw all the way? i cant vouch for anything earlier than 0.36 but it happened ocasionally then, happened more often with impd 0.37 perhaps due to more GUI stuff...and happens even more in 0.38...
http://replic.net/~ix/pd/GrO/missing.PNG
my current strategy is open a small patch first, until everything settles down, then open the larger ones. many times however, the window doesnt even draw, rather than simply missing some stuff which minimizing and maximizing can sometimes fix..
can i just bump the packet size limit to 40,000. are there perhaps some packet size limit patches that havent made it into MAIN that i can apply, perhaps from devel or impd?
carmen
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
i get these problems too. i also get this weird one:
http://eds.org/~joschi/temp/pd0.38test12-boxdrawbug.png
i opened a new patch window, hit ctl-1 to create a new blank object, and thats what it looks like.
That's a feature, not a bug, I suppose: Pd 0.38 shows not completely created objects using dashed lines. You dashes are a bit big, though.
BTW: If you rename an object, that was already connected, to an unknown object, then the connections will stay. Try with renaming an [osc~ 440] to [osc~440]
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Josh Steiner hat gesagt: // Josh Steiner wrote:
i get these problems too. i also get this weird one:
http://eds.org/~joschi/temp/pd0.38test12-boxdrawbug.png
i opened a new patch window, hit ctl-1 to create a new blank object, and thats what it looks like.
That's a feature, not a bug, I suppose: Pd 0.38 shows not completely created objects using dashed lines. You dashes are a bit big, though.
oh cool, yeah the dashes are a little weird looking at this size ;)
BTW: If you rename an object, that was already connected, to an unknown object, then the connections will stay. Try with renaming an [osc~ 440] to [osc~440]
oh that rocks!
-
Frank Barknecht -
ix -
Josh Steiner -
Krzysztof Czaja -
Orm Finnendahl -
Thomas Grill -
Tim Blechmann