[L2Ork-dev] GSOC 2020

Tue Mar 24 18:17:08 EDT 2020

On Tue, Mar 24, 2020 at 2:48 AM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> On Mon, Mar 23, 2020 at 8:30 AM Alia Morsi <morsi.alia at gmail.com> wrote:
> >
> >
> >
> > 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).
>
> Can you give an estimate for the dates when you will be doing the bulk
> of the writing for your thesis?
>

> >
> > 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.
>
> That will definitely be helpful. But first please make sure that the
> schedule for your project idea is workable *even if* those
> early dates aren't available. You'll want a workable plan *plus* buffer
> time.
>

Ok!
will update the timeline do this on Friday, after I meet with my thesis
supervisor and also discuss with him my execution plan for that.

Thanks :)

>
> >>
> >>
> >> 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?
>
> We do a poor job explaining the project ideas-- the current project
> ideas are only suggestions and may
> be changed (or a completely different idea created for an application).
>
> Nevertheless, I think the idea of a consistent interface is a good
> one. But it does not necessarily mean you must start
> with an emulator class that has methods for various chips. You could
> also have different classes. Perhaps they share
> helper functions. Perhaps not. It all depends on how these chips work
> and what similarities you find when you dig into
> how they work.
>

Ok. I agree.

>
> What I mean by consistent interface really has to do with the user
> experience. To give a contrived example-- suppose
> one emulation class sends output to a signal outlet. If you wrote
> another emulation class that, say, writes output to
> an array instead, that would be an inconsistent interface.
>
> Users should be able to gain knowledge about one emulator and then
> apply as much of that knowledge as possible to
> the other emulator. Having a single class is one way to achieve that.
> But if a single class doesn't seem sensible given
> the emulator you choose to implement, there are other ways to achieve
> a consistent interface for the user.
>

Sure. This is what I meant in the proposal by 'adapting' the emulator to
the interface, to connect between an emulator implementation (which I would
like to be reflective of the chip interface) and the 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.
>
> Sounds good.

> Best,
> Jonathan
>
> >>
> >>
> >> -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
> >
> > _______________________________________________
> > 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/20200325/2dedc9e1/attachment-0001.html>