[L2Ork-dev] GSOC 2020

[Jonathan Wilkes]

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.

>>
>>
>> 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.

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.

>>
>>
>> * 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