<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/18/2014 11:11 PM, Rich E wrote:<br>
</div>
<blockquote
cite="mid:CA+vnWEja9mJpVLoTJ+pDvD9ixw-RCg_uH-bMbJA2g5eAzXnA7g@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Jan 13, 2014 at 5:35 PM, Dan
Wilcox <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:danomatika@gmail.com" target="_blank">danomatika@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Ah wait, duh. Of course
the graph needs to know positioning, that's how it
determines execution order or independent blocks of
objects right?
<div class="">
<div><br>
<div>
<div>On Jan 13, 2014, at 5:14 PM, Dan Wilcox <<a
moz-do-not-send="true"
href="mailto:danomatika@gmail.com"
target="_blank">danomatika@gmail.com</a>>
wrote:</div>
<br>
<blockquote type="cite"><span
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Does
the dsp graph rely on positioning? I thought
only via connections. I'd imagine the gui
wrapper should only worry about positioning
and simply update those changes when saving.</span></blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>IMO a separation between GUI and core could/would
include position, e.g. objects have their connections
mapped by an index, GUI assigns the index to the object
based on position. This would allow for some much more
sophisticated GUI's, such as 3d, or even a more
human-readable text version (json has been mentioned).</div>
</div>
</div>
</div>
</blockquote>
<br>
You run into problems when you want to get decent GUI interaction
_and_ expect to deliver audio to the soundcard in realtime.<br>
<br>
Actually even in 2d without audio the problems manifest themselves
pretty quickly. For example: open the svg tiger inside Inkscape and
move it around. Notice the clever trick-- the image is broken into
tiles and moved starting with the pieces closest to the mouse.
Since the user's eye focuses on the mouse pointer, the interaction
looks snappy even though it may take half a second or more to finish
moving the tile furthest from the pointer.<br>
<br>
When you add realtime audio the options are either to err on the
side of sluggishness or to be responsive and risk dropouts. If you
want it to be responsive in both video and audio then you have to
start doing some serious optimizations based on what you think the
user cases are for the software. For example, the Inkscape trick is
perfect for creating and manipulating vector graphics, but it would
be terrible for a 2d animation environment where you'd presumably
want the tiger to move as a single unit.<br>
<br>
However, many of Pd's current problems don't have a lot to do with
that. Tk is pretty good at being sluggish and avoiding dropouts
when it doesn't have idle time to do graphics updates. In fact I
can move around an svg tiger on a canvas without interrupting the
"test audio" patch. Most dropouts related to the GUI have to do
with what amounts to a DDOS attack from the core to the GUI. When
you flood tcl with data from the socket it can't really do anything
else but spend time receiving it. When you add that to whatever Pd
core is doing to generate all those messages in the first place, you
probably won't have any time left over for delivering audio.<br>
<br>
Other toolkits are certainly more efficient than Tk. But if you're
dragging an antialiased wire from the top left of the window to the
bottom-right, the toolkit needs time to do those redraws.<br>
<br>
Finally, I'm not really sure how Open-GL and hardware acceleration
plays into all this. For example, Qt Graphics View docs have a note
about accelerated graphics possibly adding a performance hit and
possibly more latency, but it's only in the context of hardware that
doesn't do floating point computations efficiently. I played around
with Kivy a bit, which is hardware accelerated but honestly didn't
see much of an improvement in cpu usage over comparable stuff in
Tkpath.<br>
<br>
-Jonathan<br>
<br>
<blockquote
cite="mid:CA+vnWEja9mJpVLoTJ+pDvD9ixw-RCg_uH-bMbJA2g5eAzXnA7g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>cheers,</div>
<div>Rich</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>