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.
On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <jancs...@yahoo.com> 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. 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. Conceptually, I know the tcl/tk-ism for the canvas, object positions, etc are fully baked into how everything works and I don't see a reason to try and change that. Again, perhaps the easiest method would be formalize those conventions via function wrappers which work 1-1 within the existing tcl/tk gui but perhaps require some adaptation for other gui frameworks. In other words, trying to find the least intrusive way to do this as I believe Martin has already done with the existing work in libpd. I truly respect Miller's work with Pure Data and understand the need to move slowly to maintain the highest possible backwards compatibility with all existing computer music pieces made in Pure Data. So far libpd has proven we can abstract some of the Pd core functionality without affecting Pd-vanilla, so I think it's possible to look for the next steps. The recent point of not being able to run GEM & an audio heavy patch on the same pd instance is really not a fault of the core but of the gui implementation. I have used libpd within OpenFrameworks for a number of computer vision + sound apps so I know it's definitely possible. Again, I'm only theorizing. I'm pretty familiar with how the iem guis are coded after emulating them in ObjC for PdParty, but I haven't delved into the nit and grit of the core yet. At least I can say now that the paradigms make more sense. As reference, last summer I updated some pretty hairy C code in RTCmix so that it would build as a library on Windows in MinGW: https://github.com/CreativeInquiry/RTcmix I have access to a triple boot machine to test code on Win/Mac/Linux which I regular use for OpenFrameworks work. So if I seriously gave this a shot, it wouldn't be a "look, it works on my machine, but I haven't tried it on OS A, B, ...". -------- Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
