On 02/20/2014 09:50 PM, Rich E wrote:


On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes <jancsika@yahoo.com> wrote:
On 02/18/2014 11:11 PM, Rich E wrote:



On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomatika@gmail.com> wrote:
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right?

On Jan 13, 2014, at 5:14 PM, Dan Wilcox <danomatika@gmail.com> wrote:

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.



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).

You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime.


The GUI and audio shouldn't be updated from the same thread.  This is one nice thing about libpd, it forces a separation.

What are the drawbacks to the multi-threaded approach?  Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI?


So in this type of world, the GUI can do whatever it needs to do in order to draw at the desired framerate, and flags graph changes along the way.

In Pd-extended and Vanilla currently there is very little optimization to get the most out of Tk.  Those problems have a tendency to get lumped in with single-threadedness.  So if someone actually gets something with a better design up and running, just remember that you have to do similar optimization work before the benefits of the new system really start to shine.  Otherwise you'll get burned out when the right approach still gets dropouts-- from the odd inefficient algorithm, some "standard" widget that eats CPU for lunch, or whatever else isn't documented on the shiny frontpage of the toolkit.

-Jonathan

 The changes are then converted into a GUI-agnostic format and synchronously issued to the audio context.