[L2Ork-dev] GSOC 2020

[Alia Morsi]

On Mon, Mar 23, 2020 at 3:07 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Sun, Mar 22, 2020 at 6:39 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> wrote:
> >
> > On Sun, Mar 22, 2020 at 4:59 PM Alia Morsi <morsi.alia at gmail.com> wrote:
> > >
> > > finally it worked :), and made sound too!
> >
> > Great to hear! (Pun intended. :)
> >
> > One thing to note: atari_2600~ has no help patch or even a README.txt
> > file. It's a lot easier to
> > get up and running when those two files exist.
> >
> > >
> > > This is a first draft of my proposal, I would appreciate comments and
> tips. Also, I've opened the ability to comment to everyone.
> > >
> https://docs.google.com/document/d/12RVFkiOj4gr8HYv7k2dGDlYY-io5y8r4EeGcMYnKI48/edit?usp=sharing
> >
> > Thanks, I'll have a look after dinenr tonight.
>
> Ok, I've had a look. I'll start with the biggest question:
>
> Where are you in the master's thesis process, and what amount of work
> will you be
> doing during those dates? How can you be sure you won't need more of the
> days
> before that to devote solely to your thesis? So many questions about that!
>

Currently I'm writing the state of the art, and refining the details of the
'experiment' I will conduct. Btw, the date specified in July is the master
thesis presentation. The document itself is due the first week of
September, which gives me time after GSOC to dedicate only to finish the
writing.

There is no way to be 100% sure that everything will be precisely as the
plan. However, no matter how crazy thesis will get, I cannot mentally work
on it round the clock, so the hours I specified in my proposal seem
plausible to me (I hope).

Also, I was thinking maybe I can start earlier with hours like the yellow
productivity level, since I already finished my courses. I can win myself a
buffer to prepare for the worst case scenario. I'm quite inclined to this
idea, so that by the official time of GSOC start I have already gotten
started and adjusted the plan of deliverables to what I can surely deliver.

>
> Here are some general observations:
>
> * if I understand correctly you are suggesting to use Pd abstraction
> wrappers to implement some of the "common tricks"
> that composers used on these chips. That sounds like a great idea.
>

 Yes!! :)

>
> * are you suggesting to make a single emulatior class that can be used
> for different chips?
>

Yes. I still have to think of how to merge the 'common tricks' idea with
this emulator class.

Correct me if I'm wrong, but I thought this was the main requirement of the
project, from the statement "Purr Data would benefit by having a library
that provides a *consistent interface* for objects that take input into an
emulation of a piece of hardware and output one or more audio signals."
What else did you mean by consistent interface?

>
> * have you looked for prior art in the Pd world for emulators for any
> of the chips you mentioned?
>

No. how silly of me. I will check and update the proposal document.

