FWIW Iβd love it if someone wanted to take up the work of integrating QML with sclang. It would greatly reduce the surface area of our QT dependency (the required QML interfaces are very small, and mostly already exist), and there would be enormous user benefit. Itβs a very tricky and fun C++ project, and an interesting API design challenge.
I disagree that having a more difficult install process or having to use a normal text editor would be a problem. The tidal community is massive and very active and to install tidal is considerably more annoying than getting started with SC. If the install/getting started process is well documented I donβt see this being a major obstacle.
https://api.github.com/repos/supercollider/supercollider/releases
Check [n].assets[n].downloadCount - this is the only metric I know of at the moment. Usage would be nice - I wish there was a service that open source products could use for gathering analytics in an ethical way. This kind of information is SO valuable for steering a software project, validating features, fixing bugs, etc.
2 Likes
Right on the front page of the help system it says Getting Started with below that tutorials. After that comes Documentation Indexes with three diferent ways to dive into the API. Worked for me and I know little of OOP. The nice thing of the documentation system is that it also incorporates the ocs of everything I βplug inβ to SC.
Now, with this type of sofware there is always a discrepancy between coders wishes an users wishes. POV-Ray is an other example of this. To put it black&white: The coder codes code for fun or out of academic interest and the coder likes sound. The user likes music, so sound is not enough, and canβt code to the coders level, so the user depends on what the coder does, or likes. A user can ask, but that is about it. A coder may like a strong statically typed and compiled language, for a live coder it may be hampering.
1 Like
My personal impression is:
The problem with using external IDEs, specially emacs and vim variants, is that they kill musical interactivity by default. SCIDE is not the best interactive solution, but it helps a lot not getting in the way.
Neovim is powerfull, but the learning curve is Env([0,1,0,1.1,0,1.2], curve:10).plot and the time to customize and maintain it is enormous.
They are definitive great for editing big per-written source code files, but by default they are not good at creating new sparse blocks of code for rapid response.
The solution is really complex. Gibber and Strudel are amazing, but I am afraid they will not reach something further then specific live coding practices (e.g. traditional music, midi like conventions, etc).
Plus the big question regarding interactivity: should we really kill the mouse? I still think that other inputs methods for creating and modulations sounds are the only way to achieve specific sound results, on/off typing + code simply does not get there. Some in-between solution is needed.
Out of curiosity, is there a video or demonstration of someone using traditional SC with emacs/vim for live coding specifically regarding this interactivity problem?
O/T but just wanted to note the SCNvim is not any less interactive than SCIde - on the contrary! It is straightforward to use snippets and scripting in the editor that gives you all sorts of interaction options that are probably impossible with the IDE. And βout-of-the-boxβ it is just as interactive, not sure what distinction you are seeing.
What I miss from both setups is the total integration of the IDE with the language that we see in Smalltalk that allows hacking the IDE as part of a piece - and lets you save and recall states. but anyhooβ¦
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):
-
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?
-
Lots of parentheses make code reading/writing more complicated. Could indentation be made part of the syntax? Then parentheses could be omitted, I think.
-
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.
-
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.
-
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?
-
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.
-
Could SC-Plugin be included in the SC binary by default?
-
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 toimportin Python orincludein 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. -
Can the Pythonβs way of βmultiline stringsβ, i.e.
'''...'''or"""..."""be adopted? It will reduce a lot of typing and"...".quote. -
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.
-
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?
-
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. -
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 
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
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