SuperCollider 4: First Thoughts

Development
315

I want to talk about the simpler syntax of sclang, examples of help documents and others. It could be summarised as accessibility for non-programmers (or non-computer scientists):

  1. Each element of the instances of the subclasses of the abstract collection is separated by a comma. However, many users add a space after the comma, and most of the examples in the Supercollider help documents add a space after each comma. Wouldn’t it often be simpler to separate the elements by whitespace, as in Max and pd?

  2. Lots of parentheses make code reading/writing more complicated. Could indentation be made part of the syntax? Then parentheses could be omitted, I think.

  3. Should local scope variables be declared absolutely by the var keyword (after arg) at the beginning of a block of code? I think it is not necessary if sclang uses indentation as a syntactic element.

  4. Is capitalising the class name absolutely necessary? A lot of typos come from capitalising. I think the class name could be lowercased if sclang does not accept the variable name that is identical to a class name.

  5. SC allows multiple styles. This makes the learning curve harder for beginners and people not well-trained in computer science. How about keeping the simpler ones alive and deprecating the others in the future?

  6. Could the error messages about the wrong type (= wrong class in this case, I think) of variables or arguments be more intuitive? It is a bit difficult to find the exact point of error when I unknowingly change the type of a variable or argument.

  7. Could SC-Plugin be included in the SC binary by default?

  8. How about forcing the quark to be specified as a header in a block of code? We already have "path_to_a_quark".include. Could it be slightly modified, similar to import in Python or include in C? Of course, sclang should not compile any of the quarks at boot time, but compile the specific quark when evaluating selected blocks of code.

  9. Can the Python’s way of ‘multiline strings’, i.e. '''...''' or """...""" be adopted? It will reduce a lot of typing and "...".quote.

  10. Can SCDoc support more HTML elements? At the moment, it is somewhat limited. It is useful to make the help document more comprehensible and improve readability.

  11. I feel that the current examples are written from a very technical perspective. Could the examples in the help document be more useful for composition and sound design?

  12. The above points could be simplified as follows: Could SuperCollider 4 be made more non-programer-friendly?
    I have experience of teaching SuperCollider, FScape, Eisenkraut, Reaper, Audition, Samplitude Silver, Audacity, Paul’s Extreme Time Stretch to students of composition, instruments, business, media communication and computer science.
    (I have had no enough opportunity to teach Max to non-musicians. For composition students, I have experience of teaching SuperCollider Max, Finale, Sibelius and Max.)
    Most students have difficulty learning SuperCollider, with the exception of computer science majors, especially those who already have programming experience in at least two programming languages such as C, C++, Python, R, etc.
    Interestingly, some of them, who learn SuperCollider very quickly and write well-written code, do not really understand the acoustic and compositional basics underneath the code. I think this shows that SuperCollider is somewhat biased towards the technical aspect, especially programming skills.

  13. I love SuperCollider more than Max, but I have to use Max when working with others. Sometimes I miss a Quark that could match the Bach package for Max or OpenMusic. I hope that sclang will have robust support for musicXML. To do this, we should have a unified style of musical notation like Guido or LyliPond.

2 Likes