[sc-users] Re: top five sclang pet peeves

[jamshark70@xxxxxx]

Without any particular attempt to organize what I'm thinking...

> a lot of built-in functionality in the class library and interpreter
> prints a lot of crap to the post window that can't be suppressed. it gets
> in the way of any post output you actually want to see.

I'd make a distinction between initialization/startup posting and posts
during usage. The former doesn't particularly bother me (though I know,
Nathan, that it bothers you), because it happens once and then it's over.

Commonly, the post window looks kind of like this in the middle of one of my
live-coding sessions:

-> BP('kick')
-> BP('kick')
-> BP('bass')
-> BP('kick')
-> BP('snare')
-> BP('hh')
... etc.

Perhaps I'm just avoiding the verbose built-in functionality, but I don't
think the output in this case can get any more transparent.

> for a language that deals heavily with asynchronous operations
> (interprocess / networked communication), sclang sure doesn't offer a lot
> to make asynchronous programming less painful.

Devil's advocate -- maybe this is a documentation problem? Condition() is
not horrible -- when you know how to use it, it's nearly transparent (and
improving on that transparency would require a pretty hefty redesign of the
language, because as it is now, callbacks need to have access to the
thread's local scope).

But we don't have a document explaining how to handle "async ops for
dummies" because -- and this is one of my pet peeves -- we only ever
document classes and methods, and we never document important topics that
would be useful to non-computer-scientist users. "Never" -- yes, I'm
overstating, but let's be honest -- I'm not far wrong, am I?

fork {
	var score = Score([
		...
	]),
	cond = Condition.new;  // ***
	score.recordNRT(...,
		action: { cond.unhang }  // ***
	);
	cond.hang;  // ***
	... go on
}

*Three* lines only, where the "..." may span hundreds of lines. It's very
slightly weird to write "unhang" before "hang" when the unhanging happens
later, but this is not excruciating. It's not even that difficult to
understand, if it were explained in a place where users could find it
easily.

hjh



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/