Make a patch using diff -uw and submit it to the patch tracker.
I am currently away from my computer so this would have to wait. It is
however a difference of literally one character #, so FWIW IMHO diff-ing
it may be a bit of an overkill...
Ico
___
I don't know how the help browser works (Hans-Christophe wrote it) and
don't know whether that comment character is in there for some reason
or not. So I'm scared to fix this without hearing from HC.
I wonder if the old-fashioned idea of just using the file browser should
be available as
Interesting. Even if the line is preceded with an if statement which checks
for tclversion 8.5?
Ico
-Original Message-
From: Hans-Christoph Steiner [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 25, 2007 1:47 AM
To: Miller Puckette
Cc: [EMAIL PROTECTED]; pd-dev@iem.at
Subject:
-
From: Hans-Christoph Steiner [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 25, 2007 10:30 PM
To: Ivica Ico Bukvic
Cc: 'Miller Puckette'; pd-dev@iem.at
Subject: Re: [PD-dev] tcl 8.5 help browser bug and a fix
IIRC, I believe it's a change in syntax, so that 8.4 understands
Hi all,
Is there a way to declare a variable within a proc scope so that it can
be referenced later externally? e.g. having $name.something in
pdtk_canvas_new linked to a widget can be easily referenced later from
another function (e.g. this is how scrollbars work). However if I want
to declare a
Here are two patches for g_editor.c that fix following issues in 0.42.5:
1) undo recreates patch cords with wrong color (I posted this one
earlier by mistake on the pd-list)
2) graph on parent (GOP) enable and then immediately disable crashes
patches that haven't been closed prior to disabling
On Sat, 2009-10-31 at 13:39 -0400, Ivica Ico Bukvic wrote:
Here are two patches for g_editor.c that fix following issues in 0.42.5:
1) undo recreates patch cords with wrong color (I posted this one
earlier by mistake on the pd-list)
2) graph on parent (GOP) enable and then immediately
The following patch fixes jack auto-connect problem encountered on
Ubuntu 9.04.
Best wishes,
Ico
--- s_audio_jack.c 2009-10-29 19:57:33.0 -0400
+++ ../../../../pd-extended-svn/pd-extended/pd/src/s_audio_jack.c 2009-05-28 21:14:05.0 -0400
@@ -153,7 +153,7 @@ static char**
2) graph on parent (GOP) enable and then immediately disable crashes
patches that haven't been closed prior to disabling GOP (to reproduce,
open new patch-right-click-properties-enable gop-apply-disable
gop-apply-crash). This one may also affect pd vanilla (haven't
checked)
Looks
On Sat, 2009-10-31 at 17:18 -0400, Hans-Christoph Steiner wrote:
Hey Ivica,
I rewrote the scrollbar logic in 0.43 and its working well, as far as
I can tell. Have you tried it out? I think its a similar approach,
but the difference is that my code tries to keep things at 0,0 since
3) 0 0 coordinate-centric design IMHO does not make sense. From
historical perspective, old patches should still TTBOMK open just fine.
Yet, if 0 0 approach is still imposed, it results in unintuitive
behavior of scrollbars. e.g. try the following on 0.43 (or previous
versions without the
Hans and all,
Following is not the case with either 0.41.4 or 0.43.
Create a new patch-create a subpatch (e.g. [pd test]) which will
immediately open upon creation-close the main patch (with or without
saving)-crash. It happens consistently on my machine.
However, if one closes the subpatch
On Mon, 2009-11-02 at 09:24 -0500, Ivica Ico Bukvic wrote:
Hans and all,
Following is not the case with either 0.41.4 or 0.43.
Create a new patch-create a subpatch (e.g. [pd test]) which will
immediately open upon creation-close the main patch (with or without
saving)-crash. It happens
- when you select all and mouse drag components out of the current
view, Pd-extended updates scrollbars immediately, Pd and Pd-devel
update the scrollbars once you release the mouse, and Ico's gave me
an
error saying Error: can't read ::scroll(.x6d5610)
- when you resize the window,
OK, try the one below instead (with ::scroll call removed). Also, plase
don't forget to do the followign test with large graphics objects and
test scrollbar behavior:
1) create iemlib's number2
2) adjust its height to 60 and its font size to 50
3) drag it as far to the top as possible and what
Hi all,
In our recent troubleshooting trying to hunt down a mysterious crash at
patch closing we uncovered a bug that appears to be present in
pd-extended 0.41.4 and 0.42.5, as well as pd vanilla (svn checked out
yesterday). Following is reproducible on Linux 9.04 Ubuntu i386.
To reproduce the
As a follow-up to this problem, manually stopping metro before closing
the patch solves this problem, but that is not obviously the way to
ensure someone will remember to do so every time before closing...
Another correction. This problem is not apparent in pd-vanilla (even
though the source
Yay! Finally figured it out.
Please disregard my netsend patch, it's basically treating symptoms
rather than the source.
It turns out that the patch I submitted before to fix canvas GOP toggle
on/apply/off/apply crash has been the cause of the problem all along
mainly because the final version
Please see attached patch. it appears whenever there is change in the
gui of a closed sub-patch that has GOP sub-patch showing another GOP-ed
subpatch (try reading that aloud) the redraw is attempted resulting in
an error in a console. Probably the best thing is to test the attached
patch. The
All right. So, I've done some digging on this one and found out the
following:
The bug affects all versions of Pd and behaves even worse in 0.43
extended. Given that Pd is all about abstracting one's work, I would
consider this a high-priority bug.
Basically it has to do with having a
Never mind. Just found a regression on this patch (when you disable
gop,
stale objects do not get removed). I'll keep searching and report when
I
have something...
there are more GOP bugs than that. I have submitted one on SF recently.
After you're done with yours, I bet you'll find a
That's not a reason for removing it.
I never said it was. It was simply icing on the cake, if you like:
pd-extended exhibits a problem that pd-vanilla doesn't exactly because of
this one line. Namely, this is the culprit for profuse canvas errors every
time an object is updated that is visible
Why would it be the cleaner thing to do? It's not like simpler, smaller
commands are full of doorknob viruses. Tk has the commands on groups
of
items so that it acts on groups of items, I don't know why we're supposed
to avoid that feature and call it cleaner.
Because of the same reason why
Nov 2009, Ivica Ico Bukvic wrote:
There should be a loop that goes through all existing cords and checks
whether they are visible and if so, raises them. Otherwise, they should
be ignored.
Why would you need to loop through all existing cords?... I don't
understand.
You need to perform only
What's the one line?
Please see previous email.
Here's what I found, not being able to open the subpatch happens on
Pd
0.42.5 and Pd-extended 0.42.5-2009-1112, but not with pd-gui-rewrite/
0.43
Except you get a profuse number of errors that do not go away in console.
Ico
Should ?
Are my doublequotes being unsupported by your mailer? Iso-latin-1 (and
thus the first 256 chars of Unicode) support at least three doublequote
styles but it seems that mine (that look like miniature left-shift and
right-shift) get converted to other styles.
It could be my phone
and that would go a long way towards improving legibility, e.g.
all_present_objects.cords.visible.
What would that piece of code mean? how would you use it? how
would it fit
with a C-Tcl/Tk architecture? can it be expressed as C code naturally
enough?
Depends what you refer to as
This is IMHO the first valid argument against my suggested
implementation you made so far and one I would agree with.
This is because much of the rest was about peripheral issues such as what
you think of pd itself, what can be done about pd itself, and about the
wording you used against
So, if anyone is aware of the reason for its placement, it would be most
helpful to learn more about that before making the final decision
whether to keep/remove it.
Because objectboxes and messageboxes and atomboxes have
become opaque, so
the stacking order of wires does matter more.
I think we are confusing two things here, the whole pd.tk which does offer
Hans-Christoph Steiner h...@at.or.at wrote:
On Nov 18, 2009, at 10:47 AM, Ivica Ico Bukvic wrote:
Please see attached. This one should work seamlessly on pd-extended
0.42.5 with Linux (it has *not* been tested
of clarity, let us not discuss any
potential inclusion of pd.tk in this thread, as that clouds the matter at hand
which is the scrolling algorithm.
Cheers!
Ivica Ico Bukvic i...@vt.edu wrote:
I think we are confusing two things here, the whole pd.tk which does offer
I have been trying what you have been posting, but I haven't found a
clean patch or pd.tk.. The standard format for submitting code to
most open source projects is a diff -uw patch. That's the best way
to submit them if you want people to be able to read them, try them,
make sense
please see attached patch. it applies cleanly against 0.41.4
extended as
well as 0.42.5 extended.
ico
patch
It works for me Pd-extended 0.42.5-20091112, thanks for that. Sorry
for the delay, its been a busy week. Two things I tried:
- like the current Pd-extended scroll logic,
I guess I didn't understand the nature of that issue. I haven't seen
it. Tcl/Tk's bbox stuff seems to work with comments, do you mean
IEMGUI text?
.hc
Hans,
I really don't mean to be disrespectful but I am really getting frustrated
by the fact that you apparently do not read my emails at
I guessed that the attached patch illustrates the problem that you are
describing, but it seems to me that the current Pd-extended algorithm
and the Pd-vanilla algorithm get it right:
Labels for some reason seem to be more forgiving, but when you increase
font size enough, they get messed
this thing (e.g. using
gdb or other tools). If possible, I would appreciate verbose answers as I've
never delved into runtime debugging tools (beyond setting up verbose
checkpoints using stderr messages, which in this case appear not to be very
helpful).
Please advise.
Best wishes,
Ivica Ico
The problem is that Tcl/Tk is not the bottleneck when it comes to array
redrawing. Its how pd sends draw commands. Redrawing a big array
once
could result in literally 500KB of Tcl code generated by Pd and sent to
the GUI.
So whether you use Tcl/Tk, Qt, JUCE, or whatever, you'll have to
you mean in opengl?
Ico
João Pais jmmmp...@googlemail.com wrote:
I'm not a coder, but I could also give a sugestion, which I haven't tried
myself for lack of time: how about circumventing tcl/tk, by writing your
gui in gem? There was once a report that it's much faster - I can only say
it
Did you try the current GUI rewrite?
http://puredata.info/dev/PdGuiRewrite
.hc
Hi Hans,
Please allow me to chime in here for the sake of clarifying a few things about
this project.
First of all, allow me to state that I honestly appreciate all the efforts
being made in respect to the
I guess so (haven't that much experience with gem). only know that a
small
square with some data structures with geographical positions took at
least
10% cpu in my thinkpad. with gem it took nothing.
you mean in opengl?
I think this would then be probably done in vanilla OpenGL, not Gem.
I've done it in pd-extended. it's true, the initial step to do a full gui
will be a hassle, because you'll have to program the interface yourself.
but if that's done carefully, it should pay up afterwards.
The lingering question is whether you wish to encumber GPU with editor
interface (if
of continual data
changes/updates).
Could the slider be the potential culprit?
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept
It appears this is definitely linked to the amount of data exchanged
between Pd and Tcl/Tk and apparently sliders are relatively hungry
GUI-wise as their presence definitely increases frequency of this
occurence. What is particularly curious is the stderr feedback. The
moment gui loses ability to
2 more examples, but this time having nothing to do with pdtk_post but
with other commands overlapping (in this case both appear to be
truncated versions of 2 .x8d7b968.c). Something appears to be awful
wrong with the way these things are getting enqueued.
BTW, overclocking the laptop lowers the
OK, more investigation brings up the following (I am including
surrounding commands jut in case I missed something):
pdtk_ping
.x9c14968.c coords 9c19e40KNOB 126 105 133 105
.x9c14968.c itemconfigure 9c1edc0NUMBER -fill #00fc04 -text {0}
.x9c14968.c coords 9cfc848KNOB 666 106 673 106
.x9c14968.c
A couple more instances (this time apparently canvas+create and canvas
+-fill flag):
wrote 737 of 737
missing close-brace
wrong # coordinates: expected 0 or 4, got 5
bad option cre.x87260d8.c: must be addtag, bbox, bind, canvasx,
canvasy, cget, configure, coords, create, dchars, delete, dtag,
On Wed, 2010-03-17 at 16:38 -0400, Hans-Christoph Steiner wrote:
This kinds of sounds like the stuff we were dealing with in the pd-gui-
rewrite branch. Do you have a patch you are using to test this? Is
the word 'cre' always involved in these freak outs?
.hc
No, see my other replies.
I finally discovered the problem. It is not pd or pd-extended at all. It
appears that the original implementation of the wiimote object I based
l2ork's threaded version on was causing these issues as some of its
output was callback driven from the external cwiid library, rather than
being pushed
-Original Message-
From: Miller Puckette [mailto:mpuck...@imusic1.ucsd.edu]
Sent: Wednesday, March 17, 2010 10:26 PM
To: Ivica Ico Bukvic
Cc: Hans-Christoph Steiner; pd-dev@iem.at
Subject: Re: [PD-dev] more information on the gui getting stuck on 0.42.5
Hi Ivo -
It's unsafe
the next DSP tick,
that is to say, as soon as possible.
cheers
Miller
On Thu, Mar 18, 2010 at 12:04:13AM -0400, Ivica Ico Bukvic wrote:
-Original Message-
From: Miller Puckette [mailto:mpuck...@imusic1.ucsd.edu]
Sent: Wednesday, March 17, 2010 10:26 PM
To: Ivica Ico Bukvic
Cc
Speaking of clock_delay(), does every kind of output that is triggered
by something other than pd's tree traversal (e.g. incoming network
messages that are gathered by a separate thread, or messages triggered
by other libs) need to be sent through clock_delay() so that it occurs
within the right
Likewise, I noticed that netclient (maxlib) uses something called
sys_pollfn() call, is this safe?
Oops, I meant sys_addpollfn()...
Another question related to this. In the netclient.c (maxlib) there is
the following code excerpt:
/* get's called when connection has been made */
Another question related to this. In the netclient.c (maxlib) there is
the following code excerpt:
/* get's called when connection has been made */
static void netclient_tick(t_netclient *x)
{
outlet_float(x-x_outconnect, 1);
/* add pollfunction for checking
Cool! Many thanks for the clarification!
Best wishes,
Ico
Martin Peach martin.pe...@sympatico.ca wrote:
Ivica Ico Bukvic wrote:
Another question related to this. In the netclient.c (maxlib) there is
the following code excerpt:
/* get's called when connection has been made */
static
Cool! Thanks for all your help!
Best wishes,
Ico
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
://www.akustische-kunst.org/puredata/maxlib/ */
+/* */
+/* March 26 2010*/
+/* Additional fixes and improvements by Ivica Ico Bukvic i...@bukvic.net
source at http://www.akustische-kunst.org/puredata/maxlib*/
/* */
+/* March 26 2010*/
+/* Additional fixes and improvements by Ivica Ico
Speaking of tcpserver.c isn't the tcpserver_notify() function making an
unsafe outlet_float() call when it is being triggered by an external
event (disconnection) which can happen out-of-order and thus potentially
causing crashes?
Shouldn't this be wrapped also in a clock_delay()?
Best wishes,
if you quit Pd, the destructors are not properly called for externals.
this is a rather serious issue reported on the sf-tracker soome years(?)
ago, but a fix never made it into Pd proper.
Also, in this case I don't think this is the problem as the verbose output
shows that the free function
@@
return;
}
-/* broadcasts a message to all connected clients */
-static void tcpserver_broadcast(t_tcpserver *x, t_symbol *s, int argc, t_atom *argv)
+/* broadcasts messages to all clients */
+/* Ivica Ico Bukvic i...@bukvic.net 5/6/10 rewrote broadcast to be xrun-free */
+static void
)
-if (pd_checkobject(g-g_pd))
-{
+for (g = x-gl_list; g; g = g-g_next) {
+if (pd_checkobject(g-g_pd) != 0)
+ {
+ x-gl_goprect = 1;
+ break;
+ }
+ }
+ /* Ivica Ico Bukvic 5/16/10 i...@bukvic.net
All right, the following fixes scrolling on Linux once and for all. It
should be also wrapped in a way that does not disturb Win and OSX (even
though they are in a need of the same fix).
Please note the following applies to:
Linux/OSX/Windows
Pd 0.42.5 vanilla and extended
Tcl/Tk 8.4 8.5
On Tue, 2010-05-18 at 13:30 -0400, Ivica Ico Bukvic wrote:
All right, the following fixes scrolling on Linux once and for all. It
should be also wrapped in a way that does not disturb Win and OSX (even
though they are in a need of the same fix).
Please note the following applies to:
Linux
Please disregard this patch--i've discovered a few more fixes and will
be resubmitting shortly.
cheers!
ico
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
All,
As I put finishing touches on the improved scrolling algorithm, the last
object I just added to dynamic resizing of the scrollbars is the graph
object. After messing with it I discovered that it was very unstable and
am wondering what is its use given that its entire functionality is
OK, here's a complete patch that fixes most (all?) issues with scrolling
algorithm listed below.
Please note the following applies to:
Linux/OSX/Windows
Pd 0.42.5 vanilla and extended
Tcl/Tk 8.4 8.5
In addition to the detailed description provided in the previous email,
here's a list of fixes:
IOhannes,
I tried your version of tcpserver/client and it unfortunately shows no
improvement in our performance tests (16 wirelessly networked machines) with
latency spikes sometimes as high as 1-2 seconds. In addition, your iteration of
tcpserver/client suffers from the bugs that were fixed
*x_dumpbangout;
struct _coll *x_next;
+
+ //for thread-unsafe file i/o operations
+ //added by Ivica Ico Bukvic i...@vt.edu 9-24-2010
+ //http://disis.music.vt.edu http://l2ork.music.vt.edu
+ t_clock *x_clock;
+ t_clock *x_init; /* for initializing first dummy thread */
+ pthread_t unsafer_t
Oops, please use the attached patch instead.
Best wishes,
Ico
On Sat, 2010-09-25 at 12:36 -0400, Ivica Ico Bukvic wrote:
In hope to answer some of the questions I presented on the pd-list the
other day, attached is the patch (diff -u against pd-extended svn
0.42.5) that converts miXed
that would be I would greatly appreciate
your feedback.
Best wishes,
Ico
On Sat, 2010-09-25 at 20:05 -0400, Ivica Ico Bukvic wrote:
Oops, please use the attached patch instead.
Best wishes,
Ico
On Sat, 2010-09-25 at 12:36 -0400, Ivica Ico Bukvic wrote:
In hope to answer some of the questions
Many thanks for the explanation! What seems weird, however, is how divergent
time delta between repeats is. On Windows it is always around 30ms (at least on
my hardware) whereas on Linux it goes between 0, including 1.4ms and up to 50+.
Even when accounting for jitter between two events I
Indeed. However, does Linux's API allow for this?
_
From: Hans-Christoph Steiner [mailto:h...@at.or.at]
Sent: Sunday, October 10, 2010 6:26 PM
To: tim vets
Cc: Ivica Ico Bukvic; pd-l...@iem.at; martin.pe...@sympatico.ca; pd-dev@iem.at
Subject: Re: [PD] [PD-dev] odd key object
Hi all,
I have a real pickle in trying to debug Pd. Namely, when I grep-ed every
single instance of pdtk_canvas_getscroll and commented it out, it still
gets invoked somehow and I am at a loss how. I know it occurs as many
times as there are objects selected that have been moved (so it is
Never mind... My brain finally decided to get out of bed and join me in
my office... Apologies for spam...
On Thu, 2010-11-18 at 11:22 -0500, Ivica Ico Bukvic wrote:
Hi all,
I have a real pickle in trying to debug Pd. Namely, when I grep-ed every
single instance of pdtk_canvas_getscroll
Hi Mathieu,
This is a great advice! However, when adding blargh() function from the
gridflow.c inside the sys_vgui (s_inter.c) so that when the debug is on
it outptus a trace for each call, it appears it only manages to do one
level which is obviously the sys_vgui call itself. Why is it not able
in
0.42 would not apply to 0.43
.hc
On Nov 21, 2010, at 10:40 AM, Ivica Ico Bukvic wrote:
Hi Mathieu,
This is a great advice! However, when adding blargh() function from
the
gridflow.c inside the sys_vgui (s_inter.c) so that when the debug is
on
it outptus a trace for each call
On Sun, 2010-12-26 at 23:57 -0500, Ivica Ico Bukvic wrote:
it's declared as void, not static. extension is inherited from the
original code but is not cpp code, afaik.
Ico
Actually, I stand corrected. It is cpp and a simple extern C did the
trick. Now onto tracking segfaults
Hi all,
I guess subject says it all. For the sake of efficiency I am hoping to
detect whether an inlet is connected to anything and if so to perform
its signal-based operations. Otherwise, it should remain dormant. Is
there anything in the existing API that allows for this?
Many thanks!
Ico
Is there anything in the API that offers ability to detect when an array
has been changed and then act upon it? This would be quite useful when
using array as a multislider to change values. If there isn't I am
proposing providing an invisible send from array whenever it is changed
with the name
On Mon, 2010-12-27 at 17:16 +, Pedro Lopes wrote:
Here's my point of view:
1) Theres a million and one ways.
2) If an array is changed by some pd-internal probably you can track
that down in the changer patch, thus you can control and know it.
3) Array comparison (as Jack
On Mon, 2010-12-27 at 11:31 -0500, Martin Peach wrote:
I suppose I am getting it wrong as usual but I thought signal objects
only do computation when signals arrive at the inlets.
Martin
Not according to what I am getting when I create a bunch of phasor~
objects (unconnected to anything),
Please excuse cross-posting.
Dear friends and fellow FOSS enthusiasts,
It is my great pleasure to share with the community a belated Holiday
present :-) in a form of latest snapshot of L2Ork iteration of
Pure-Data. Better than ever, the latest version comes with the following
improvements:
Apologies for cross-posting.
20110101 snapshot now introduces code clean-ups including revamped
to-front and to-back algorithms which do not rely upon the
cut/paste/undo hack and thus do not affect any of the other objects on
canvas. Consequently, there is also addition of a special undo/redo
, in the spirit of Steve
Jobs' keynote speeches we've left the best for last. Stay tuned for more
exciting updates soon ;-)
For additional info on L2Ork, visit http://l2ork.music.vt.edu.
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia
All,
Couldn't this be solved simply by adding -O2 compilation flag to the
object, as per intel's document found at:
http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/win/compiler_f/fpops/common/fpops_reduce_denorm.htm
Any thoughts?
Ico
or concerns, please do not
hesitate to contact me.
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music
window (or the gop-ed patch unless it is open)
*Infinite undo
*Ability to draw red GOP rectangle
*Universal copy/paste should also resize the canvas as per original script?
*Consider making hslider and vslider capable of doing int data
Cheers!
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
I guess this is mainly for the Pd devs,
Jonathan and I have been working on trying to have patch close itself
through the script. However, even in the newest Pd the problem persists
in that if one invokes menuclose via patch it crashes pd. I suspect this
is because the closure happens while Pd is
://github.com/pd-projects/pd-l2ork
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Director, CCTAD
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231
I guess this is primarily for devs:
The title says it all. When pd starts up, it does 2 instances of
canvas_new() calls. More interestingly, it does not do canvas_free for
those two instances when closing pd, suggesting this is a memory leak.
So, what gives? Why does it create 2 invisible
They contain templates for arrays.
[; pd-_float vis 1; pd-_float_array vis 1 (
More interestingly, it does not do canvas_free for
those two instances when closing pd, suggesting this is a memory leak.
So, what gives? Why does it create 2 invisible canvases, what is their
function,
The OS releases all the memory allocated by the process when it
terminates, so no.
OK, however, in pd-l2ork I am currently building infinite undo which
will be a doubly-linked list linked to a canvas. So, if I am going to
instantiate it dynamically, once the program exits are all these dynamic
On Sun, 2011-12-11 at 14:27 -0500, Ivica Ico Bukvic wrote:
The OS releases all the memory allocated by the process when it
terminates, so no.
OK, however, in pd-l2ork I am currently building infinite undo which
will be a doubly-linked list linked to a canvas. So, if I am going
it does.
if it does not, file a bug report at your operating system.
I stand corrected. So, the next question is, is it considered good
coding practice to explicitly call destructors, or is this one of those
quod libet kinds of things?
Otherwise, why would we need
destructors in the
about the latest dev
snapshot knowing that it is currently unstable, try checking out the pd-l2ork
from the git repository. For a stable (albeit older) version you can always
visit the L2Ork website.
Cheers!
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound
_
From: Ivica Ico Bukvic [mailto:i...@vt.edu]
Sent: Tuesday, December 13, 2011 4:18 AM
To: Hans-Christoph Steiner; Jonathan Wilkes; Krzysztof Czaja; pd-dev
Subject: Re: [PD-dev] deadly leak
This problem has a series of fixes spread all across the code. It is not one
instance
OK,
So, I reenabled the workaround I had used before in pd-l2ork and all is well
again. But it still does use a workaround and an ugly one at that. Yet, that is
the *only* way I can see fixing this. The problem is essentially what I had
mentioned already cutting and undoing cutting a canvas
Mathieu Bouchard ma...@artengine.ca wrote:
Le 2011-12-14 à 10:15:00, Ivica Ico Bukvic a écrit :
So, the only way I can ensure in pd-l2ork that this never happens is
that I enable global variable in canvas_new making sure that pd_new
function is aware its next allocation is for a canvas. I
Greetings fellow FOSS/Audio enthusiasts,
It is my great pleasure to announce pd-l2ork 20111215 a.k.a. Holiday
release. In the latest version of Linux Laptop Orchestra's in-house
version of Pure-Data we've squashed a number of lingering bugs, as well
as added some exciting new features, including:
On Dec 16, 2011, at 11:41, Jonathan Wilkes jancs...@yahoo.com wrote:
- Original Message -
From: Ivica Ico Bukvic i...@vt.edu
To: pd-l...@iem.at; pd-dev@iem.at; l2ork-...@disis.music.vt.edu;
pik...@piksel.no; linux-audio-u...@lists.linuxaudio.org;
linux-audio-annou
1 - 100 of 106 matches
Mail list logo
