[PSA] Upcoming projects

[Eric Griffis]

Hello everyone,

Over the next few months, I will be breaking ground on three new projects.

== A diagramming library ==

  An Algebraic Racket port of Haskell's diagrams library:

  https://archives.haskell.org/projects.haskell.org/diagrams/

  I love this design. It's like Pict, but the API is structured as a
  monoid under cc-superimpose.

== A dynamic, interactive data visualization library ==

  An aggressive Algebraic Racket adaptation of the parts of D3.js I like.

  Initial use cases:
  - concurrent / distributed process network visualizations
  - hybrid text/graphical UIs with automatic layout
  - a generic feed browser

== A digital audio workstation library ==

  An experiment in real-time interactive Neuron programming.

  The base package will include a basic synth, a sampler, a sequencer, and
  a multi-track recorder -- like a developer API for Fruity Loops.

  Endpoints for MIDI and audio I/O should be easy to build with packages
  in the official repo.

  Optimistic feature list:
  - multi-track recording and playback (audio & MIDI)
  - non-destructive edits
  - mix automation
  - inter-process signal routing
  - global clock synchronization

I will then combine these projects into a hybrid DAW / VJ instrument and
target a live A/V performance for FARM 2020, the SIGPLAN workshop for
functional art and music co-located with ICFP.

If any part of this interests you, however large or small, reach out!

If you are working on related software, or planning to, speak up!

Eric

[Daniel Prager]

Hi Eric

They all sound great.

I'm particularly interested in the first two, and was very impressed by the Diagram project gallery, and it would be great to see in Racket.

Quick question: Why Algebraic Racket?

Dan

[Eric Griffis]

On Thu, Jun 27, 2019 at 9:12 PM Daniel Prager <daniel....@gmail.com> wrote:
>
> Hi Eric
>
> They all sound great.
>
> I'm particularly interested in the first two, and was very impressed by the Diagram project gallery, and it would be great to see in Racket.

Cool! Thanks for the comments.

> Quick question: Why Algebraic Racket?
>
> Dan

If I understand the question, you're asking what makes Algebraic Racket
"algebraic?"

It started as an attempt to implement algebraic data types without
committing to a type system. Turns out, "typed algebraic structures minus
the typing constraints" is a useful design heuristic.

Eric

[Daniel Prager]

Hi Eric

On Fri., 28 Jun. 2019, 16:15 Eric Griffis, <ded...@gmail.com> wrote:

On Thu, Jun 27, 2019 at 9:12 PM Daniel Prager <daniel....@gmail.com> wrote:

[snip]

> Quick question: Why Algebraic Racket?

If I understand the question, you're asking what makes Algebraic Racket
"algebraic?"

It started as an attempt to implement algebraic data types without
committing to a type system. Turns out, "typed algebraic structures minus
the typing constraints" is a useful design heuristic.

That's interesting, but not what I was driving at! My bad ...

Take 2:

Why implement these projects in Algebraic Racket?

Dan

[Eric Griffis]

> Why implement these projects in Algebraic Racket?

Good question -- not so easy to answer cleanly. Here's a smattering.

I created Algebraic Racket to make functional meta-programming in Racket
more enjoyable. My talk will demonstrate what I mean by that and why it
matters in practice.

The packages are also a field test for Algebraic Racket's extended feature
set. The diagrams library uses classes for ad hoc polymorphism. The
visualization and audio libraries use algebraic data for inter-process
messaging.

Algebraic Racket is designed to accommodate my programming style:
mostly-pure, compositional, driven by structural pattern matching at
multiple run-time phases. I like match and syntax-parse, but I love
Algebraic Racket.

(Don't tell Matthias I said this, but sometimes point-free style is more
compact and easier to read. This happens a lot more often in Algebraic
Racket, and it leads to good things.)

Algebraic Racket is mostly just extra syntax for the Racket base.
Replacing #lang racket/base with #lang algebraic/racket/base should not
change what a program does or slow it down much, and modules in one
language can be used in the other. Pattern-based variants of core Racket
syntactic forms (e.g, let, case, define) can be imported, but that breaks
drop-in compatibility.

Eric

[Ryan H]

Hi Eric,

The DAW library project sounds interesting. I don't know much about music production, but a friend has been getting into it, so I've dabbled a bit. It's always cool to see what people can do with code and music. The other day I watched some of Chris Ford's talks, and that was neat. I've wondered if working with a UI is better, though, because it gives you interactivity and visual feedback that code can't. But maybe Racket's strength with DSLs can overcome that. Neuron also sounds interesting—a DAW based on it sounds like a modular synthesizer. Maybe you could even distribute it across the internet, and get something like NINJAM. Looking forward to seeing how the project and performance turn out.

Ryan