[L2Ork-dev] GSOC 2020

Sun Mar 22 21:07:04 EDT 2020

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!

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.

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

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

-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