<div dir="ltr">Hello Jonathan, <div>Thanks for the review. The pointer thing in the aim was a typo on my part and I have already corrected it in my proposal draft. </div><div><br></div><div>About the external libraries, I would like to stick to the first approach that you mentioned. i.e prioritise all those libraries that get loaded by default by the libdir_loader. We can extend this once the project gets selected, to the other approaches that you mentioned.</div><div>Below is the list of externals that get loaded, in order.<br></div><div><ul><li>cyclone<br></li><li><span id="gmail-docs-internal-guid-b9f064d0-6159-b5ea-56fe-d38735451a4a"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">zexy</span></span><br></li><li><span id="gmail-docs-internal-guid-b9f064d0-6159-b5ea-56fe-d38735451a4a"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">creb</span></span><br></li><li><span id="gmail-docs-internal-guid-b9f064d0-6159-b5ea-56fe-d38735451a4a"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">cxc</span></span><br></li><li><span id="gmail-docs-internal-guid-b9f064d0-6159-b5ea-56fe-d38735451a4a"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">iemlib</span></span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">mapping</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">markex</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">maxlib</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">memento</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">mjlib</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">motex</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">oscx</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pddp</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pdogg</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pixeltango</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">rradical</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">sigpack</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">smlib</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">unauthorized</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pan</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">hcs</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">jmmmp</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">ext13</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">ggee</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">ekext</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">disis</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">lyonpotpourri</span><br></li><li><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">pdlua</span><br></li></ul></div><div>Could you please tell me if this list was missing anything?<br></div><div><font color="#000000" face="Arial"><span style="white-space:pre-wrap"><br></span></font></div><div><font color="#000000" face="Arial"><span style="white-space:pre-wrap">Also I had one more doubt regarding this, (this may be a pretty beginner doubt)</span></font></div><div><font color="#000000" face="Arial"><span style="white-space:pre-wrap"><br></span></font></div><div><span style="white-space:pre-wrap;color:rgb(0,0,0);font-family:Arial">1) When I start purr-data after loading the pd-lua library the console throws an </span><i style="white-space:pre-wrap;color:rgb(0,0,0);font-family:Arial">error:audio I/O dropout. </i></div><div><img src="cid:ii_jf7z0n2x0_162616c8e9a4fb59" width="459" height="63"></div><div> </div><div>2) The programs work fine though.</div><div><img src="cid:ii_jf7z21tr1_162616d90c2ff10a" width="384" height="74"><br><br></div><div>3) Also, on running the external_tests.pd file it shows that all tests are passing.</div><div><img src="cid:ii_jf7z4zhd2_162616fa68f29efe" width="334" height="49"></div><div>I was not able to figure out a reason behind this, It would be great, if you could please help me with this.<br></div><div><br></div><div>Thanks ,</div><div><br></div><div>Sincerely,</div><div>Pranay Gupta</div><div><br></div><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 2:52 AM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Pranay,<br>
<br>
On Sun, Mar 25, 2018 at 4:39 PM, pranay gupta<br>
<<a href="mailto:pranayguptastudent@gmail.com">pranayguptastudent@gmail.com</a>> wrote:<br>
> Hello Jonathan,<br>
<span class="">> I have started with the proposal and I had a few doubts,<br>
> I wanted to ask you if there is a specific list of external libraries that<br>
> you want me to include in this project?<br>
<br>
</span>I don't have a specific list at the moment. However there are a<br>
few ways I can think of to filter it down to a manageable set.<br>
<br>
The first is to focus on the libraries which get loaded by default in<br>
the current version of Purr Data we ship. Currently each of these<br>
libraries gets loaded by the "libdir loader" which outputs a message<br>
to the console at startup:<br>
<br>
libdir_loader: added 'hcs' to the global objectclass path<br>
<br>
Second would be to look at the libraries that get installed using<br>
the new toplevel make target `make light` and prioritize those,<br>
as they are the minimum number needed to have a minimal<br>
install.<br>
<br>
Third would be for the users and devs to tell us which ones<br>
they prioritize. But that would be something to do later if the<br>
project gets accepted and work on the core has begun.<br>
<br>
Finally, I think checking c and c++ files in purr-data/externals<br>
to see how many currently use "float" instead of "t_float" atm.<br>
<span class=""><br>
> Also can you please explain to me a little bit about the testing of<br>
> purr-data and the in general?<br>
<br>
</span>Currently the tests are quite basic-- we check to make sure that each<br>
external library will properly load, and that we can instantiate objects<br>
from each library without crashes or memory error (using valgrind).<br>
<br>
Without too much trouble, this can be extended to make sure that<br>
each external library which performs DSP computation can actually<br>
do so without crashing or memory leaks.<br>
<br>
There was a project idea for more robust testing but that obviously hasn't<br>
been implemented yet.<br>
<span class=""><br>
> Also I have attached a link to my proposal draft below. Could you please<br>
> review it and tell me if I am going in the right direction with it and how<br>
> can I further improve it?<br>
<br>
</span>That definitely looks like the right direction to me.<br>
<br>
Under "Aim": you refer to "single precision and double precision<br>
pointer." But the<br>
fundamental change is to the underlying type for representing numbers in Purr<br>
Data, not the pointer size. (Although pointer sizes will obviously change as a<br>
consequence of this.)<br>
<br>
I'm mainly concerned with avoiding ambiguity between this and, say, a project<br>
that aims to change an app to run on an architecture where the word size is<br>
twice as large.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Jonathan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks.<br>
><br>
> Link to proposal<br>
><br>
> Sincerely,<br>
> Pranay Gupta<br>
><br>
> On Sat, Mar 24, 2018 at 3:27 AM, Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com">jon.w.wilkes@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Pranay,<br>
>><br>
>> I'll respond point by point for clarity below.<br>
>><br>
>> On Fri, Mar 23, 2018 at 1:33 PM, pranay gupta<br>
>> <<a href="mailto:pranayguptastudent@gmail.com">pranayguptastudent@gmail.com</a>> wrote:<br>
>> > Hello Jonathan,<br>
>> ><br>
>> > I have gone through all the mails and tried to go through some files<br>
>> > also,<br>
>> > what I understood was that, wherever algorithms have been implemented<br>
>> > using<br>
>> > single precision I have to change that to double precision and some<br>
>> > external<br>
>> > libraries that are being called in the core functions might also need<br>
>> > changes.<br>
>><br>
>> There are basically two categories of work: the core and the external<br>
>> libraries (essentially plugins) which ship with Purr Data.<br>
>><br>
>> For the core there is prior art with the Pd Double project which can<br>
>> be found here:<br>
>><br>
>> <a href="https://github.com/pd-projects/pd-double" rel="noreferrer" target="_blank">https://github.com/pd-<wbr>projects/pd-double</a><br>
>><br>
>> One of the challenges here is that our core code has diverged<br>
>> substantially<br>
>> from that codebase. However, the overall structure of the code is still<br>
>> very<br>
>> similar as are the core DSP algorithms and message dispatching/parsing<br>
>> code.<br>
>><br>
>> The second category-- external libraries-- is a bit more<br>
>> difficult because the quality varies considerably for each library.<br>
>> Some of them are straightfoward and just require recompiling<br>
>> and testing. Some freely mix "t_float" and "float", probably under<br>
>> the assumption that the "t_float" type would never change. Still<br>
>> others may use type-punning or other tricks that depend on<br>
>> "t_float" being equal to "float".<br>
>><br>
>> I think a workable approach here is to prioritize a handful of these<br>
>> libraries to make ready for double precision and then document<br>
>> common types of problems for the rest. That is to say I don't think<br>
>> this project idea needs to aim to make every single library ready<br>
>> for double precision.<br>
>><br>
>> > Also, support for backward compatibility, and an option to the<br>
>> > users whether to run purr date using single precision or double<br>
>> > precision<br>
>> > should be added.<br>
>><br>
>> I don't think this is possible. The public API essentially<br>
>> requires external library developers to typecast raw pointers to<br>
>> arrays of t_float. So either everything is compiled with a<br>
>> uniform t_float value, or you get either:<br>
>><br>
>> a) data corruption (double-precision mode with single-instance library<br>
>> loaded)<br>
>> b) data corruption and buffer overflow (single-precision mode with<br>
>> double-precision lib)<br>
>><br>
>> I'm actually just guessing on the type of errors-- there may be<br>
>> some part of the API I'm forgetting which causes crashes in both cases.<br>
>><br>
>> > And in case any of the single precision or double precision<br>
>> > catches an error, the one that works has to be used.<br>
>><br>
>> As above, I don't think that's possible. But we can test both<br>
>> precision types in the CI (perhaps switching out one of the older<br>
>> Ubuntu runners for a single precision build runner).<br>
>><br>
>> > Also, you mentioned<br>
>> > about single precision binaries performing better with better algorithms<br>
>> > as<br>
>> > compared to double precision with a basic implementation when compared<br>
>> > to<br>
>> > vanilla binaries as per the results of some tests.<br>
>><br>
>> I didn't measure any difference on my Rockchip Chromebook.<br>
>> But I'd say it would be a good idea to set up some performance<br>
>> tests to measure the differences.<br>
>><br>
>> ><br>
>> > I had a few doubts regarding the project,<br>
>> ><br>
>> > 1) What should be the main points that I should focus more on in my<br>
>> > proposal?<br>
>><br>
>> Probably on making it possible to compile Purr Data for both types<br>
>> of precision, to make sure the core runs reliably in each case, and<br>
>> to make sure some of the more popular external libraries run reliably<br>
>> in each and document a process for testing/working on the rest.<br>
>><br>
>> ><br>
>> > 2) Also will any of the algorithms that are already implemented require<br>
>> > any<br>
>> > implementation changes when adding support for double precision?<br>
>><br>
>> In the core-- yes. These were replaced and tested with new implementations<br>
>> in the pd double project. I *think* they are the files assigned to the<br>
>> TYPE_PUNNING_SRC variable in purr-data/pd/src/<a href="http://makefile.in" rel="noreferrer" target="_blank">makefile.in</a>.<br>
>><br>
>> ><br>
>> > 3) And it would be really helpful if you could provide me a few<br>
>> > resources<br>
>> > that might make it easier for me to understand the project better?<br>
>><br>
>> General resources or specific to this project idea?<br>
>><br>
>> For the former-- here's a great resource Albert created:<br>
>><br>
>> <a href="https://agraef.github.io/purr-data-intro/" rel="noreferrer" target="_blank">https://agraef.github.io/purr-<wbr>data-intro/</a><br>
>><br>
>> Let us know if you have any more questions.<br>
>><br>
>> -Jonathan<br>
>> ______________________________<wbr>_________________<br>
>> L2Ork-dev mailing list<br>
>> <a href="mailto:L2Ork-dev@disis.music.vt.edu">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/<wbr>listinfo/l2ork-dev</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu">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/<wbr>listinfo/l2ork-dev</a><br>
______________________________<wbr>_________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu">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/<wbr>listinfo/l2ork-dev</a></div></div></blockquote></div><br></div>