[L2Ork-dev] Interested in working on JIT-compiled Signal Graph for the Audio Engine

[Jonathan Wilkes]

On Thu, Mar 11, 2021 at 11:21 AM Prateek Pardeshi
<prateekpardeshi9 at gmail.com> wrote:
>
> Hi everyone,
>
> I'm Prateek Pardeshi, a junior Computer Science student at SRM IST, Chennai. I have been contributing to Open Source since October 2019 (Since Hacktober 2019).
>
> Since then I'm in love with Open Source, because of that I use Linux as my Primary OS and contribute frequently to OS organisation.
>
>
> My Previous Open Source Experience:
>
> 1. Open Source Fellow'21 at HackIllinois
> 2. GirlScript Summer of Code'20 Participant
> 2. Mentor for StudentCodein'20 (Similar to Google Code-in)
>
> Project link: https://git.purrdata.net/jwilkes/summer-of-code-ideas-list#jit-compiled-signal-graph-for-the-audio-engine
>
> I'm interested in this project because I worked as a fellow under Dr.Michael Kruse, maintainer of LLVM Compiler Infrastructure(Polly), also I am contributor at LLVM Compiler Infrastructure, specifically Polly, which is a loop optimiser written in C language. I'm familiar with the LLVM community and the working/debugging/building/issues of LLVM compiler Infrastructure.
>
> Recently I worked on refabricating reference-counting used for memory management to C++ binding.
> This project will provide me an opportunity to work on something new while contributing to the Open Source.
>
> Also, would like to know your expectations, deliverables, scope and thoughts on this project.
>
> In addition to that I've contributed to Gatsby(also an ex-maintainer), GNOME, LBRY, UNO Project, etc.
>
> Looking Forward to being a long term contributor here. :)

Hello Prateek Pardeshi,

Welcome!

That is definitely one of the more ambitious projects listed there. I
believe there is prior art which has been open sourced here:

https://github.com/enzienaudio/hvcc

A challenge for a Purr Data project related to JIT is how it
integrates into the current workflow. Would this be something that
automatically updates as the user builds their program? Or would they
finishing building their program and then click a button to "optimize"
it using this compiler?

As with previous years, I'd suggest an incremental approach to the
core part of the project:

1. proof of concept-- e.g., taking some of the simple DSP classes from
d_arithmetic.c. E.g., examples that are essentially a simple filter
chain of single inputs and single outputs like a -> b -> c etc.

2. extending that to graphs that include objects with multiple inputs
and outputs

3. consider extending this to objects that convert to/from signal data
to non-DSP data

4. extending the approach so that some subset of dynamically loaded
external DSP classes

5. and so on...

As far as scope goes-- this project idea was written before Google
changed the number of hours. So perhaps focusing on the core classes
and leaving external libraries as a stretch goal. But I'd definitely
make sure to prioritize UX, even for the proof of concept.

Best,
Jonathan

>
> I think my email was bounced back by the mailman due to a custom domain, so sending again from gmail.
>
> Regards,
> Prateek Pardeshi
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev