Current priorities in improving the documentation?

Very interesting! some thoughts:

.

I don’t have an opinion on whether it should be used in helpfiles or not, but if you highlight !? and hit cmd-D it takes you right to Object:!? where there are many examples.

.

Yes, another question is about whether to use variables, environment variables, or interpreter variables, in the help. The reason I personally use environment variables in this case is, it’s more readable than single letter interpreter vars, and when making GUIs I usually want to be able to futz with the objects after making them – when they are confined to regular variables this isn’t possible. The helpfiles in general currently seem to prefer interpreter variables:

(
x = Window.new("test", Rect(100,Window.screenBounds.height-180,300,100));x.front;
)

.

Yes but I wonder about adding a fork to this already somewhat convoluted hypothetical example – it seems off-topic. (And actually harder to search than !?… cmd-D it and you have to figure out first that it is applied to a Function, and then look up Routine and TempoClock.) If you’d rather use SynthDef in the helpfiles, you can at least SynthDef(...).play and get rid of the fork.

Or maybe it’s best to provide a condensed shorthand version alongside a full blown structure with SimpleController and SynthDef and Synth and fork and all the proper bells and whistles. I guess the point of my examples was to show things that are easy in Pd and harder in SC – and to hypothesize that there might be a pattern which makes them less hard, although equally it might be useful to demonstrate that you should start thinking the SC way instead of trying to replicate a Pd workflow…

(and not that this is a good argument for it, but many helpfiles currently use {}.play as a shorthand when it’s something else that is the main focus, and it is pretty basic / idiomatic.)

.

I guess this is also an issue of using the currently available vanilla infrastructure vs rolling your own (other areas where this comes to mind are Patterns and Tunings, probably many other things). The documentation should be opinionated to a degree, but your edit to my code actually breaks something, the displayed number box value is incorrect (ranges from 0 to 1 instead of showing the correct frequency), alongside adding a couple extra lines of code to map and unmap. So maybe the “full bells and whistles” version should abandon EZSlider altogether and show a fully customized MVC approach, while the “simple built-in” version should use EZSlider and ControlSpec.

1 Like

I’m very strongly in favour of having good code in the help files, rather than easy code. Bad practices learnt at the beginning are hard to correct. Dealing with nil is a must in a language like SC and new users need to learn this.

1 Like

Interesting approach.

Did you get more insights using those analysis tools in the help files?

No insights so far, mostly because I need to make the thing useable; currently there’s just too much info there, and zooming etc. is very slow because everything is redrawn. I’ll now try to program some interaction into it such that clicking on a node draws only the neighborhood of that node, which should be less migraine-inducing.

1 Like

I think some kind of interactivity would be really nice, and best within the browser so it can be shipped with the documentation - and it should be dynamic so it can reflect the installed quarks as well. Although networkx/mpl is a really nice tool, it is not something we can ship with SuperCollider b/c it would introduce Python as a dependency.

The default go-to tool for for stuff like graph drawing or any kind of (static) visualization in JS is https://d3js.org/ - currently it is not a dependency of SCDoc, but I think we could justify adding it.

E.g. some links to some examples which could be relevant

If you need some help w/ a PR including this, PM me.

2 Likes

Thanks! I didn’t actually mean for this graph to be included with the docs but rather as a way of tracking down help files that could use more crossreferences.
I don’t know js unfortunately, I might give it a try but I’m not sure if it’s worth it… for now I’ll finish the job with matplotlib and mess around with it a bit.

Here’s another screenshot of just the neighborhood of the Polymorphism guide, looks a bit more “insightful”… a priori I would have thought the neighborhood of that guide to be larger. (this includes both the links to and from the polymorphism file, as indicated by the arrowheads)
In this case, what this helps us notice (presumably) is that while the first three examples mentioned in the help file (Function, Object, Ref) are properly linked, the other examples (that illustrate polymorphism of the .play method) aren’t (Pattern, AppClock, Synthdef, Function); and overall, that there isn’t a lot going on in that file.

A caveat is of course that at the moment I’m focusing on things that are formatted as link::<helpfile.schelp>:: and excluding a) the “see also” part of the helpfiles (this can easily be fixed), b) mere mentions of Classes/Concepts etc… in the text and c) code examples which, iirc also function as hyperlinks in the doc. b) is more or less what this little graph toy is trying to help fix (i.e., for the polymorphism guide, I’d now go and make AppClock etc. into links); on the other hand accounting for c) (code) will probably generate too many links?

Anyway, moving on to making this interactive…

I think this is very out of context at the moment, but back to the opening post of this thread:

I have changed various things in the help documentation:

I think this work could be seen as unnecessary and boring, but from other perspectives, it should be work to be done.

Please take a look, and I hope someone can review it.

4 Likes

Looking at the PR comments, I agree with your sentiment

I think the documentation should be friendly and does not need to include every historical remnant.

Although

a) it’s really important and the current or “historical” state of the documentation should be preserved in a way that is easy to reference, like it is online now,
(not historical in the sense of being the way it was written once, but more historical in the sense of what you’re using isn’t really SC3, it’s SC-server, which descended from SC2, … smalltalk …),

b) I think there is so much to be gained from an overhaul that helps focus, clarify, and modernize (when someone goes to the help, they don’t need to know the historical roots if it distracts from the actual solution to their problem, or if they wind up finding old and problematic code before they find the current best practice; equally they should hopefully be able to find the answer to their question quickly – and if that answer is, “learn OOP somewhere else” then at least they should get there painlessly)

And, here is maybe a more “experienced user” gripe with the current documentation: for conversion methods like whatever.asSomethingElse it would be great to always have indicated how to get the object back from whatever it is converted to…

1 Like

I’m looking at this now, but tbh I need a bit of time to figure out how the github reviewing process actually works, and for the same reason have been a bit shy about commenting something there…

1 Like

No hurry!

I think I can update the latest version of that PR today,

I am not good at github and many things are still confusing and difficult. If you join, other experienced users will help you.

1 Like

I have updated the mentioned PR:

I hope someone will generously have time to review.