[L2Ork-dev] GSOC 2020

Wed Mar 18 20:36:26 EDT 2020

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