inlet_new apparently redirects elsewhere, so one could potentially do
what list_append does (if I am understanding the code correctly), but is
there an easier way to do this?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Dire
Assuming you want a pulse in non-signal domain, you could use disis_phasor~
(see http://l2ork.music.vt.edu/main/?page_id=56 for download links) which
outputs a bang every time ramp is crossed. This is only accurate to the
nearest sigvs size (by default 64 bytes) as there is no guarantee that you
wi
anvas_free function:
-if (x->gl_magic_glass)
- magicGlass_free(x->gl_magic_glass);
+if (x->gl_magic_glass) {
+ //magicGlass_free(x->gl_magic_glass);
+pd_free(&x->gl_magic_glass->x_obj.te_g.g_pd);
+ }
=====
Best wishes,
--
if (x->gl_list == y) {
That rtext is never freed after that so unless I am missing something I
see no reason why we would want to do this. Any ideas?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Or
ess up the rest of the parser or is more or less trivial? I
spent a few minutes this afternoon studying code and am not yet sure if
this is something that may be too complicated to pull off quickly...
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound &a
t.edu/main/?page_id=56...
Enjoy!
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
Department of Music
Blacksburg, VA 24061-0240
(540) 231-
On Dec 16, 2011, at 11:41, Jonathan Wilkes wrote:
> - Original Message -
>
>> From: Ivica Ico Bukvic
>> 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
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:
> Deadly leak hits me, and my students, regularly and annoyingly when we
> are patching in a certain way.
>
> I don't know about other bugs. This one is really not as convoluted
> as you suggest -- its fatal consequences are, perhaps, but not the bug
> itself.
>
> The real source of the bug is
Mathieu Bouchard 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
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 obj
_
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 but
#x27;re curious 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 In
> 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
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.
> 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 dynami
> 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
> >
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 canvases
at:
https://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)
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
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
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 M
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
__
ted
with the new promotional materials and photos. Yet, 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
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
The last update of the year (20101230) fixes a few more bugs and
introduces a port of John Gibson's jg.spectdelay~, a frequency-based
delay/feedback/eq object.
> Latest snapshot is available from the usual place:
> http://l2ork.music.vt.edu/main/?page_id=56
>
> Complete changelog since 11/25/2010
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:
*impl
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
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 (
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 _c
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
__
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.
ic'.
>
> .hc
>
> On Dec 26, 2010, at 8:35 PM, Ivica Ico Bukvic wrote:
>
> > Hi all,
> >
> > I've taken a quick stab at trying to port John Gibson's spectdelay~
> > external from Max to Pd and got stuck at the following error:
&g
ctdelay_class, (t_method)spectdelay_hold_msg, gensym("hold"), A_GIMME, 0);
class_addmethod(spectdelay_class, (t_method)spectdelay_posteq_msg, gensym("posteq"), A_GIMME, 0);
class_addmethod(spectdelay_class, (t_method)spectdelay_maxdel_msg, gensym("maxdel"), A_GIMME, 0);
cla
n
>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
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 t
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_canv
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
definite
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 o
First of all, my apologies to all for x-posting of the original
matter--I did not realize there was such a major overlap in user base on
pd-list and pd-dev lists making my x-post truly redundant.
> since rPars can't be used by any other thread, you need to make a copy
> for each thread.
This mus
copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
// ===
// ChangeLog:
// 2008-04-1
_
From: tim vets [mailto:timv...@gmail.com]
Sent: Monday, September 27, 2010 1:21 PM
To: Ivica Ico Bukvic
Cc: martin.pe...@sympatico.ca; pd-l...@iem.at; pd-dev@iem.at
Subject: Re: [PD] [PD-dev] odd key object behavior under Linux
I got curious, so I did this little test with auto-repeated keys
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 cannot
In my recent troubleshooting saga dealing with xruns and coll object I
identified one rather odd behavior that apparently stems from the [key]
object.
It all started when I noticed that my threaded version of coll object
tended to freeze Pd at apparently random points. As it turns out, I was
testi
struct _coll *x_next;
+
+ //for thread-unsafe file i/o operations
+ //added by Ivica Ico Bukvic 9-24-2010
+ //http://disis.music.vt.edu http://l2ork.music.vt.edu
+ t_clock *x_clock;
+
+ pthread_t unsafe_t;
+ pthread_mutex_t unsafe_mutex;
+ pthread_cond_t unsafe_cond;
+
+ t_symbol *x_s;
+ t_int u
y 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:
&g
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 conve
*x_filebangout;
t_outlet *x_dumpbangout;
struct _coll *x_next;
+
+ //for thread-unsafe file i/o operations
+ //added by Ivica Ico Bukvic 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 */
+
-on-read-complete (as the coll does) even though it is
effectively running independently from the main thread without causing a major
ruckus inside Pd's internal interrupt/clock that deals with audio and gui
updates?
Any help is most appreciated.
Ivica Ico Bukvic, D.M.A.
Compositio
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 in
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:
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
essent
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
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 follo
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
Basica
if (pd_checkobject(&g->g_pd))
-{
-x->gl_goprect = 1;
-break;
-}
+ /* Ivica Ico Bukvic 5/16/10 */
+ x->gl_goprect = 1;
}
if (glist_isvisible(x) && x->gl_goprect)
glist_redraw(x);
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
g; g = g->g_next)
-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;
+ }
+ }
What is the status of this branch? Is it production ready?
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 M
7,242 @@
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 5/6/10 rewrote broadcast to be xrun-free */
+static
Martin,
If we could somehow wrap the broadcast call for the tcpserver in a separate
thread and minimize parsing redundancies to make it xrun-proof, I think this
object would be absolutely perfect for our needs. I am more than happy to
assist in this process if you could just please send me a br
This apparently also fixes the second bug. Yay!
On Wed, 2010-05-05 at 18:15 -0400, Ivica Ico Bukvic wrote:
> please see attached.
>
> tcpclient was spawning a new thread every time you pressed connect
> regardless whether you are connected or not. Hence, crashes.
>
> Still n
@@ -160,11 +160,15 @@
struct hostent *hp;
int sockfd;
+ /* Ivica Ico Bukvic
+ not necessary here any more as this is now checked
+ before the thread is spawned
if (x->x_fd >= 0)
{
error("%s_connect: already connecte
OK, two more bugs, first one being show-stopper at times totally
freezing Pd.
When a tcpclient is connected and then tcpserver mysteriously disappears
(e.g. it is cut from the patch or remote machine crashes) tcpclient
properly reports disconnect. However, if one connects tcpclient and then
presse
> Hmmm, I just tried this on WinXP and it works fine (Pd version
> 0.42.5-extended-20100411 but with the new tcpserver).
> I can even open multiple copies of the patch without errors or failure
> to create.
> I'll check later on a debian machine.
>
> Martin
I just noticed you patched the sourc
erns, please do not
hesitate to contact me.
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 - 0240
Blacksburg,
> 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 functio
> Ivica Ico Bukvic wrote:
> > Martin,
> >
> > Just tried the latest version and the problem with stuck port persists,
> > suggesting that either Ubuntu is doing something funny or that the
> > destructor is to blame.
> >
>
> if you quit Pd, the dest
Martin,
Just tried the latest version and the problem with stuck port persists,
suggesting that either Ubuntu is doing something funny or that the
destructor is to blame.
A simple test to perform is to use attached test patch:
1) Connect the client
2) Close the patch without explicitly disconnec
> OK, thanks for finding that. I fixed it in svn, the way it is written
> above will not set SO_REUSEADDR because the parameter is false (0).
> Also
> it was #ifdeffed out except for IRIX. You should try an autobuild from
> tomorrow.
I'll definitely try it out but I am not convinced this is the pr
ts number of connections and tends to crash,
almost as if it fails to properly detect disconnection.
Any ideas what might be the problem and whether any of these problems have been
addressed in the latest version?
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Direc
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,
I
* Get source at http://www.akustische-kunst.org/puredata/maxlib/ */
+/* */
+/* March 26 2010*/
+/* Additional fixes and improvements by Ivica Ico Bukv
://www.akustische-kunst.org/puredata/maxlib*/
/* */
+/* March 26 2010*/
+/* Additional fixes and improvements by Ivica Ico Bukvic*/
+/* for
Cool! Thanks for all your help!
Best wishes,
Ico
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Cool! Many thanks for the clarification!
Best wishes,
Ico
Martin Peach wrote:
>Ivica Ico Bukvic wrote:
>>>> Another question related to this. In the netclient.c (maxlib) there is
>>>> the following code excerpt:
>>>>
>>>>/* get's
> > 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 pollfunctio
> 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 */
sta
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 ti
k,
>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,
> -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
>
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"
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 repli
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, fi
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
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 l
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 s
minutes 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)
Virg
> 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
> 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, n
> 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 t
you mean in opengl?
Ico
João Pais 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 does if you're usin
> 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 ha
w to debug 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 wis
> 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 mess
> 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 email
> > please see attached patch. it applies cleanly against 0.41.4
> > extended as
> > well as 0.42.5 extended.
> >
> > ico
> >
>
> 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 sc
> 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
On Fri, 2009-11-27 at 22:15 -0500, Mathieu Bouchard wrote:
> On Fri, 27 Nov 2009, Hans-Christoph Steiner wrote:
>
> > FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so this
> > couldn't be included in vanilla since Miller wants to continue to support
> > 8.3, and it couldn't b
e sake 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 wrote:
>I think we are confusing two things here, the whole pd.tk which d
I think we are confusing two things here, the whole pd.tk which does offer
Hans-Christoph Steiner 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* b
1 - 100 of 134 matches
Mail list logo
