Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes <[email protected]> wrote:
> 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. >> >> On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <[email protected]> wrote: >> >>> #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. -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
