[PD] Browser UIs for vanilla Pd patches

[Billy Stiltner]

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
for my browser interface to xensynth

https://ia601201.us.archive.org/34/items/xensynth/xesynthcontrol/xensynthcontrol.html

xensynthcontrol.html is  just a bunch of high level stuff that was easier
to do with html javascript than patching up in pd ,
however it's a vital part of my music making when selecting a scale or mode
and  generating a Moments of Symmetry
beatmap for my sequencer.Looks like it will be  good to replace JAVA's
tcp/udp sockets since JAVA is no longer supported
by major web browsers.
video here
https://archive.org/details/xensynthnetworkcontrol

Was getting antsy about a solution, am still kind of iffy because JAVA
worked for so long and the end of mozilla's support
is the end of this month supposedly. JAVA applets were the only cross
platform solution to sockets from browser to pd
as far as I knew. Will websockets last as long as JAVA applets did?
https://support.mozilla.org/en-US/questions/1216281


On Tue, Mar 20, 2018 at 1:13 AM, Chris McCormick <chris at mccormick.cx> wrote:

> On 20/03/18 05:29, Dan Wilcox wrote:
>
>> 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.
>>
>
> There's no need to add in-app socket communication. The "server" runs
> inside Pd itself.
>
> The change to the app would look like this in psuedo-code:
>
> if "index.html" in patch folder:
>   instantiate WKWebView with index.html loaded
> else:
>   instantiate existing pd[droid]party GUI view
>
> 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.
>
> Even if we have 100 Ghz, native (iOS CoreGraphics, etc) will still be
>> faster.
>>
>
> That's true.
>
> 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.
>
> 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.
>>
>
> This would indeed be great. I remember people discussing this at PdCon16.
>
> 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.
>
> 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.
>
> 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.
>>
>
> They have done amazing work and so have you.
>
> At this point, it would be great to solve this problem that preserves
>> vanilla stability *and* provides for expanding GUI possibilities.
>>
>
> 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.
> :)
>
> It's totally possible and would lead to interesting stuff using libpd ...
>> at the very least I would consider adding patch creation in PdParty.
>>
> Sounds fun! I can imagine Blockly working well for patching on mobile
> devices:
>
> https://developers.google.com/blockly/
>
> Chris.
>
>
> --
> http://mccormick.cx/
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180803/d82fd15c/attachment-0001.html>