Re: [SoundComp-Develop] Design discussion, call for arms :-)

[Uri Even-C. <ur...@sp...>]

On Mon, Dec 28, 2009 at 8:11 PM, js...@ya... <js...@ya...> wrote:
> This is some general information for you all, and a "call to arms".
>
>
> As you might have already understood, SoundComp consists of 3 main parts (the rest is expected to be almost negligible right now):
> (1) Signal processing
> (2) Language parser
> (3) Control logic
>
> (1) is relatively straightforward. Large parts already exist. It is not necessary that all team members understand the mathematical backgrounds of digital signal processing, so I will not go further into that unless someone is picking something from there to implement.
> A basic concept is that each algorithm is encapsulated in a "ProcessElement" object that fulfills the following basic logic:
>
> It offers an unlimited number of inputs (data destinations) and outputs (data sources), depending on the algorithm
> Its input and output properties can be queried (with countable few exceptions, being mixers and wave files).
> It has a method for setting the sources connected to its destinations (i.e. where does the information for its inputs come from). This method is called for assembling the logical structure of the whole process. During processing, each ProcessElement gathers the information it needs on its own, without the assistance of any controlling instance.
> When everything is connected, all ProcessElements are collected in a so-called AdvancerRegistry. This
> entity takes care of proceeding from one sample value to the next, it
> calls the advanceState() and advanceOutput() method of all elements in a random order. The order does not matter for the result since first all next-sample outputs are calculated without propagating the information, so all value queries still are based on the previous sample value. After that, all states are propagated to the element outputs atomically.
> This procedure is more or less consistent for all types of ProcessElements, so neither ProcessElements nor the AdvancerRegistry need any information about the types of the connected objects.
>
> The source and destination data can be of different types:
>
> - constant numbers
> - number streams (i.e. numbers that change from sample to sample, without fixed limit)
> - number series (a collection of numbers with a well-defined finite count) that usually do not change from sample to sample
> - complex tables (a table with an index and up to two numbers (real and imaginary part) associated to each index key). If the index is numeric, value query may interpolate if no value is defined for the exact key. The index may as well be a piece of text, no interpolation is then carried out.
>
> There is already a structure layed out that allows for implementation of ProcessElements in either Java or C++ and the connections work also cross-language. Mostly, it is easier to get something running in Java, in the long run we will probably port almost all of this to C++ for performance reasons.
>
> (2) Here some definition work is in progress and I hope to get some input, mainly from Uri.
>
> The language should be extremely flexible and still easy to use. That means we should have meaningful defaults everywhere, but should be able to change every parameter at any point in the piece of music.
> Also, the language should be easily extensible. Since we will insert more and more ProcessElement types, adding those should not touch the basics of the language too much.
>
> The element that I am going to define first are scales. The default will be the ubiquitary well-tempered 440Hz based scale with note names as A1, c#5 and the like. But the user will as well be allowed to use note names like "do, re, mi, fa, sol" and assign any base frequencies to those. It is even possible to have for example g-flat and f-sharp being different notes, as they really are in natural scales. Only the welltempered scale unifies this kind of note pairs.
>
> Then we should define how to write melodies and chords. Again, it should be extremely flexible, that is, of course the self-defined notes should work as easy as the predefined. And it should be easily possible to alter tempo and rhythm everywhere. The user should not be limited to a certain number of note lengths, but virtually everything should be possible here - but the "regular" power-of-2-based values again should be easy to write.
>
> After that, we need a way to specify sounds, instruments etc. Basically, this is a way of writing how to connect the different ProcessElements and provide them with parameters. Also, these parameters (as much as technically possible) should be able to change everywhere within the piece of music. I consider that part of the language to be the easiest to specify.
> I have the idea to have SoundComp being extensible by external signal processing modules as an addition to the ones compiled in as standard without recompiling SoundComp. This also means that accessing ProcessElements may need a very generic syntax, so adding modules does not require a language/parser change. Such a module would then consist of a .class/.jar file and a .dll/.so, just like SoundComp itself.
>
> What already has been implemented to a large extent is the preprocessor. It works similar to the preprocessor of the C/C++ language:
> with (at the start of a line):
> - #include, it is possible to insert external files into the compiled text
> - #define, it is possible to specify a text template that can be reused later on as a kind of abbreviation. These templates (macros) can have parameters whose values can be specified on use.
> - #undef, it is possible to forget a previously defined macro. A macro can never be redefined in a context where it is already defined.
> - #ifdef ... #else ... #endif, it is possible to use a certain part of the text only if a certain macro is defined. #ifndef does the exact opposite.
>
> With these preprocessor commands, it is even possible to conditionally include different sound libraries (as an #include between #ifdef and #endif is also subject to the condition).
>
> Not working right now, but planned is:
> - #if <expression> ... #else ... #endif, it is possible to use a certain part of the text only if <expression> evaluates to anything else than undefined or zero.
>
> The preprocessor will need an intensive code review as the code quality is less than what I'd like, but I keep that for later as I am glad it works and want to do other stuff first.
>
> (3) is probably the most sophisticated part. Here also, I am glad for ideas.
>
> The parser will provide a whole bunch of instrument and effect processes, and a set of events (note on, note off, parameter change), maybe already with associated time stamps.
> The control logic will have to consecutively call AdvanceRegistry.advanceAll(). When certain timestamps are reached, events must be fired. Here it will become complex, as these events may have numerous consequences: voices and instruments and other processes being created or terminated from the templates that the parser provides etc.
> This is probably the point where we will spend the most thoughts and hopefully discussion. I have some basic requirements for this, too, but let's do some parts of the language first.
>
> I hope not to have confused you all... best regards
>
> Jan

Can you send me the source code of SoundComp, or let me know how I
download them?  I want to view the project.  Also, is there a running
version for Windows XP?

Right now, I don't have any feedback related to SoundComp.  I find it
difficult to read all your messages, but I read this one :-) .  I
think your description is fine.

Uri Even-Chen
Mobile Phone: +972-50-9007559
E-mail: ur...@sp...
Blog: http://www.speedy.net/uri/blog/