Back to design page, or to main page.

Early notes and 2012 ideas

From a collection of 2011-2013 notes on the program and language (the program then named "sgensys"), where the thinking continued after the coding stopped in early 2012. {New 2020 thoughts italicized in brackets.}

The names of persons from whom I got a little feedback in 2012 are three who worked at LiU's IDA (computer science) department. At the time, I had been studying a bit of undergraduate theory, looking around the library, searched in general, and had a difficult time translating between the theory of programming languages and the track I had already begun to explore. In hindsight, it may have been more interesting to discuss the early project I already had in more detail with them.

When I revived the project years later, during an extended time as a jobless dropout going through an inner rollercoaster, I had forgotten many details of the 2012 knowledge, but could much more clearly see how my old experimenting related to bigger programming language concepts, no longer blinded by specifics of form. Later, I think a personal refresher on formal languages, automata theory, and compiler construction may come in handy.

Note that the word "operator" here refers to a FM synthesizer operator, i.e. a parametrized oscillator.

Main ideas list

New language and syntax:

• Read, study, and see how it works out.
• Preliminary ideas:
  • Voices implicit, not necessarily as in old version. (Make invisible at language level?)
    {Later thought: Deal with carrier sound sources in the language, make other aspects of voices implicit.}
  • Operator-related objects in language – requires more study to elaborate structure.
    {Later thought: I already did it from the start, in terms of one pre-defined class for instantiation, easily extended to providing several for further purposes.}
  • Applying more generic concepts of functions, expressions – enabling greater flexibility.
    {Later thought: Making lists or arrays more general in uses makes a building block for functions later, as lists/arrays with parametrized contents.}
  • Parser separated, creating proper parse tree, from the start. Unknown complete design.
    {Later thought: Simplifying the parser, and handling most processing outside it, is the most important part.}
  • Clear separation between imperative and other elements of language.
  • Scopes and nesting made more clearly defined, more strict, given greater role.
    {Later thought: It started out loosely experimented into the language.}
  • Spend some time studying functional programming languages for ideas, adopting whatever fits.
  • Make constructions for envelopes and dynamic variations as expressive as possible.
    {Later thought: Envelopes are like flexibly used devices, ramps are like array fill-and-use instructions, other things may be like such or otherwise.}
  • Allow "templates" of sound-defining objects, in some as-yet undefined form.
    {Later thought: Lists or arrays can hold contents for repeated insertion(s)/use(s). Extend to allow varying contents in using them...}
  • Flexible referencing/addressing/substitution.
• A speculative synthesis of ideas:
  • Functions as objects -> Operators as functions -> A unified, as yet unknown, syntax.
  • Using and combining functions in defining other functions. Simple, terse, unified syntax.
  • Allow flexible relational querying in specifying timing.
    {Later thought: Was a very vague idea.}
  • Reference without evaluation the imperative state in function-objects, values undetermined until evaluation.
    {Later thought: Much more generally, a more flexible language allows referencing things only given their full or final values later, as part of specifying new or larger expressions.}
  • Imperative state scope-dependent, scopes nested. Language details to be made flexible, and as practical as possible.
  • Evaluate function-objects according to current local state when actions are performed. (closures?)
• Haraldson's feedback:
  {Later thoughts: Advice not taken on how to be pragmatic instead of experimenting the way I did.}
  • "Play" with constructs using Lisp or similar without getting stuck in details.
  • Use tools instead of wasting half a year writing a parser by hand, if possible for the language.
  • [Suggestions for courses which could be useful.]
  • Don't get stuck in low-level thinking.
• Szalas' feedback:
  • Timing relation problem seems to fit constraint programming.
  • Integer (linear) programming, if it fits, has efficient algorithms.
• Further synthesis of ideas:
  • Relation to other objects – contraints? – can be generally applicable, not just to timing.
• Stavaker's feedback:
  • Write grammar, see problems that appear, and how it goes and where it leads.
  • [Book suggestions.]
  • [Course suggestions.]
• My own thoughts:
  • This cannot all be planned and designed in advance; [experimentation is needed].
  • Needing more experience thinking and working like an engineer, and broader understanding.
  • Once ideas are worked out a bit further, it may pay to ask for further feedback. Mainly, more of a feel and some perspective on what at present seems to remain is needed.

The remainder

Later pages described, firstly, ideas building on my old design about how to solve various problems seen, for extending or reworking the program as it then was. Such ideas had to do with timing, data structures for oscillators and their relations, and traversal. A useful part may be the thoughts on how to stereo-split only parts of an audio processing chain according to need, when something which some other things depend on is in stereo instead of in mono. Secondly, there were further lists departing from the old design with very abstract musings about a "new language", and work potentially leading to it were interspersed with some more practical ideas about reworking the old program.

Comparing the 2020 program to the more practical 2012 redesign ideas, the language and work done by the parser simply hasn't grown to fit the sketched-out ideas of a more full-featured symbol table, and a bit more. But an antiquated idea of scanner input buffering from the old version of the so-called Dragon Book, copied into my notes, made its way in a mutated form into the file module used in my code. The practical notes also include the simple idea of pre-traversing oscillator connection graphs "in the compiler" (after parsing), and scheduling audio input and output blocks/buffers into a flat ordered list for audio generation to use afterwards.

Text available under .