<div dir="ltr">Hi all!<div><br></div><div>thanks for the kind welcome :)</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><span class=""><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></span><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></div></div></blockquote><div><br></div><div>fantastic, thanks for the concise and precise directions!</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span class=""><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></span><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" target="_blank">https://musinf.univ-st-<wbr>etienne.fr/lac2017/pdfs/19_C_<wbr>C_137956.pdf</a><br></div><span class=""><div> <br></div></span></div></div></div></blockquote><div><br></div><div>yep, just read the article. It's really great to know you're onto this. In the past it has been very hard to push any real change in that direction, Jonathan will probably know this best given his massive efforts for the new gui. I had done several ui widgets based on Pd-extended, just before it started fading out of existence, so, when I completed my library, pd-ext was not there anymore....arrg.</div><div><br></div><div>I was now about to port everything to vanilla, but fortunately had first a look at Purr and realised the potential it has.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div></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></span><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?</div></div></div></div></blockquote><div><br></div><div>indeed. Jonathan, it would be great if we could discuss the issue a little, so I can understand how I can help.</div><div><br></div><div>I'll now familiarise myself with the new Purr communication protocols. </div><div><br></div><div>best!</div><div>M</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Albert<br></div></font></span></div><span class="HOEnZb"><font color="#888888"><br>-- <br><div class="m_1709928377072839833gmail_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/+<wbr>AlbertGraef</a></div></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/<wbr>listinfo/l2ork-dev</a><br></blockquote></div><br></div></div>