[L2Ork-dev] Contributing to new GUI improvement?

[Ivica Ico Bukvic]

Completely agree with Albert--your contributions would be most welcome. 
Thank you, Marco, and welcome to the community! I suggest that you 
communicate closely with Jonathan who is the wizard behind the 
node-webkit port as he will know more than anyone else at this point as 
to what it will take to make your objects possible. One thing to 
consider, Jonathan a while ago showed how easy it is to make GUI objects 
using newly introduced additions to the data structures he developed, so 
that may be another way to achieve what you're looking for without 
having to delve into C--this may also make your GUI elements more 
flexible and extensible.

Best,

Ico

On 12/18/2017 7:03 AM, Albert Graef wrote:
> Hi Marco, and welcome on board! :)
>
> On Mon, Dec 18, 2017 at 11:32 AM, Marco Donnarumma 
> <lists at marcodonnarumma.com <mailto:lists at marcodonnarumma.com>> wrote:
>
>     Being myself a webdesigner and thus expert in html and css, as
>     well as familiar with nw, I wondered if I would be able to
>     contribute somehow to the improvements to the new Purr GUI.
>
>
> That'd be great, contributions are always welcome!
>
>     Where in the Purr source should I look first to get an
>     understanding of how the new gui works and how it can be improved?
>
>
> The JavaScript source of the GUI is in purr-data/pd/nw/. It's hard to 
> understand by itself, though, since there are some deep tie-ins with 
> Pd's real-time engine in the C part, i.e., the stuff in 
> purr-data/pd/src/. Basically, the GUI and the real-time engine each 
> run in their own process and communicate over a socket using Pd's 
> "FUDI" protocol (or rather some Purr-specific variation of it).
>
> Basically, the GUI calls the C part using the pdsend() function (in 
> pdgui.js), and the C part calls back into the GUI using functions like 
> gui_vmess(), gui_start_vmess() ... gui_end_vmess(). So these are the 
> kind of calls you want to watch out for. Be warned that the sources 
> are riddled with these, and it's not always easy to figure out what 
> interactions are going on there. But we can always ask Jonathan, he 
> has a really good grasp of the big hairball that is the internals of 
> Pd. ;-)
>
>     For instance, something basic that I'd like to achieve is a small
>     public library of new animated gui sliders and gui buttons with
>     embedded preset saving.
>
>
> We've also been thinking along these lines. See, e.g., Section 4.3 in 
> our LAC paper: 
> https://musinf.univ-st-etienne.fr/lac2017/pdfs/19_C_C_137956.pdf
>
>     I'm aware this seems not to be among your priorities (at least
>     from the read me on Albert github), nevertheless would like to
>     hear your opinion.
>
>
> I actually consider this a high priority, it would be just *amazing* 
> to have this capability! My understanding is that the main issue there 
> is the way that Pd does its gop scaling, so we'd need a way to turn 
> that off when rendering data structures inside a gop area. Jonathan 
> has given this some thought already, if I'm not mistaken. Jonathan?
>
> Albert
>
> -- 
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com <mailto:aggraef at gmail.com>
> WWW: https://plus.google.com/+AlbertGraef
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20171218/c485c78f/attachment.html>