Woops, forgot the reply-all.
On 01/13/2014 09:32 AM, Dan Wilcox wrote:
As Hans has proposed for years, IMO this is really the only way to perhaps solve the "PD gui development doesn't move fast enough" problem in the long term. In this case, Miller would have the core (in libpd) & the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way.
Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core.
I wasn't referring to anything in particular, only in general.
#2 is hard. Where would you start and how would you proceed?
I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL.
I think by DSP core you're referring to:
* DSP graph stuff
* message dispatching system
* various widgetbehaviors and data structures parentwidgetbehaviors
* all the gui logic in g_editor.c
* gui queuing stuff, array selection/manipulation logic, mouse motion callbacks, and probably other things I'm forgetting
Is this correct?
Yes, minus the widgets and gui queuing stuff, etc. I'm talking about finding a way to separate the strictly gui stuff from the DSP graph. I recognize that some of that is required, so I'm trying to think pragmatically. Obviously you're a better judge of that as you have more experience with the code in the area.
In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, & processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc.
I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact?
Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it.