I am using submodules for the PDParty objects for all GUI classes. The only copy-paste was Gui.h/m, which I changed significantly...
On Fri, Jan 8, 2016 at 8:52 AM, Dan Wilcox <[email protected]> wrote: > > On Jan 8, 2016, at 9:29 AM, Daniel Iglesia <[email protected]> > wrote: > > I'm glad you asked! It's done in a slightly convoluted, potentially > fragile, possibly un-scalable way. > > When a user loads a .pd file, pre-proccessing is done on the .pd text to > generate _two_ new .pd files, one for execution, and one for display The > two communicate with each other. > > > I thought it might be done that way. Does sound knife-edge :) I think it’s > not too conceptually difficult to work with send-receives, plus it makes it > easier to stream data from the device int Pd on your laptop while > developing. > > We could work out a way to make the PdParty objects more extensible so you > could use the iem implementations as well. This can be included with > separating the PdParty UI from the Core and pd gui implementations. SO > Submodule instead of copy/paste classes (I could use any bug finding help > as well!) > > Separate questions for everyone: > 1) you may notice that the current version does not render connection > lines. While the patch text lists all the connections (and inlet/outlet > indices for them), the app doesn't know how many inlets/outlets each object > has. I haven't delved too deeply for it yet, but is there an interface > somewhere that will return that information? e.g. here's an atom line for > an object and its parameters, tell me how many inlets/outlets. If so, then > connection lines could be rendered correctly. (Without it, I could still > render conneciton lines, but if there are empty inlets/outlets after a > connection then they would not be shown.) > > > I stayed away from connection lines mainly because trying to implement > “editing” is perhaps an unreasonable task for a single, unpaid developer. > Drawing the lines brings that expectation, no? ALso, since I’m using > sends/receievs there are no lines to render anyway ... > > 2) Is showing the full set of patch objects (and, eventually, connection > lines) even desirable? (Rather than just rendering the gui objects). I'm > thinking of an option that would switch their display on/off. (But leave > GUI objects, including message boxes) > > > Mmm that implies, as I’ve written above, that people can “edit” in > MobMuPlat. > > Thanks for input, Dan I. > > On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox <[email protected]> wrote: > >> How are you doing this? >> >> -------- >> Dan Wilcox >> @danomatika <https://twitter.com/danomatika> >> danomatika.com >> robotcowboy.com >> >> On Jan 7, 2016, at 9:19 AM, [email protected] wrote: >> >> - Unlike PdParty/PdDroidParty, you don't need to define send/receive >> values for every GUI object. Just drop in your PureData patch, with normal >> object connections, and it should work. (send/receive communication should >> also still work as well). >> >> > -------- > Dan Wilcox > @danomatika <https://twitter.com/danomatika> > danomatika.com > robotcowboy.com > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
