SuperCollider 4: First Thoughts

Also in 2013 the discussion was still going on:
https://listarc.cal.bham.ac.uk/lists/sc-dev-2013/msg51129.html

BTW: The updated link to the 2006 post is this:

https://listarc.cal.bham.ac.uk/lists/sc-users-2006/msg04538.html

But my absolute favourite – I still remember reading it – was this one on APRIL 1 2009:

https://listarc.cal.bham.ac.uk/lists/sc-users-2009/msg50910.html

… garbage recycling … brilliant !

4 Likes

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

Sure. An important idea here is disambiguation – a big word meaning that any syntax must have one and only one meaning, and if there is any possible confusion, the language design needs to use syntax to tell different meanings apart.

An example in SC is the requirement to use parentheses around expressions for argument defaults in |arg| syntax:

f = { |a b| a };  // OK

f = { |a = 0, b = 0| a + b };

f = { |a 0 b 0| a + b };  // OK

f = { arg a = 0, b = a*2; a + b };  // OK

f = { |a = 0, b = (a*2)| a + b };  // OK

f = { |a = 0, b = a*2| a + b };  // not OK

The last one is not OK because | could have two meanings: it could end the argument block, or it could be a bitwise-OR binary operator. What is b? Is it a*2 or is it a * 2 | a + b? Well, “obviously” not the latter because then the argument block isn’t closed – but to determine this, the compiler would have to scan forward to find the presence or absence of another | token, and then go back to apply that inference. This is veeerrryyyy tricky, and it also doesn’t work for e.g. f = { | a b | c | d } – is that args a b and an expression c | d, or a = b | c and return d?

So SC makes it illegal to simplify the syntax here – because if it did simplify, you would run into cases where it’s impossible to determine the meaning. The parentheses make it clear.

In Max/Pd, lists are atoms (numbers or symbols). In SC, array elements are expressions:

[a + 2, b - 5]

vs

[ a + 2 b - 5 ] // yikes

I guess you could say “maybe sometimes the commas could be left out,” but that conflicts with #5’s call to cut back on multiple styles.

The Python way. One way to check it out is to try it:

SynthDef
	\test
	def  // bc, also no braces for functions I guess
		out = \out.kr
		freq = \freq.kr
		Out.ar
			out
			SinOsc.ar
				freq

(next statement)

It could potentially be made to work, but I’m not sure it’s more friendly.

That’s been discussed. Pretty much everyone wants that requirement to be relaxed :grin:

Do you mean to accept sinOsc or sinosc or sINOsc all as equivalents of SinOsc? I can imagine practical difficulties with that.

We actually have coding style guidelines – one problem is that new programmers are already overwhelmed with syntax and concepts, and may not yet understand why consistent styling is good for readability. So the people who need readability the most, do it the least.

The type system discussion – lots and lots about this, in this thread.

I’m of two minds about it. We get a lot of benefit from runtime dispatch (duck typing), but that benefit is easy to overlook. At the same time, getting the error six stack frames down is confusing.

Currently, adding a quark requires recompiling the class library. If we could load classes dynamically, then it would be possible.

I’m out of time for now, but the other points are thoughtful – may come back to them later.

hjh

No, none of the things you have listed should be considered equivalent.
However, I would like to use sinOsc instead of SinOsc.
By capitalising the class name, I just mean that capitalising the first character of the class name would be redundant and not necessary, because sclang may give an error message if a user uses a class name as a variable.

I agree with the other things you mentioned!

Especially, I sometimes use the elements of array with complicated expression, but I have considered them as atom! Thanks for the explanation!

Hi all please join discussion of the shape of future development efforts here: The Future of SuperCollider Development Efforts

1 Like

Nim is style insensitive / style agnostic, it actually works.

The following is my attempt to do that. It is written as a function and should be revised. The code structure is not so elegant and it could not be so optimised for CPU and memory usage:

I realised that a common convention for writing musical notation should precede musicXML export while doing this attempt.

1 Like

It would also be nice if the post window could post multimedia data such as plotting, rendered music xml, web page, video, image, etc. Would this be possible?

The console is a text interface. Why would it need to render a web page or play a video!? Do you know of a terminal that does this?