>
> -Jonathan
>
>
> >
> > Best,
> > Jonathan
> >
> > >
> > > Looking forward for your response/s
> > >
> > > On Thu, Mar 19, 2020 at 2:36 AM Jonathan Wilkes <
> jon.w.wilkes at gmail.com> wrote:
> > >>
> > >> On Wed, Mar 18, 2020 at 6:23 PM Alia Morsi <morsi.alia at gmail.com>
> wrote:
> > >> >
> > >> > Hello! my comments and questions are inline to your past email.
> > >> >
> > >> > On Wed, Mar 4, 2020 at 4:31 PM Jonathan Wilkes <
> jon.w.wilkes at gmail.com> wrote:
> > >> >>
> > >> >> On Wed, Mar 4, 2020 at 5:33 AM Alia Morsi <morsi.alia at gmail.com>
> wrote:
> > >> >> >
> > >> >> > Hi!
> > >> >> >
> > >> >> >
> > >> >> > I’m a master student at the moment, and have software
> development experience in my past life. I would like to participate in GSOC
> 2020 with purr data, which I had used in one of the master courses.
> > >> >> >
> > >> >> >
> > >> >> > I’m considering those options:
> > >> >> >
> > >> >> > Vintage Platform Audio Emulation Library
> > >> >> >
> > >> >> > and
> > >> >> >
> > >> >> > Interaction with Audio Plugins
> > >> >> >
> > >> >> >
> > >> >> > I would like to choose based on which would be feasible to
> implement given my skillset, and therefore It would be great if the
> potential mentor/s contact me to have a little discussion.
> > >> >> >
> > >> >> >
> > >> >> > Please reach out!
> > >> >> >
> > >> >>
> > >> >> Hello Alia Morsi,
> > >> >>
> > >> >> Welcome!
> > >> >>
> > >> >> A general starting point would be to create a fork of Purr Data at
> > >> >> git.purrdata.net. Then compile Purr Data
> > >> >> for your OS using the guide here:
> > >> >>
> > >> >> https://git.purrdata.net/jwilkes/purr-data#build-guide
> > >> >>
> > >> >> Once you have that running pick one of the issues labeled
> > >> >> "good-first-bug" to get experience
> > >> >> making a feature branch, touching the code, fixing the bug, and
> making
> > >> >> a merge request in
> > >> >> Gitlab. That will show you the basic process by which we develop
> Purr Data.
> > >> >
> > >> >
> > >> > Done :)
> > >> >>
> > >> >>
> > >> >> For the audio emulation library, I left a single piece of prior
> art in the repo.
> > >> >>
> > >> >> Once you've cloned the Purr Data repo, have a look at
> > >> >> purr-data/externals/mmonoplayer
> > >> >> and see if you can figure out how to compile that C source file to
> > >> >> create an external binary
> > >> >> for Purr Data. It's a bit tricky given there is no build script or
> > >> >> help file. But I think it's a good exercise to
> > >> >> have a look at the interface for that class and play around with
> it in
> > >> >> Purr Data. Also, you'll probably
> > >> >> run into a lot of prior art like this which has minimal
> > >> >> documentation/build scripts. :)
> > >> >
> > >> >
> > >> > I did attempt to build it. At the end, an atari2600~.pd_darwin file
> is created. But, although I put it in the same directory as a .pd file, I
> still can’t create an atari_2600~ object (this is the exact symbol used in
> gensym in the atari2600~.c file, so I was hoping it would work)
> > >> >
> > >> >
> > >> > To create the Makefile, I used the template/ external folder as a
> starting point. I hardcoded the include paths of pd headers in the Makefile
> (bad.. I know), and deleted some clang compiler flags.
> > >> >
> > >> > I’m a bit stuck where I’m not sure if the reason it’s not loading
> is due to a mistake in my editing of the Makefile itself, or due to another
> rookie error I could have made. btw get a link warning that says “ld:
> warning: directory not found for option '-L/sw/lib'”. While I don’t know
> exactly what that means, I thought I’d put it here in case it is indeed
> what’s causing the problem.
> > >>
> > >> I'd advise throwing out the Makefile for now and compiling straight
> from gcc:
> > >>
> > >> * you want to compile it as a shared library
> > >> * compile it to have position independent code (for example, on
> > >> aarch64 it won't load correctly if you don't do that)
> > >> * make sure there are no errors or even warnings
> > >>
> > >> Now, when you try to test it do two things:
> > >>
> > >> 1. Run Purr Data with -verbose flag: `pd-l2ork -verbose`
> > >> 2. After Purr Data starts up, click "Clear Console" in the "Edit" menu
> > >> of the main Pd window. (There's a handy little shortcut for it, too.)
> > >> 3. Now that your Pd window is clear go ahead and try to create
> "atari_2600~".
> > >>
> > >> If it ends up broken, check the Pd window for external loading errors.
> > >>
> > >> >
> > >> >
> > >> >
> > >> >>
> > >> >> Some questions:
> > >> >>
> > >> >> Would you want to use mostly Pd abstractions or external compiled
> > >> >> binaries for the library? Lots of
> > >> >> trade-offs there with speed, rapid prototyping, readability, etc.
> > >> >
> > >> >
> > >> >>
> > >> >> I’m inclined to choose external compiled binaries, but I’m quite
> flexible. I guess this would be the choice of better speed, slower
> prototyping, and worse readability (if I understand the tradeoffs
> correctly).
> > >>
> > >>
> > >>
> > >> Abstractions are more accessible-- that is, one can read them and
> > >> potentially change/fix them and they'll run on every platform without
> > >> recompile.
> > >>
> > >> But for this kind of project there will be an enormous speed advantage
> > >> writing it in C.
> > >>
> > >>
> > >> >
> > >> >
> > >> >>
> > >> >> What should the interfaces look like? You can have signal i/o,
> control
> > >> >> input with signal output, a mixture,
> > >> >> etc. Is there a common interface that may be reused within the
> library?
> > >> >>
> > >> > Do you mean, what would be a suitable interface through which many
> of the devices in mind could be adapted? I believe an approach to answer
> this question would be to find a generalization after emulating a couple of
> devices, if I understand correctly, so I don't have a concrete answer to
> this now.
> > >>
> > >>
> > >> I mean the interface consisting of inlets, outlets, and the class
> methods.
> > >>
> > >>
> > >> >
> > >> > Also, I’ve used none of such vintage devices, so what would the
> process of emulating them be like? I am hoping that through their spec
> sheets I can get started. but are there any other resources you recommend?
> > >>
> > >>
> > >> There are pretty active forums for emulating vintage audio chips and
> > >> instruments. I would definitely check those to see what
> > >> the prior art looks like.
> > >>
> > >> -Jonathan
> > >>
> > >> >
> > >> >
> > >> >> If you're interested in that project then hopefully that's enough
> to
> > >> >> get started.
> > >> >>
> > >> >> Feel free to post any more questions you may have here to the list.
> > >> >>
> > >> >> Jonathan
> > >> >>
> > >> >> >
> > >> >> > Thanks
> > >> >> >
> > >> >> > Alia
> > >> >> >
> > >> >> > _______________________________________________
> > >> >> > 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
> > >> >
> > >> > _______________________________________________
> > >> > 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
> > >
> > > _______________________________________________
> > > 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/20200323/a0f4af4f/attachment-0001.html>