[L2Ork-dev] GSoC '19

Thu Mar 28 08:17:25 EDT 2019

Hello Jonathan,
Sorry for the late reply, has been swamped by school work during the past
few days.

On Sun, 24 Mar 2019 at 11:52, Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> >
> > Hi all,
> >
> > I am writing to express my interest in working on Purr-Data in the
> Google Summer of Code.
> >
> > I was just looking at the project suggestions on Jonathan's GitLab page,
> and am interested in a couple of them.
>
> Btw-- if you have a potential GSoC idea that isn't listed there, feel
> free to add it or ask about it here on the list.
>

At the moment, I cannot really think of anything else better than your
suggestions, but I will let you know if I come up with any new ideas.

>
> > The first one is making a REPL interface. As someone who insist on doing
> most of the work on the command line, this project sounds really
> interesting to me. I would be very keen to explore how to communicate with
> embedded device locally or via ssh. Although I have never use Pure Data in
> any embedded device (apart from a small attempt of using pduino), I am
> eager to learn more and eventually develop a user-friendly REPL interface
> for Raspberry PI and other devices.
> >
> > The second one is encapsulation ergonomics. As a Pd user for slightly
> more than two years, I do find abstraction a troublesome process in Pd.
> This project sounds like a great opportunity to rewrite some of the code
> that would make abstraction a more natural process in patching. Although
> the GitLab page does not specify the language(s) required for this project,
> I am assuming C would be a prerequisite?
>
> Yes, C. And possibly a trivial bit of Javascript to add some menu options.
>
> That sounds great, C is my strong suit, and hopefully Javascript would not
be too hard to learn

> >
> > These two sounds almost equally interesting to me.
> > It would be great if you would kindly suggest which one is more
> beneficial to the Pd community.
>
> The encapsulation idea would probably immediately benefit current Pd users.
>

On the other hand, the REPL idea could potentially open up new ways to
> create and interact
> with Pd patches.
>

That is what I was thinking as well.
If that is the case, I would probably just stick to the encapsulation idea.

>
> >
> > Also, I am just wondering if there are any suggestions in applying for
> GSoC and writing a project proposal?
>
> You might begin by compiling Purr Data from source using the build guide
> here:
>
> https://git.purrdata.net/jwilkes/purr-data#build-guide
>
> Yes, I have just done that using git and homebrew.
Although I came across some trouble while homebrewing python (since I
already had python), it went just fine after I reinstall it.

Since you are already a Pd user, you might then roughly outline the
> features you would like from a
> successful implementation of either of the ideas you mentioned above.
> What would it feel like to
> use the new encapsulation features, or to interact with Pd through the
> REPL? What new possibilities
> would these features provide that is not currently possible in Pd?
>
> Then see if you can figure out which sections of the source code would
> be touched by either idea. If
> you can, try to rate each part as to which will require the most work.
>

Thank you for your concrete suggestions.
I will try to work on these in these couple of days.

>
> One thing I'll say about last year's GSoC-- we used an incremental
> approach to the project. This meant
> that Pranay submitted fairly self-contained code patches at each stage
> of the project which could
> be merged into master without any conflicts. This turned out to work
> really well. For the two project
> ideas you've mentioned, I believe it should be possible to take a
> similar approach. So see if you can
> divide the project up into fairly self-contained sections.
>

I will see what I can do after I have located where the source code
responsible for encapsulation are.

>
> Finally, feel free to post to the list or email me if you come up with
> more questions as you flesh out
> the idea. (Also, it is possible to submit more than one proposal if
> you have the time to flesh out
> both idea. Though I imagine as you start to investigate them you may
> begin to favor one over the
> other, which is fine.)
>
>
I just have a couple of concerns.
Sorry I might have overestimated myself in the past week, but I realised I
might not be able to commit for 30+ hours per week during May since I am in
Australia, the exams are usually in May-early June.
Having said that, the encapsulation project does not seems to be too hard
to do, though I might have underestimated it since if it was easy, it
should have already been a feature in Pd.
I just want to check in what is the expectation from you guys in terms of
commitment?
I might reevaluate myself in these couple of days.
Just in case, if I realise in these few days that I do not have the
capacity for GSoC, would I still be able to contribute to this in anyway?
I would definitely be keen to contribute to the Pd community within or
outside GSoC.

Kind regards,
Tsz-Kiu

> I am aware that the application starts in a couple of days, so I
> apologise if this is too last-minute.
>
> Definitely not too late.
>
> >
> > Something about myself:
> > I did my undergraduate in Music, majored in Composition during my
> honours year. I started to use Pure Data about two years ago. Thanks to Pd,
> I became interested in computer music and digital signal processing. I am
> currently a Master student in electrical engineering at the University of
> Melbourne. I have only started programming (apart from Pd) last year but
> now I am a tutor in programming/computing in C at the University. I insist
> on doing most of my work on the command line, therefore I also know the
> basics of bash scripting.
>
> That sounds like a great starting point. We look forward to your
> application! And again,
> email us if you have any more questions.
>
> Best,
> Jonathan
>
> >
> > Thank you very much for your time.
> >
> > Kind regards,
> > Tsz-Kiu
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20190328/1faa1832/attachment-0001.html>