[L2Ork-dev] Introduction

[Jonathan Wilkes]

On Sat, Jun 8, 2019 at 7:43 AM Jeremiah Rose
<jeremiah.aaron.rose at gmail.com> wrote:
>
> Hi all,
>
> Just signed up on the Purr Data GitLab so here's my introductory email ^_^

Hi Jeremiah,
Welcome! Thanks for the introduction. I've got some responses inline below.

>
> 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 https://github.com/jeremiahrose/RPi0w-PD and it works good but doesn't do PD yet.
>
> 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.

That would be wonderful.

Currently you should be able to build the Purr Data core for RPI zero.

The difficulty is that the RPI zero uses a different arm architecture
than the rpi3. Most of the Linux cross-compilation
documentation is for the other arm archs. While it would be possible
to build nw.js-- the GUI toolkit Purr Data uses-- for RPI zero
arm it's a pain and probably not particularly useful for a single CPU
computer that's trying to also generate audio in realtime.

>
> More generally I'm interested in using a headless Pure Data in embedded contexts.

If that's the case then you should be able to build Purr Data just
fine. The current build script will probably download an nw.js
binary for the wrong arm architecture. But running Purr Data with the
"-nogui" flag should still work just fine.

> 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.
> 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.

Giulio did an initial prototype to keep the stream of "motion"
messages (or "mousemove" event in the GUI) from propagating to the
audio engine.
That's a nice start because each "motion" message that makes it to a
method call[1] triggers a walk through the linked list of gobjs inside
a patch.
With his patch you'd only generate gobj list walks on click[2] and on
dragging selected objects.

Slight digression-- I'm a bit curious what would happen if
canvas_findhitbox iterated through an array of gobjs rather than a
linked list. In other words,
maintain an array of gobs *in addition* to the current linked list
implementation, then measure the performance of array iteration vs.
linked-list walk in
canvas_findhitbox. That may be just the tip of the iceberg. But even
if we separate GUI from core the user will still need to stream
messages for things
like displacing an object or dragging a slider. In those cases,
jumping to the same array index 100 times in a row would be preferable
to walking N
links 100 times in a row, especially where N is large.

As far as the HTML5 GUI-- I used nw.js to retain the multiple toplevel
windows of Pd's UI. For a purely browser-based interface with sensible
UX
I think we need a single container (document, iframe, DOM element,
whatever makes sense) through which the user can access and view
various
canvases available from a given instance. That way the user can click
on a subpatch in that container and see the inside of it in the same
container.
I think we'd have to just relegate each canvas to take up the full
space that the container provides-- otherwise we'll spend all our time
re-implementing
a windowing system inside the browser.

But this is all just initial brainstorming on my part. Let me know if
you have any questions or suggestions going forward. A lot of this
work can
be leveraged and used to get Purr Data's backend running as a
webassembly binary (and therefore, having the entire instance running
inside
the browser).

Best,
Jonathan

[1] I *think* there's already code to throttle these messages in the
core, but that won't prevent dropouts for larger patches.
[2] This can still easily cause dropouts because "click" in Pd is a
misnomer-- it also generates a stream of messages to the core when the
user moves
the mouse over a gobj.

>
> Cheers!
> Jeremiah
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev