I'm just having trouble with the specifics. Do you have an example of a patch
that suffers from Pd's current single-threaded implementation that would be
measurably improved by using a multi-threaded approach? Also, what is the
metric to use here?
To compare apples to apples, imagine that every g_* sourcefile has already been
moved to the GUI side of both the single- and double- threaded designs that are
being compared.
-Jonathan
On Sunday, February 23, 2014 12:30 AM, Rich E <reakina...@gmail.com> wrote:
On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
On 02/20/2014 09:50 PM, Rich E wrote:
>
>
>>
>>
>>On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
>>
>>On 02/18/2014 11:11 PM, Rich E wrote:
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomat...@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 <danomat...@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?
>
>
>
Firstly, I think the decision should at least be available (to process audio
and GUI on separate threads), since this is the most common way to handle the
two different update rates. Especially since, with most GUI frameworks, you
_must_ update the GUI on the main / UI thread, which is running at 60fps.
But to answer the question... drawback is having to manage the whole 'this
method must to be called on the audio thread, and that method must be called on
the non-audio thread'. However this turns out to be little of a limitation
since it is almost always what you want to do anyway, and you gain huge amounts
in the area of responsiveness.
In the end, every situation is different. With pd vanilla, audio is most
important and maybe that deserves the current architecture. To me, it is more
about keeping options open, which is why I think abstracting the visual
position from the core is a good idea.
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
