<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 3:07 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 22, 2020 at 6:39 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
><br>
> On Sun, Mar 22, 2020 at 4:59 PM Alia Morsi <<a href="mailto:morsi.alia@gmail.com" target="_blank">morsi.alia@gmail.com</a>> wrote:<br>
> ><br>
> > finally it worked :), and made sound too!<br>
><br>
> Great to hear! (Pun intended. :)<br>
><br>
> One thing to note: atari_2600~ has no help patch or even a README.txt<br>
> file. It's a lot easier to<br>
> get up and running when those two files exist.<br>
><br>
> ><br>
> > This is a first draft of my proposal, I would appreciate comments and tips. Also, I've opened the ability to comment to everyone.<br>
> > <a href="https://docs.google.com/document/d/12RVFkiOj4gr8HYv7k2dGDlYY-io5y8r4EeGcMYnKI48/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/12RVFkiOj4gr8HYv7k2dGDlYY-io5y8r4EeGcMYnKI48/edit?usp=sharing</a><br>
><br>
> Thanks, I'll have a look after dinenr tonight.<br>
<br>
Ok, I've had a look. I'll start with the biggest question:<br>
<br>
Where are you in the master's thesis process, and what amount of work<br>
will you be<br>
doing during those dates? How can you be sure you won't need more of the days<br>
before that to devote solely to your thesis? So many questions about that!<br></blockquote><div><br></div><div><font color="#0b5394">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. </font></div><div><font color="#0b5394"><br></font></div><div><font color="#0b5394">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).</font></div><div><font color="#0b5394"><br></font></div><div><font color="#0b5394">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. </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Here are some general observations:<br>
<br>
* if I understand correctly you are suggesting to use Pd abstraction<br>
wrappers to implement some of the "common tricks"<br>
that composers used on these chips. That sounds like a great idea.<br></blockquote><div><br></div><div><font color="#0b5394"> Yes!! :)</font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* are you suggesting to make a single emulatior class that can be used<br>
for different chips?<br></blockquote><div><br></div><div><font color="#0b5394">Yes. I still have to think of how to merge the 'common tricks' idea with this emulator class. </font></div><div><font color="#0b5394"><br></font></div><div><font color="#0b5394">Correct me if I'm wrong, but I thought this was the main requirement of the project, from the statement "</font><span style="font-family:"Helvetica Neue";font-size:12px"><font color="#0b5394">Purr Data would benefit by having a library that provides a <b>consistent interface</b> for objects that take input into an emulation of a piece of hardware and output one or more audio signals." </font></span></div><div><span style="font-family:"Helvetica Neue";font-size:12px"><font color="#0b5394">What else did you mean by consistent interface?</font></span></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* have you looked for prior art in the Pd world for emulators for any<br>
of the chips you mentioned?<br></blockquote><div><br></div><div><font color="#0b5394">No. how silly of me. I will check and update the proposal document. </font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
-Jonathan<br>
<br>
<br>
><br>
> Best,<br>
> Jonathan<br>
><br>
> ><br>
> > Looking forward for your response/s<br>
> ><br>
> > On Thu, Mar 19, 2020 at 2:36 AM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
> >><br>
> >> On Wed, Mar 18, 2020 at 6:23 PM Alia Morsi <<a href="mailto:morsi.alia@gmail.com" target="_blank">morsi.alia@gmail.com</a>> wrote:<br>
> >> ><br>
> >> > Hello! my comments and questions are inline to your past email.<br>
> >> ><br>
> >> > On Wed, Mar 4, 2020 at 4:31 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br>
> >> >><br>
> >> >> On Wed, Mar 4, 2020 at 5:33 AM Alia Morsi <<a href="mailto:morsi.alia@gmail.com" target="_blank">morsi.alia@gmail.com</a>> wrote:<br>
> >> >> ><br>
> >> >> > Hi!<br>
> >> >> ><br>
> >> >> ><br>
> >> >> > 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.<br>
> >> >> ><br>
> >> >> ><br>
> >> >> > I’m considering those options:<br>
> >> >> ><br>
> >> >> > Vintage Platform Audio Emulation Library<br>
> >> >> ><br>
> >> >> > and<br>
> >> >> ><br>
> >> >> > Interaction with Audio Plugins<br>
> >> >> ><br>
> >> >> ><br>
> >> >> > 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.<br>
> >> >> ><br>
> >> >> ><br>
> >> >> > Please reach out!<br>
> >> >> ><br>
> >> >><br>
> >> >> Hello Alia Morsi,<br>
> >> >><br>
> >> >> Welcome!<br>
> >> >><br>
> >> >> A general starting point would be to create a fork of Purr Data at<br>
> >> >> <a href="http://git.purrdata.net" rel="noreferrer" target="_blank">git.purrdata.net</a>. Then compile Purr Data<br>
> >> >> for your OS using the guide here:<br>
> >> >><br>
> >> >> <a href="https://git.purrdata.net/jwilkes/purr-data#build-guide" rel="noreferrer" target="_blank">https://git.purrdata.net/jwilkes/purr-data#build-guide</a><br>
> >> >><br>
> >> >> Once you have that running pick one of the issues labeled<br>
> >> >> "good-first-bug" to get experience<br>
> >> >> making a feature branch, touching the code, fixing the bug, and making<br>
> >> >> a merge request in<br>
> >> >> Gitlab. That will show you the basic process by which we develop Purr Data.<br>
> >> ><br>
> >> ><br>
> >> > Done :)<br>
> >> >><br>
> >> >><br>
> >> >> For the audio emulation library, I left a single piece of prior art in the repo.<br>
> >> >><br>
> >> >> Once you've cloned the Purr Data repo, have a look at<br>
> >> >> purr-data/externals/mmonoplayer<br>
> >> >> and see if you can figure out how to compile that C source file to<br>
> >> >> create an external binary<br>
> >> >> for Purr Data. It's a bit tricky given there is no build script or<br>
> >> >> help file. But I think it's a good exercise to<br>
> >> >> have a look at the interface for that class and play around with it in<br>
> >> >> Purr Data. Also, you'll probably<br>
> >> >> run into a lot of prior art like this which has minimal<br>
> >> >> documentation/build scripts. :)<br>
> >> ><br>
> >> ><br>
> >> > 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)<br>
> >> ><br>
> >> ><br>
> >> > 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.<br>
> >> ><br>
> >> > 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.<br>
> >><br>
> >> I'd advise throwing out the Makefile for now and compiling straight from gcc:<br>
> >><br>
> >> * you want to compile it as a shared library<br>
> >> * compile it to have position independent code (for example, on<br>
> >> aarch64 it won't load correctly if you don't do that)<br>
> >> * make sure there are no errors or even warnings<br>
> >><br>
> >> Now, when you try to test it do two things:<br>
> >><br>
> >> 1. Run Purr Data with -verbose flag: `pd-l2ork -verbose`<br>
> >> 2. After Purr Data starts up, click "Clear Console" in the "Edit" menu<br>
> >> of the main Pd window. (There's a handy little shortcut for it, too.)<br>
> >> 3. Now that your Pd window is clear go ahead and try to create "atari_2600~".<br>
> >><br>
> >> If it ends up broken, check the Pd window for external loading errors.<br>
> >><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> >><br>
> >> >> Some questions:<br>
> >> >><br>
> >> >> Would you want to use mostly Pd abstractions or external compiled<br>
> >> >> binaries for the library? Lots of<br>
> >> >> trade-offs there with speed, rapid prototyping, readability, etc.<br>
> >> ><br>
> >> ><br>
> >> >><br>
> >> >> 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).<br>
> >><br>
> >><br>
> >><br>
> >> Abstractions are more accessible-- that is, one can read them and<br>
> >> potentially change/fix them and they'll run on every platform without<br>
> >> recompile.<br>
> >><br>
> >> But for this kind of project there will be an enormous speed advantage<br>
> >> writing it in C.<br>
> >><br>
> >><br>
> >> ><br>
> >> ><br>
> >> >><br>
> >> >> What should the interfaces look like? You can have signal i/o, control<br>
> >> >> input with signal output, a mixture,<br>
> >> >> etc. Is there a common interface that may be reused within the library?<br>
> >> >><br>
> >> > 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.<br>
> >><br>
> >><br>
> >> I mean the interface consisting of inlets, outlets, and the class methods.<br>
> >><br>
> >><br>
> >> ><br>
> >> > 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?<br>
> >><br>
> >><br>
> >> There are pretty active forums for emulating vintage audio chips and<br>
> >> instruments. I would definitely check those to see what<br>
> >> the prior art looks like.<br>
> >><br>
> >> -Jonathan<br>
> >><br>
> >> ><br>
> >> ><br>
> >> >> If you're interested in that project then hopefully that's enough to<br>
> >> >> get started.<br>
> >> >><br>
> >> >> Feel free to post any more questions you may have here to the list.<br>
> >> >><br>
> >> >> Jonathan<br>
> >> >><br>
> >> >> ><br>
> >> >> > Thanks<br>
> >> >> ><br>
> >> >> > Alia<br>
> >> >> ><br>
> >> >> > _______________________________________________<br>
> >> >> > L2Ork-dev mailing list<br>
> >> >> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> >> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> >> >> _______________________________________________<br>
> >> >> L2Ork-dev mailing list<br>
> >> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > L2Ork-dev mailing list<br>
> >> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> >> _______________________________________________<br>
> >> L2Ork-dev mailing list<br>
> >> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> >> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > L2Ork-dev mailing list<br>
> > <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> > <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div>