Of course, there are situations where you want to plot, render music XML, show a webpage or play a window, but this should be done in the GUI (= graphical user interface)!

Experimenting with the sclang kernel for Jupyter suddenly brought this question to my mind.

This got me thinking about jit.pwindow and jit.window in Max as well. The Max console can only print text, of course. However, one can use rendered video and graphics within a patch. This led me to ask this question.

No. I only know that one can make the terminal background transparent in some OSes, and one can put a video behind the terminal window.

Not very often, but still, I should press alt/cmd + tab to find the window that sclang calls to move to the SC-IDE. This seems to lead me to the question…

Even if it were possible, it would be really hard work to implement. I should have thought of that before I wrote it. Sorry…

No, but I’ve come across some very useful “pretty-printing” functions. Specially for trees and arrays. Array boxes in APL is a thing of beauty, for example, and it works with be most complex structures. Since sclang borrowed some array operations, it could also have those goodies as well, why not? The same for trees.

┌────────┬────────┬────────┐
│1 2 3   │4 5 6   │7 8 9   │
├────────┼────────┼────────┤
│10 11 12│13 14 15│16 17 18│
├────────┼────────┼────────┤
│19 20 21│22 23 24│25 26 27│
└────────┴────────┴────────┘

┌→──────────────────┐
│     ┌→──┐ ┌→────┐ │
│ 1 a │abc│ ↓1 2 3│ │
│   - └───┘ │4 5 6│ │
│           └~────┘ │
└∊──────────────────┘

Julia’s benchmark is another good example (unicode though)!

julia> using BenchmarkTools
julia> @benchmark sort(data) setup=(data=rand(10))
BenchmarkTools.Trial:
 10000 samples with 968 evaulations took a median time of 90.902 ns (0.00% GC)
 Time  (mean ± σ):   94.936 ns ±  47.797 ns  (GC: 2.78% ±  5.03%)
 Range (min … max):  77.655 ns … 954.823 ns  (GC: 0.00% … 87.94%)

          ▁▃▅▆▇█▇▆▅▂▁                                          
  ▂▂▃▃▄▅▆▇███████████▇▆▄▄▃▃▂▂▂▂▂▂▂▂▂▂▂▁▂▁▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
  77.7 ns         Histogram: frequency by time           137 ns

 Memory estimate: 160 bytes, allocs estimate: 1.
1 Like

Hey @prko

Yes, this kind of idea would be great in a Jupyter notebook. But terminals don’t do this kind of thing, that’s why there are notebooks nowadays!

1 Like

There are some interesting possibilites when thinking of wasm as a general platform not just for scsynth/sclang but also for the IDE.

If one could dream, I think something like egui could make a nice basis for an IDE 2.0 (see demo egui – An immediate mode GUI written in Rust) or replacing QtGUI.
This would allow to really think of an IDE more as a desk where multiple snippets and windows can be arranged next to each other, multiple people can work on the same desk, integrating visual representations, sources and feedback - video playback in IDE within a document? No problem.

It would be a new way of thinking an IDE and not just in such a boring manner like vscode does - and it would immediately run locally or distributed in the browser in similar performances (this is not electron, it is native machine code!). Combind with the LSP it would create something really refreshing and creative :slight_smile:

4 Likes

Maybe something like SmallTalk? There is a history around those good ideas.

3 Likes

@dscheiba do you have the skills and time to do it? I’d love to see something when there is a prototype.

It may be pragmatic to have a pop-up window that works as a post-window from the current mouse position or from the block of code being evaluated, appear for a while when evaluating a block of code, and then disappear when the mouse pointer is moved, something is typed, or the cursor is moved.

A converter that converts the current output value of a Ugen to a float or integer when a trigger is received might be practical? Then we could be more flexible:

This would mean re-integrating the control layer into the DSP loop (where the whole design of SC3 was to get the control layer fully out of the DSP loop – which gives us benefits such as glitch-free buffer loading, which AFAIK Pd doesn’t have).

SC4 would be an opportunity for a radical redesign – a really radical redesign would be the only way to implement this suggestion.

hjh

1 Like