<div dir="ltr">Hi Marco, and welcome on board! :)<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 18, 2017 at 11:32 AM, Marco Donnarumma <span dir="ltr"><<a href="mailto:lists@marcodonnarumma.com" target="_blank">lists@marcodonnarumma.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>That'd be great, contributions are always welcome!<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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?</div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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. ;-)<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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.</div></div></blockquote><div><br></div><div>We've also been thinking along these lines. See, e.g., Section 4.3 in our LAC paper: <a href="https://musinf.univ-st-etienne.fr/lac2017/pdfs/19_C_C_137956.pdf">https://musinf.univ-st-etienne.fr/lac2017/pdfs/19_C_C_137956.pdf</a><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div><div>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?<br></div><div><br></div><div>Albert<br></div></div><br>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Albert Gr"af<br>Computer Music Research Group, JGU Mainz, Germany<br>Email:  <a href="mailto:aggraef@gmail.com" target="_blank">aggraef@gmail.com</a><br>WWW:    <a href="https://plus.google.com/+AlbertGraef" target="_blank">https://plus.google.com/+AlbertGraef</a></div></div>
</div></div>