<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I would test the same patch you built. To tax tkpath and tk in
particular you can spread toggles to the four corners of the screen
since redrawing area calculation on those toolkits is fairly
inefficient. CPU spec and CPU overhead data would also help figure
out where the bottleneck lies. e.g. my experience is from a
low-powered AMD APU (essentially AMD's Atom counterpart).<br>
<br>
<div class="moz-cite-prefix">On 1/7/2016 11:52 AM, Jonathan Wilkes
wrote:<br>
</div>
<blockquote
cite="mid:1543112159.1659814.1452185569841.JavaMail.yahoo@mail.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff;
font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial,
Lucida Grande, sans-serif;font-size:16px">
<div id="yui_3_16_0_1_1452183579370_2890">Do you have a simple
patch to test?</div>
<div id="yui_3_16_0_1_1452183579370_2977"><br>
</div>
<div id="yui_3_16_0_1_1452183579370_2978">Not sure exactly
what's going on, but I can think of three relevant areas:</div>
<div dir="ltr" id="yui_3_16_0_1_1452183579370_3723">* node.js
APIs are largely built to be asynchronous</div>
<div id="yui_3_16_0_1_1452183579370_4324" dir="ltr">* V8
javascript engine does JIT compilation of hot code</div>
<div id="yui_3_16_0_1_1452183579370_4325" dir="ltr">* Chromium
goes out of its way to ensure that nothing blocks the renderer
from doing its job</div>
<br>
<div id="yui_3_16_0_1_1452183579370_4745" dir="ltr">Of course
advertisers don't have to pay for the CPU they consume on your
device, which <br>
</div>
<div dir="ltr">mean all browser-based technology are CPU hogs.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">-Jonathan<br>
</div>
<div id="yui_3_16_0_1_1452183579370_4744" dir="ltr"><br>
</div>
<div id="yui_3_16_0_1_1452183579370_4787" dir="ltr"><br>
</div>
<div id="yui_3_16_0_1_1452183579370_4369" dir="ltr"><br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
</div>
<div id="yui_3_16_0_1_1452183579370_2800"><span></span></div>
<div class="qtdSeparateBR"><br>
<br>
</div>
<div style="display: block;" class="yahoo_quoted">
<div style="font-family: HelveticaNeue, Helvetica Neue,
Helvetica, Arial, Lucida Grande, sans-serif; font-size:
16px;">
<div style="font-family: HelveticaNeue, Helvetica Neue,
Helvetica, Arial, Lucida Grande, sans-serif; font-size:
16px;">
<div dir="ltr"><font size="2" face="Arial"> On Thursday,
January 7, 2016 11:19 AM, Ivica Ico Bukvic
<a class="moz-txt-link-rfc2396E" href="mailto:ico@vt.edu"><ico@vt.edu></a> wrote:<br>
</font></div>
<br>
<br>
<div class="y_msg_container">
<div id="yiv5554064119">
<div> Would you please test the same on pd-l2ork
and/or vanilla? If there is a stark difference, this
may suggest that node webkit does some kind of
internal event pruning (which would be really
sweet). Also, checking CPU overhead may help shed
some light as to what is going on. Finally, what are
the specs of your machine?<br clear="none">
<br clear="none">
<div class="yiv5554064119yqt6963339203"
id="yiv5554064119yqt18966">
<div class="yiv5554064119moz-cite-prefix">On
1/7/2016 2:20 AM, Jonathan Wilkes wrote:<br
clear="none">
</div>
<blockquote type="cite">
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica Neue, Helvetica, Arial, Lucida
Grande, sans-serif;font-size:16px;">
<div id="yiv5554064119">
<div
id="yiv5554064119yui_3_16_0_1_1452148600145_2615">
<div
id="yiv5554064119yui_3_16_0_1_1452148600145_2614"
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica Neue, Helvetica, Arial, Lucida
Grande, sans-serif;font-size:16px;">
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4266">In
the GUI port I hooked up about 14
toggles to a [metro 1] and was getting
<br clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4369">anywhere
between 30 and 40 fps in the GUI. I
could continue creating new <br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4451">objects
in the same patch.</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4453"><br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4455">Now
if I connected each of those toggles
to a [print] I'd probably freeze the <br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4457">GUI.
But I'm not doing any optimization on
console, nor limiting the <br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4500">size
of the scrollback buffer. (I am,
however, displaying a hit count beside
<br clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4569">duplicate
messages which cuts down immensely on
noise.)</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4604"><br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4657">At
least for now, if some common patch
behavior is able to DOS the <br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_5229">GUI
I'd rather have it freeze up as an
incentive to fix the underlying
problem.</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_5518"><br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_5233">-Jonathan<br
clear="none">
</div>
<div dir="ltr"
id="yiv5554064119yui_3_16_0_1_1452148600145_4605"><br
clear="none">
</div>
<div
id="yiv5554064119yui_3_16_0_1_1452148600145_5235"><br
clear="none">
</div>
<div><br clear="none">
</div>
</div>
</div>
</div>
<div>
<div style="font-family:HelveticaNeue,
Helvetica Neue, Helvetica, Arial, Lucida
Grande, sans-serif;font-size:16px;">
<div style="font-family:HelveticaNeue,
Helvetica Neue, Helvetica, Arial, Lucida
Grande, sans-serif;font-size:16px;">
<div dir="ltr"><font size="2"
face="Arial"> On Wednesday, January
6, 2016 1:07 PM, Ivica Bukvic <a
moz-do-not-send="true"
rel="nofollow" shape="rect"
class="yiv5554064119moz-txt-link-rfc2396E"
ymailto="mailto:ico@vt.edu"
target="_blank"
href="mailto:ico@vt.edu"><a class="moz-txt-link-rfc2396E" href="mailto:ico@vt.edu"><ico@vt.edu></a></a>
wrote:<br clear="none">
</font></div>
<br clear="none">
<br clear="none">
<div
class="yiv5554064119y_msg_container">
<div id="yiv5554064119">
<div>
<div dir="ltr">Create a metronome
with less than 2 milliseconds
clock and connect it to a bunch
of toggles, turn it on, and
enjoy interacting with a barely
responsive gui. The same is
achievable with a less dubious
implementation where a graphical
user interface simply has a lot
of concurrently animated
components.</div>
<div dir="ltr">NB: depending on
your computer specs the two
millisecond threshold may have
to be set lower.</div>
<div dir="ltr">-- <br clear="none">
Ivica Ico Bukvic, D.M.A.<br
clear="none">
Associate Professor<br
clear="none">
Computer Music<br clear="none">
ICAT Senior Fellow<br
clear="none">
Director -- DISIS, L2Ork<br
clear="none">
Virginia Tech<br clear="none">
School of Performing Arts – 0141<br
clear="none">
Blacksburg, VA 24061<br
clear="none">
(540) 231-6139<br clear="none">
<a moz-do-not-send="true"
rel="nofollow" shape="rect"
ymailto="mailto:ico@vt.edu"
target="_blank"
href="mailto:ico@vt.edu">ico@vt.edu</a><br
clear="none">
<a moz-do-not-send="true"
rel="nofollow" shape="rect"
target="_blank"
href="http://www.performingarts.vt.edu/">www.performingarts.vt.edu</a><br
clear="none">
<a moz-do-not-send="true"
rel="nofollow" shape="rect"
target="_blank"
href="http://disis.icat.vt.edu/">disis.icat.vt.edu</a><br
clear="none">
<a moz-do-not-send="true"
rel="nofollow" shape="rect"
target="_blank"
href="http://l2ork.icat.vt.edu/">l2ork.icat.vt.edu</a><br
clear="none">
<a moz-do-not-send="true"
rel="nofollow" shape="rect"
target="_blank"
href="http://ico.bukvic.net/">ico.bukvic.net</a></div>
<div
class="yiv5554064119qtdSeparateBR"><br
clear="none">
<br clear="none">
</div>
<div
class="yiv5554064119yqt0456417139"
id="yiv5554064119yqt13301">
<div
class="yiv5554064119gmail_quote">On
Jan 6, 2016 9:31 AM, "Jonathan
Wilkes" <<a
moz-do-not-send="true"
rel="nofollow" shape="rect"
class="yiv5554064119moz-txt-link-abbreviated"
ymailto="mailto:jancsika@yahoo.com"
target="_blank"
href="mailto:jancsika@yahoo.com"><a class="moz-txt-link-abbreviated" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a></a>>
wrote:<br clear="none">
<blockquote
class="yiv5554064119gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex;">
<div>
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica Neue,
Helvetica, Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>
<div>
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica Neue,
Helvetica, Arial,
Lucida Grande,
sans-serif;font-size:16px;">
<div><span></span></div>
<div>
<div>Are there
more than two
people (matju
and Miller)
who understand
the <br
clear="none">
</div>
<div>_current_
design?</div>
<div><br
clear="none">
</div>
<div>-Jonathan<br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
</div>
</div>
</div>
</div>
<div>
<div
style="font-family:HelveticaNeue,
Helvetica Neue,
Helvetica, Arial,
Lucida Grande,
sans-serif;font-size:16px;">
<div
style="font-family:HelveticaNeue,
Helvetica Neue,
Helvetica, Arial,
Lucida Grande,
sans-serif;font-size:16px;">
<div dir="ltr"><font
size="2"
face="Arial">
On Wednesday,
January 6,
2016 12:00 AM,
Ivica Ico
Bukvic <<a
moz-do-not-send="true" rel="nofollow" shape="rect"
class="yiv5554064119moz-txt-link-abbreviated"
ymailto="mailto:ico@vt.edu" target="_blank" href="mailto:ico@vt.edu"><a class="moz-txt-link-abbreviated" href="mailto:ico@vt.edu">ico@vt.edu</a></a>>
wrote:<br
clear="none">
</font></div>
<br clear="none">
<br clear="none">
<div>
<div>
<div> The
following is
going somewhat
OT but
nonetheless
based on this
very
interesting
topic:
application
framerate is
no more
deterministic
than the
proposed idea.
Just because
monitor
refreshes at
60Hz doesn't
mean the app
will do the
same or
consistently.
Yet, pegging
GUI updates at
60Hz (think
speedlim-like
behavior)
despite all
the loose ends
will
undoubtedly
provide
improved
responsiveness
over a GUI
where one can
send
sub-millisecond
change
requests, most
of which will
never see the
light of the
day, despite
eating up tons
of CPU and in
all likelihood
bringing it
down to its
knees.<br
clear="none">
<br
clear="none">
<div>
<div>On
1/4/2016 9:32
PM, Jonathan
Wilkes wrote:<br
clear="none">
</div>
<blockquote
type="cite">
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>
<div>
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>
<div>
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>Having an
animation
method allows
GUI-side
optimizations
that aren't <br
clear="none">
</div>
<div dir="ltr">possible
when the
animation is
smeared across
the
socket/parser/eval'er.</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">Determinism:
GUI rendering
isn't
deterministic,
at least not
in the way
Pd's <br
clear="none">
</div>
<div dir="ltr">scheduler
is. For
example, how
could the GUI
(tcl/tk or
otherwise)
even <br
clear="none">
</div>
<div dir="ltr">know
that it missed
a deadline?<br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div>I guess
the simple API
I'm toying
with is
"stretching
the accordion"
so to <br
clear="none">
</div>
<div dir="ltr">speak,
and
potentially
showing the
cracks more
explicitly
with a longer
<br
clear="none">
</div>
<div dir="ltr">running
animation than
can currently
be seen in
Pd's GUI. But
that can be <br
clear="none">
</div>
<div dir="ltr">remedied,
either by
recursively
halving a
single
animation into
smaller ones,
<br
clear="none">
</div>
<div dir="ltr">or
just giving up
and using
[line].<br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">The
greater
benefit is
that more
elegant types
of visual
feedback
become <br
clear="none">
</div>
<div dir="ltr">possible
without being
discarded out
of hand due to
their
potential for
<br
clear="none">
</div>
<div dir="ltr">audio
interruption.</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">-Jonathan<br
clear="none">
</div>
<div><br
clear="none">
</div>
</div>
</div>
</div>
<div>
<div>
<div
style="font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div
style="font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div dir="ltr"><font
size="2"
face="Arial">
On Monday,
January 4,
2016 5:20 PM,
Ivica Ico
Bukvic <a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
class="yiv5554064119moz-txt-link-rfc2396E"
ymailto="mailto:ico@vt.edu" target="_blank" href="mailto:ico@vt.edu"><a class="moz-txt-link-rfc2396E" href="mailto:ico@vt.edu"><ico@vt.edu></a></a>
wrote:<br
clear="none">
</font></div>
<br
clear="none">
<br
clear="none">
<div>
<div>
<div> On
1/3/2016 3:24
PM, Jonathan
Wilkes wrote:<br
clear="none">
<blockquote
type="cite">
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>
<div>
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>It's
actually way
more
simplistic
than that--
just an
"animate"
method that <br
clear="none">
</div>
<div dir="ltr">wraps
around
whatever
attribute is
available to
the drawing
command. All
<br
clear="none">
</div>
<div dir="ltr">I'll
have is a ramp
time, an
optional delay
time, and an
optional
easing curve.
<br
clear="none">
</div>
<div dir="ltr">That
will make it a
bit like a
[vline~] for
GUI side
animation.</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">I'm
using the web
animations API
because it
makes things
very simple,
even <br
clear="none">
</div>
<div dir="ltr">to
do complex
things like
animating path
data.</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">The
idea is that
this would
open up some
modest
visualization
opportunities
<br
clear="none">
</div>
<div dir="ltr">that
are otherwise
too cpu
intensive.
For example,
if you're
animating <br
clear="none">
</div>
<div dir="ltr">using
[line] the
socket
messages can
quickly get in
the way of the
audio.<br
clear="none">
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br
clear="none">
Will you at
some point
drown the CPU?
Sure, but that
is no
different than
a million of
other ways of
doing the
same. OTOH,
implementing
the animation
this way helps
you ensure
that your
animation
remains in
sync with the
audio, which
to me seems
much better
gain than a
potential
CPU/socket
overhead may
be a
shortcoming.<br
clear="none">
<br
clear="none">
There could be
some very cool
ways of
filtering gui
messages, as
well (short of
getting rid of
the
socket-based
communication
in favor of a
shared
memory/multithreaded
design). For
instance, your
animation
object could
be given the
screen refresh
rate and
therefore it
would not send
out a message
via a socket
unless a
desired
frame-worth of
time has
transpired
since the last
message was
sent. This
would do
wonders not
just in terms
of animation,
but also the
overall gui
responsiveness,
if implemented
system-wide.<br
clear="none">
<br
clear="none">
Best,<br
clear="none">
<br
clear="none">
Ico
<div><br
clear="none">
<br
clear="none">
<blockquote
type="cite">
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>
<div>
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">-Jonathan<br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div><span></span></div>
<div><br
clear="none">
<br
clear="none">
</div>
</div>
</div>
</div>
<div>
<div
style="font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div
style="font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div><br
clear="none">
<br
clear="none">
</div>
<div>
<div dir="ltr"><font
size="2"
face="Arial">
On Sunday,
January 3,
2016 1:08 PM,
Ivica Ico
Bukvic <a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
class="yiv5554064119moz-txt-link-rfc2396E"
ymailto="mailto:ico@vt.edu" target="_blank" href="mailto:ico@vt.edu"><a class="moz-txt-link-rfc2396E" href="mailto:ico@vt.edu"><ico@vt.edu></a></a>
wrote:<br
clear="none">
</font></div>
<br
clear="none">
<br
clear="none">
<div>
<div>
<div> I think
it may make
sense in
addition to
having a
one-shot-independent
animations
that have no
guarantee of
staying in
sync with the
audio (e.g.
these could be
useful for
mouse-over
button
animations)
that your
animation
object can
also receive a
decimal value
between its
originator and
destination,
allowing for
each keyframe
to be a whole
number. So,
0-1 would
interpolate
between the
starting state
and first
keyframe, 1-2
between first
and second
keyframes,
etc., and thus
allow pd to
use its timing
mechanism to
project
changes in
animation
state via a
line object, a
counter or
something
similar. IIRC
most (all?)
HTML5-based
animations can
be triggered
as independent
events or can
be given a
specific
percentage
value. The
one-shot
object could
interact with
independent
events, while
the proposed
object could
interact with
the latter.<br
clear="none">
<br
clear="none">
That said, not
knowing how
you have
imagined your
animation
object, it may
be tricky to
implement this
as it would
require object
to keep track
of all the
keyframed
events
(assuming
there are more
than one). If
you are
thinking of
having the
animation
object track
only one
single
animation
(e.g.
something
progressing
from 30% to
90%), the same
could still
prove useful
except in this
case you would
only allow for
values between
0 and 1.<br
clear="none">
<br
clear="none">
<div>
<div>On
1/2/2016 1:12
PM, Jonathan
Wilkes via
Pd-list wrote:<br
clear="none">
</div>
<blockquote
type="cite">
<div
style="color:#000;background-color:#fff;font-family:HelveticaNeue,
Helvetica
Neue,
Helvetica,
Arial, Lucida
Grande,
sans-serif;font-size:16px;">
<div>Hi list,</div>
<div>I'm
playing with
adding a
simple
animation api
to data
structure
drawing
commands. <br
clear="none">
</div>
<div>The
parameters
will be sent
to the GUI,
and the GUI
will take care
of the ramp,
delay, etc.</div>
<div><br
clear="none">
</div>
<div>I'm
thinking of
just making it
a simple "set
it and forget
it" api. That
is, you send a
message <br
clear="none">
</div>
<div dir="ltr">with
your ramp and
delay times to
the GUI, and
you just
blindly trust
that the GUI
will make <br
clear="none">
</div>
<div dir="ltr">things
happen in the
right amount
of time. The
alternative I
can think of
is to have the
GUI <br
clear="none">
</div>
<div dir="ltr">call
back when an
animation is
finished, but
that would
encourage
mixing the two
clocks <br
clear="none">
</div>
<div dir="ltr">(i.e.,
GUI and Pd
clock) in
unpredictable
<br
clear="none">
</div>
<div dir="ltr">ways.</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">Does
this simple
approach seem
like a
reasonable
design? The
biggest
problem would
be that <br
clear="none">
</div>
<div dir="ltr">a
long-running
animation
could skew.
But in that
case you could
probably
amortize the
cost of</div>
<div dir="ltr">sending
more messages
over the
longer time
period.<br
clear="none">
</div>
<div dir="ltr"><br
clear="none">
</div>
<div dir="ltr">-Jonathan<br
clear="none">
</div>
</div>
<br
clear="none">
<fieldset></fieldset>
<br
clear="none">
<pre>_______________________________________________
<a moz-do-not-send="true" rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a moz-do-not-send="true" rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</div>
<br
clear="none">
</div>
</div>
<br
clear="none">
<div>_______________________________________________<br
clear="none">
<a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
class="yiv5554064119moz-txt-link-abbreviated"
ymailto="mailto:Pd-list@lists.iem.at" target="_blank"
href="mailto:Pd-list@lists.iem.at"><a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a></a>
mailing list<br
clear="none">
UNSUBSCRIBE
and
account-management
-> <a
moz-do-not-send="true"
rel="nofollow"
shape="rect"
class="yiv5554064119moz-txt-link-freetext"
target="_blank" href="http://lists.puredata.info/listinfo/pd-list"><a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a></a><br
clear="none">
</div>
<br
clear="none">
<br
clear="none">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br
clear="none">
</div>
</div>
</div>
<br
clear="none">
<br
clear="none">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br
clear="none">
</div>
</div>
<br clear="none">
<br clear="none">
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br clear="none">
<br clear="none">
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br clear="none">
</div>
</div>
<br>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>