<div dir="ltr"><div>Thanks Jonathan and Ico for your emails,</div><div><br></div><div>I have the mailing list set to digest mode so hopefully this reply works as intended - responses inline.<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">
> I've been using PD and PD-extended on the Raspberry Pi for a 
prototype of an electric trumpet that I'm building. At the moment I'm 
working on a minimal Buildroot OS for the RPi0w to boot directly to Pure
 Data - that project is over at <a href="https://github.com/jeremiahrose/RPi0w-PD" rel="noreferrer" target="_blank">https://github.com/jeremiahrose/RPi0w-PD</a> and it works good but doesn't do PD yet.<br>
><br>
> My immediate goal is to make a Buildroot package for either Purr 
Data or PD Vanilla (or both!) and if you guys want, I could try to get 
it pulled into the main Buildroot repo.<br><br>
That would be wonderful.<br><br>
Currently you should be able to build the Purr Data core for RPI zero.<br><br>
The difficulty is that the RPI zero uses a different arm architecture<br>
than the rpi3. Most of the Linux cross-compilation<br>
documentation is for the other arm archs. While it would be possible<br>
to build nw.js-- the GUI toolkit Purr Data uses-- for RPI zero<br>
arm it's a pain and probably not particularly useful for a single CPU<br>
computer that's trying to also generate audio in realtime.<br></blockquote><div><br></div><div>I have Pd Vanilla working well in Buildroot and currently doing tests to submit the patch.</div><div>Yes, I'm a bit intimidated by Purr Data's build process. Is the core (minus GUI and externals) substantially different from Pd Vanilla? What's the relationship between Purr Data and Pd Vanilla in terms of git workflow - do you rebase against upstream Pd Vanilla HEAD (like <a href="https://puredata.info/docs/developer/GitWorkflows">Pd extended did</a>) or was it forked from a previous version?</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">
> More generally I'm interested in using a headless Pure Data in embedded contexts.<br><br>
If that's the case then you should be able to build Purr Data just<br>
fine. The current build script will probably download an nw.js<br>
binary for the wrong arm architecture. But running Purr Data with the<br>
"-nogui" flag should still work just fine.<br></blockquote><div><br></div><div>This will work well enough for me but I don't think Buildroot would accept a patch for a package that contains a non-working binary. Maybe I'll try to compile Chromium for RPi0w anyway and see how it goes ... sounds like a fun night in :-o<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I read the conversation with Giulio from the Bela project and I 
feel like my needs are pretty much aligned with his in regards to 
separation of GUI and backend.<br>
> I would like to use a headless Pure Data on one machine, and then 
subsequently connect a browser based GUI from another machine to edit 
the currently running patch. So I'm keen on the HTML GUI used in Purr 
Data and would like to learn more about how that's implemented, and what
 I can do to help with any efforts to separate GUI from backend.<br><br>
Giulio did an initial prototype to keep the stream of "motion"<br>
messages (or "mousemove" event in the GUI) from propagating to the<br>
audio engine.<br>
That's a nice start because each "motion" message that makes it to a<br>
method call[1] triggers a walk through the linked list of gobjs inside<br>
a patch.<br>
With his patch you'd only generate gobj list walks on click[2] and on<br>
dragging selected objects.<br></blockquote><div><br></div><div>Do you have a link to Giulio's work on this? I couldn't find the relevant commits at <a href="https://git.purrdata.net/giuliomoro/purr-data">https://git.purrdata.net/giuliomoro/purr-data</a></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">
Slight digression-- I'm a bit curious what would happen if<br>
canvas_findhitbox iterated through an array of gobjs rather than a<br>
linked list. In other words,<br>
maintain an array of gobs *in addition* to the current linked list<br>
implementation, then measure the performance of array iteration vs.<br>
linked-list walk in<br>
canvas_findhitbox. That may be just the tip of the iceberg. But even<br>
if we separate GUI from core the user will still need to stream<br>
messages for things<br>
like displacing an object or dragging a slider. In those cases,<br>
jumping to the same array index 100 times in a row would be preferable<br>
to walking N<br>
links 100 times in a row, especially where N is large.<br></blockquote><div><br></div><div>Sorry for my ignorance, but are the functions you're quoting here a part of the nw.js implementation? Would it be possible to upstream these improvements to Vanilla or am I thinking about it wrongly?<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">
As far as the HTML5 GUI-- I used nw.js to retain the multiple toplevel<br>
windows of Pd's UI. For a purely browser-based interface with sensible<br>
UX<br>
I think we need a single container (document, iframe, DOM element,<br>
whatever makes sense) through which the user can access and view<br>
various<br>
canvases available from a given instance. That way the user can click<br>
on a subpatch in that container and see the inside of it in the same<br>
container.<br>
I think we'd have to just relegate each canvas to take up the full<br>
space that the container provides-- otherwise we'll spend all our time<br>
re-implementing<br>
a windowing system inside the browser.<br></blockquote><div><br></div><div>>From my perspective as an outsider, this sounds like a very sensible approach. Each canvas is a div/iframe/whatever, and allow the web developer to put them wherever she wants.<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">
But this is all just initial brainstorming on my part. Let me know if<br>
you have any questions or suggestions going forward. A lot of this<br>
work can<br>
be leveraged and used to get Purr Data's backend running as a<br>
webassembly binary (and therefore, having the entire instance running<br>
inside<br>
the browser).<br></blockquote><div><br></div><div>That would indeed be very cool. I found another project claiming to do this here: <a href="https://github.com/sebpiq/WebPd">https://github.com/sebpiq/WebPd. <br></a></div><div><br></div><div>At the moment (again, from my perspective as an outsider), it seems like there is a constellation of overlapping Pure Data projects without very much coordination and a lot of duplicated work. Was this a philosophical decision made by the community, or more of an accident?</div><div>I would love to see an ecosystem where I could, for example, use the core Pd Vanilla maintained by Miller as an API and then just compile it against whatever GUI worked for my application, be that nw.js, Tk, a browser based GUI connecting to a server backend (which is what I need), or a browser based webassembly backend, or whatever. Or maybe that's what's happening already?<br></div><div>Anyway, just brainstorming on my behalf.<br></div><div> </div><div>Cheers!<br></div><div>Jeremiah<br></div></div>