SoundComp (https://sourceforge.net/p/soundcomp) will be a compiler tool that translates a textual description of a piece of sound into respective sound files.
There was a longer almost inactive phase but we are getting active again.
SoundComp mainly consists of 3 parts:
- 1. a scanner+parser that creates a tree structure of sound related objects from the textual description
- 2. a collection of signal processing objects with a uniform interface that can be combined to produce almost any kind of sound signals
- 3. a control logic that cares about combining, parametrizing and triggering the signal processing objects according to the content of the parse tree
The whole thing is planned to be platform independent (except maybe for few, very limited platform specific extensions). With previous versions we had the existing test code running on different permutations of unixoid/windows systems in 32 and 64 bit, on little and big endian platforms.
is almost pure java code, sustained by jflex/byacc/j. Large parts of this are already done. This is almost completely straightforward, once you know how to handle the parser generator stuff. The ongoing design of 3., or addition of more elements in 2. sometimes require to add companion parts to 1, and also a lot of room is left for pre-compilation optimization (e.g. constants extraction).
is a mixture of java and c++ code. The signal processing routines are pure c++, a boilerplate code scheme makes this accessible from java via JNI. The objects are designed so after they have been connected by the control logic, they mostly can call each other without a need to jump back and forth to and from java. Here we have already done enough to produce sound files, but significant work is still to be done. Test cases exist that explain and prove how this object network is supposed to work. Signal processing skills are a real plus if you want to help out here, but if you're inexperienced you may learn on the job. Apart from understanding signal processing, due to the (almost completely) uniform interface of all these objects, this is quite easy to grasp. For maintaining maximum portability we deliberately do not want to exploit newer c++ features, so being used to "antique style" c++ is ok.
the control logic is mainly in java. Here we lack large parts even in design. This is expected to become the most difficult part of the whole thing. Some knowledge about or interest in music and its timing requirements, and being willing to discuss architectural issues will definitely help here.
Possible future extensions could be:
- supporting more file formats: wav, ape, flac already done; ogg, mp3 (now that the patent issues are history) would be neat. It is clear that this is purely for convenience as the existing options to create lossless files suffice when you always can convert the files later on.
- better support for files with more than 2 channels.
- adding more signal processing elements that haven't been thought of yet.
- optimizing the whole control logic for making use of multicore CPUs. This has already begun.
- optimizing the signal processing code in certain platform specific parts if assembler or GPU code proves to do the same things significantly faster. Note that it still needs to be platform independent, i.e. the "general c++ case" must always work on machines for which no optimized code exists.
- real time extensions to allow to read or write to audio hardware in real time on systems that are powerful enough. Note that the default operation mode is "offline" and that compiling a text can use much more time than the playing time of the resulting file.
- on real time enabled systems, providing standard interfaces for other programs (e.g. for VST hosts)
- allow triggering from MIDI. This can either be by using MIDI as a regular signal input or on systems for which MIDI interfaces exist, also by directly using this designated MIDI hardware. In such a system, SoundComp could be a MIDI synthesizer/vocoder.
The main development option is eclipse (with JDT and CDT used in a combined type project). However certain development environment is not exactly required - as long as you can compile java and c++ for the same platform and run tests on thiscombination, it is fine. Examples of past successful test systems are WinXP x64,Win7 32bit, webOS on Palm Pre, Solaris on Sun Ultrastation, MacOS 10.4 (PPC). You may also try to get it running on an android or iOS device (e.g. with embedded java) - on both it could even be possible to develop on the target device like it worked on the Palm Pre.
You may apply for any of the parts (or more than one of them). As it is a free time project you need not be able to spend time for it every day, but at least foresee that you can show signs of activity in reasonable frequency. Please attempt to specify your experience in the relevant field. Use the message button on my profile page to contact me.
Best regards
Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would love to assist you for this work. Please send me an emaila at garry3.efi@gmail.com or join me on Skype: cis.garry so that we can discuss in precise.
Thank you
Garry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SoundComp (https://sourceforge.net/p/soundcomp) will be a compiler tool that translates a textual description of a piece of sound into respective sound files.
There was a longer almost inactive phase but we are getting active again.
SoundComp mainly consists of 3 parts:
- 1. a scanner+parser that creates a tree structure of sound related objects from the textual description
- 2. a collection of signal processing objects with a uniform interface that can be combined to produce almost any kind of sound signals
- 3. a control logic that cares about combining, parametrizing and triggering the signal processing objects according to the content of the parse tree
The whole thing is planned to be platform independent (except maybe for few, very limited platform specific extensions). With previous versions we had the existing test code running on different permutations of unixoid/windows systems in 32 and 64 bit, on little and big endian platforms.
is almost pure java code, sustained by jflex/byacc/j. Large parts of this are already done. This is almost completely straightforward, once you know how to handle the parser generator stuff. The ongoing design of 3., or addition of more elements in 2. sometimes require to add companion parts to 1, and also a lot of room is left for pre-compilation optimization (e.g. constants extraction).
is a mixture of java and c++ code. The signal processing routines are pure c++, a boilerplate code scheme makes this accessible from java via JNI. The objects are designed so after they have been connected by the control logic, they mostly can call each other without a need to jump back and forth to and from java. Here we have already done enough to produce sound files, but significant work is still to be done. Test cases exist that explain and prove how this object network is supposed to work. Signal processing skills are a real plus if you want to help out here, but if you're inexperienced you may learn on the job. Apart from understanding signal processing, due to the (almost completely) uniform interface of all these objects, this is quite easy to grasp. For maintaining maximum portability we deliberately do not want to exploit newer c++ features, so being used to "antique style" c++ is ok.
the control logic is mainly in java. Here we lack large parts even in design. This is expected to become the most difficult part of the whole thing. Some knowledge about or interest in music and its timing requirements, and being willing to discuss architectural issues will definitely help here.
Possible future extensions could be:
- supporting more file formats: wav, ape, flac already done; ogg, mp3 (now that the patent issues are history) would be neat. It is clear that this is purely for convenience as the existing options to create lossless files suffice when you always can convert the files later on.
- better support for files with more than 2 channels.
- adding more signal processing elements that haven't been thought of yet.
- optimizing the whole control logic for making use of multicore CPUs. This has already begun.
- optimizing the signal processing code in certain platform specific parts if assembler or GPU code proves to do the same things significantly faster. Note that it still needs to be platform independent, i.e. the "general c++ case" must always work on machines for which no optimized code exists.
- real time extensions to allow to read or write to audio hardware in real time on systems that are powerful enough. Note that the default operation mode is "offline" and that compiling a text can use much more time than the playing time of the resulting file.
- on real time enabled systems, providing standard interfaces for other programs (e.g. for VST hosts)
- allow triggering from MIDI. This can either be by using MIDI as a regular signal input or on systems for which MIDI interfaces exist, also by directly using this designated MIDI hardware. In such a system, SoundComp could be a MIDI synthesizer/vocoder.
The main development option is eclipse (with JDT and CDT used in a combined type project). However certain development environment is not exactly required - as long as you can compile java and c++ for the same platform and run tests on thiscombination, it is fine. Examples of past successful test systems are WinXP x64,Win7 32bit, webOS on Palm Pre, Solaris on Sun Ultrastation, MacOS 10.4 (PPC). You may also try to get it running on an android or iOS device (e.g. with embedded java) - on both it could even be possible to develop on the target device like it worked on the Palm Pre.
You may apply for any of the parts (or more than one of them). As it is a free time project you need not be able to spend time for it every day, but at least foresee that you can show signs of activity in reasonable frequency. Please attempt to specify your experience in the relevant field. Use the message button on my profile page to contact me.
Best regards
Jan
Hi,
I would be intrested in this...and would be able to assist you.
You can reach me on andrewjohnson56782@gmail.com
Best Wishes
Andrew
Hello Jan
Greetings!
I would love to assist you for this work. Please send me an emaila at garry3.efi@gmail.com or join me on Skype: cis.garry so that we can discuss in precise.
Thank you
Garry