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-request@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).
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. This split is done at: https://github.com/monkeyswarm/MobMuPlat/blob/master/MobMuPlat-iOS/MobMuPlat...
- The "engine" patch is the patch that is actually opened by libpd and
generates audio. The processing replaces each gui object with a Pd abstraction I made (termed a "shim" in the code) that has a send/receive relationship (with an auto-generated handle) with the MobMuPlat- layer GUI code. So a line (this is the toggle in the "MMPExamples-NativeGUI.pd" file). #X obj 253 440 tgl 45 0 /demoToggleSend /demoToggleReceive I'm_using_send_and_receive becomes #X obj 253 440 MMPPdGuiFiles/MMPPdGuiShim 15-gui-send 15-gui-rec /demoToggleSend /demoToggleReceive; "15-gui-send" and "15-gui-receive" are the handles for send/receive with the user-visible gui object. Note that existing send/receive behavior is kept intact (with /demoToggleSend and /demoToggleReceive) There's a few flavors of this shim (in github.com/monkeyswarm/MobMuPlat/tree/master/MobMuPlat-iOS/MobMuPlat/PdGui): a main one for most GUI objects, a special one for a "bang", and a special one for a message object.
- The "GUI" patch is a simpler process, it just, for every GUI object,
sets the send/receive handles to the same auto-generated handles generated for the matching "engine" shim that should communicate with it. After processing, this pd patch is then read and rendered to native-app-layer GUI widgets.
I've tested this to work for using the "internal" (object property) send/receive labels, attaching to send/receive objects, using "set", one-to-many and many-to-one communication. However there's probably some use case I've overlooked (or some fun way to make it stack overflow when it shouldn't). Let me know...!
Separate questions for everyone:
- 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.)
- 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)
Thanks for input, Dan I.
On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox danomatika@gmail.com 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, pd-list-request@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).
On Jan 8, 2016, at 9:29 AM, Daniel Iglesia daniel.iglesia@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:
- 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 ...
- 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 <danomatika@gmail.com mailto:danomatika@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-request@lists.iem.at mailto:pd-list-request@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/
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 danomatika@gmail.com wrote:
On Jan 8, 2016, at 9:29 AM, Daniel Iglesia daniel.iglesia@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:
- 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 ...
- 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 danomatika@gmail.com 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, pd-list-request@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 robotcowboy.com
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.iglesia@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 <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
On Jan 8, 2016, at 9:29 AM, Daniel Iglesia <daniel.iglesia@gmail.com mailto:daniel.iglesia@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:
- 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 ...
- 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 <danomatika@gmail.com mailto:danomatika@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-request@lists.iem.at mailto:pd-list-request@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/
Also, if you’re using the PdParty PdParser class, I fixed a bug that was causing invalid sendnames: https://github.com/danomatika/PdParty/blob/master/src/classes/PdParser.m#L88
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Jan 8, 2016, at 10:20 AM, Dan Wilcox danomatika@gmail.com wrote:
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.iglesia@gmail.com mailto:daniel.iglesia@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 <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
On Jan 8, 2016, at 9:29 AM, Daniel Iglesia <daniel.iglesia@gmail.com mailto:daniel.iglesia@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:
- 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 ...
- 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 <danomatika@gmail.com mailto:danomatika@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-request@lists.iem.at mailto:pd-list-request@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/
-
Dan Wilcox -
Daniel Iglesia