› ›

Review for proposals

coolutpalcoolutpal
edited March 2015 in Summer of Code 2015

Hey I have submitted 2 proposals related to processing-sound

https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/coolutpaljha/5718998062727168

https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/coolutpaljha/5738600293466112

could you guys have a look at it and provide me feedback accordingly also could you also communicate to wilm regarding the same .

Comments

  • shiffmanshiffman

    We'll provide feedback on your proposals on the melange site itself should we have questions or thoughts. If you would like feedback from the community here you'll need to paste the contents of your proposal as I believe the melange site is not publicly visible.

  • coolutpalcoolutpal

    Alright my second proposal makes much more sense according to me so I am gonna go ahead and paste my proposal . Tell me do I need to provide more info or description accordingly .. The links as of now won't be visible as it's a feature of melange site .

    Organization: The Processing Foundation

    Abstract: The idea is to add Audioloop(AudioInput() and AudioOutput() ) which would run on sampleRate/bufferRate . This would be mainly useful for applications which use sound as their base for processing. Draw loop (which runs on frame rate) would still exist as a part of the processing's core package . Audio loop would just be an addition.

    Additional info: https://github.com/coolutpal

                               Sample Rate Loops
         Proposal For Processing-Sound -- GSOC 2015

                                Introduction

    Presently all of the sketches are rendered using draw loop which is control rate or say frame rate dependent .The present draw loop as it is control dependent is prone to lot of jitter and little bit of noise . This would work just fine for applications rendering 2D sketches but wouldn't be beneficial for those applications which require sound analysis . For those applications audio rate needs to implemented as a different scheduling loop. The idea is to implement Sample rate or Audio rate as a different scheduling loop for processing's sound library .

                                      Project Goals

    1. Making audio applications work jitter free. 2. Option of selecting between audio loop and draw loop depending upon priorities of the application. 3. Developing a tool which would help someone determine what loop fits in the best using various performance benchmarks.

                                     Project benefits

    1. Scheduling sound in different loop altogether would in a way remove it's dependency from existing draw loop . The work now can altogether be carried out separately . 2. The programmer would have option for setting Various Sample rates,Size of the buffer,Number of channels which wouldn't have been possible if only draw loop existed. 3.The existing methcla library would still remain light as only one c++ library would be added (RtAudio) which on it's own is light and fast just like Methcla. Implementation details

    The idea is inspired from OpenFrameworks after wilm told me to look into it . OpenFrameworks use 3 classes which makes addition of further sound loops possible . -->ofBaseSoundInput -->ofBaseSoundOutput -->ofSoundBuffer The top 2 classes help in addition of 2 loops to the main application -->audioIn() -->audioOut()

    Now all of this is accomplished using API for RtAudio in openFrameworks . RtAudio is a pure c++ library whose API is commonly made available . This RtAudio library helps Audio loop (audioIn loop and audioOut loop) to run on a sample rate or buffer size. Now in openFrameworks a static c++ library is used (libRtAudio.a) .

    Now I can use this static library along with API for RtAudio (both being c++) wrap it up using jni wrapper for processing part . As long as I can see this part as such can't be accomplished in pure java and a RtAudio library has to be used . Therefore intervention of jni is required . However the existing methcla interface would still be light as RTAudio lib is also pretty light.

                                          Availability

    I would be done with my end semester examinations till 2nd may and therefore be available for the entire time period .Should my proposal be accepted I would completely devote my devote my summer to make processing even more better.

                                         TIMELINE


-->Community bonding period
     .Get to know better about processing's core package as this would be mainly the package required to implement a separate loop
      for audio based applications.
-->First coding period
     .Identifying various dependencies to draw loop and outlining a sketch to move those dependencies to a separate audio loop
     .Changing the core package removing dependencies from the draw loop and porting this package to processing-audio repository.
-->Second coding period
     .Proposing an initial layout for audio loop . Determining the benchmarks on which it would work upon.
     .Implementing the audio loop from the scratch based on Audio rate and adding dependencies identified from the first
      coding period.
-->Third coding period
     .Adding explicit interface to be provided to the user(based on his experience)
     .Exploration of further ideas.                  
-->Fourth coding period
     .Cleaning up code removing unnecessary comments and performing various unit test
     .Adding documentation                                                        

                                     About me

    Hello , I am utpal studying computer science and Engineering from MNNIT Allahabad. I have been a long time java user .Contribution to open source is not something new to me as I have done it in past . I have been a member of open source organization Catrobat subproject Musicdroid for quite a while now . .The project aims at creating MIDI sound in real time which in turn demonstrates that I have understanding of all basic sound based parameters.

    I have been using for quite a while now . I have been following processing for quite a while now and accordingly possess familiarity with processing's code(Mostly with that of the core package as that is the only package required for processing-sound). The existing methcla interface for processing-sound is what amazes me the most being fast and light . I am familiar with the build instructions for both processing's main repository along with processing's sound repository .

    I have submitted 2 pull requests one of which has been merged into processing sound directory Remove import of unnecessary packages and another one which is still pending to be reviewed by the the PR's Added a confirmation Dialog to About Window.

    If any project PR be interested in my Idea I would happily provide more info regarding my thought process and the work which I am doing in it .

    Email-coolutpaljha@gmail.com

Sign In or Register to comment.