<div dir="ltr"><div><div><div>Thanks for this Chris, Have yet to try out pd-ws but it might be a bit simpler for me to plug in place of Nicolas' websockets<br></div><div>for my browser interface to xensynth<br><br> <a href="https://ia601201.us.archive.org/34/items/xensynth/xesynthcontrol/xensynthcontrol.html">https://ia601201.us.archive.org/34/items/xensynth/xesynthcontrol/xensynthcontrol.html</a><br><br></div><div>xensynthcontrol.html is  just a bunch of high level stuff that was easier to do with html javascript than patching up in pd , <br>however it's a vital part of my music making when selecting a scale or mode and  generating a Moments of Symmetry <br>beatmap for my sequencer.Looks like it will be  good to replace JAVA's tcp/udp sockets since JAVA is no longer supported <br>by major web browsers.<br></div><div>video here <br><a href="https://archive.org/details/xensynthnetworkcontrol">https://archive.org/details/xensynthnetworkcontrol</a><br><br></div></div>Was getting antsy about a solution, am still kind of iffy because JAVA worked for so long and the end of mozilla's support<br> is the end of this month supposedly. JAVA applets were the only cross platform solution to sockets from browser to pd <br></div>as far as I knew. Will websockets last as long as JAVA applets did? <a href="https://support.mozilla.org/en-US/questions/1216281">https://support.mozilla.org/en-US/questions/1216281</a><br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 20, 2018 at 1:13 AM, Chris McCormick <span dir="ltr"><<a href="mailto:chris@mccormick.cx" target="_blank">chris@mccormick.cx</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20/03/18 05:29, Dan Wilcox wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The "GUI faking" works at the moment and it's fast. I'm less inclined to believe adding a webbrowser layer and in-app socket communication is going to be performant on mobile devices.<br>
</blockquote>
<br></span>
There's no need to add in-app socket communication. The "server" runs inside Pd itself.<br>
<br>
The change to the app would look like this in psuedo-code:<br>
<br>
if "index.html" in patch folder:<br>
  instantiate WKWebView with index.html loaded<br>
else:<br>
  instantiate existing pd[droid]party GUI view<br>
<br>
The existing Pd[Droid]Party apps would function exactly as they do now, except for the additional option of using a webkit window in place of the existing patch viewer.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even if we have 100 Ghz, native (iOS CoreGraphics, etc) will still be faster.<br>
</blockquote>
<br></span>
That's true.<br>
<br>
A Pd person might be willing to make the trade-off, taking a performance hit for the superpower of rich web based user interfaces. I like the idea of people having that option and I don't think it detracts from anything in the existing Pd ecosystem.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What I *really* want is to simply ditch the GUI implementations and receive drawing commands directly from Pd. It could be "line here, rectangle there, text here" as it is now or it could be higher level as in "toggle here, object there" etc. If there was an abstraction layer replacing the TCL (maybe it looks/works like TCL in the end) wrapping the GUI, it would simply be easier to let Pd itself handle the logic and we just feed it input events.<br>
</blockquote>
<br></span>
This would indeed be great. I remember people discussing this at PdCon16.<br>
<br>
It's orthogonal to what I'm suggesting though. I'm not suggesting to render patches in a browser view. I'm suggesting to give the user the option to have a browser view in which to build their own rich UIs, which might look completely different to the Pd patch view.<br>
<br>
No matter how fancy you make the boxes look there are always going to be things you can't do with only boxes and lines. Building completely new types of interface widgets becomes much simpler if you have the full expressive power of a web browser window at your disposal.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know the Purr Data team have worked this out, so maybe we can look at there model or think of something at a different level. I have some ideas and, after having dug into the GUI code to fix zooming/sizing, I know there isn't really that much raw drawing TCL in the core. And most of what's there is pretty simple and repetitive.<br>
</blockquote>
<br></span>
They have done amazing work and so have you.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At this point, it would be great to solve this problem that preserves vanilla stability *and* provides for expanding GUI possibilities.<br>
</blockquote>
<br></span>
The patch I posted is only using [netreceive] - so far I haven't run into any stability issues and the GUI possibilities are already vastly expanded. :)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's totally possible and would lead to interesting stuff using libpd ... at the very least I would consider adding patch creation in PdParty.<br>
</blockquote></span>
Sounds fun! I can imagine Blockly working well for patching on mobile devices:<br>
<br>
<a href="https://developers.google.com/blockly/" rel="noreferrer" target="_blank">https://developers.google.com/<wbr>blockly/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
Chris.</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<a href="http://mccormick.cx/" rel="noreferrer" target="_blank">http://mccormick.cx/</a><br>
<br>
______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/li<wbr>stinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>