Ah ok. I just quickly looked at the link you sent. I can change Gui so it only 
loads the vanilla UIs by default and move the scene-specific stuff into the 
Scene class, for instance.

--------
Dan Wilcox
@danomatika <https://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Jan 8, 2016, at 10:18 AM, Daniel Iglesia <daniel.igle...@gmail.com> wrote:
> 
> 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 <danomat...@gmail.com 
> <mailto:danomat...@gmail.com>> wrote:
> 
>> On Jan 8, 2016, at 9:29 AM, Daniel Iglesia <daniel.igle...@gmail.com 
>> <mailto:daniel.igle...@gmail.com>> 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 <danomat...@gmail.com 
>> <mailto:danomat...@gmail.com>> wrote:
>> How are you doing this?
>> 
>> --------
>> Dan Wilcox
>> @danomatika <https://twitter.com/danomatika>
>> danomatika.com <http://danomatika.com/>
>> robotcowboy.com <http://robotcowboy.com/>
>>> On Jan 7, 2016, at 9:19 AM, pd-list-requ...@lists.iem.at 
>>> <mailto:pd-list-requ...@lists.iem.at> 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 <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
> 

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to