Didn’t realise this was a bug, thought that was just how it works - if it is fixed, using load is far better than the mess I suggested.
I’d have a go at fixing it, but I the routines and thread side of sc is where I am least comfortable, so there might be someone better suited.
The infrastructure is there for a thread to remember where it’s executing. It’s just not consistently updated, which IMO is not realizing the spec properly.
TBH here… in my live setup file, I have var path = thisProcess.nowExecutingPath and then I use path throughout. That was a while ago. I don’t remember if I had tried using thisProcess.nowExecutingPath, and it broke, and then I tried to work around it – or maybe I just assumed “this isn’t going to work in a thread” and preemptively worked around it.
(Now, the path infrastructure doesn’t exist for functions – so, scheduled functions don’t have any awareness of the path in which they were defined. I don’t think this is a big problem because standalone functions don’t persist their status in the way that routines do, and if you really need it, the workaround isn’t difficult.)
It’s now at thisThread's executingPath is not updated when doing `executeFile` in a Routine · Issue #6028 · supercollider/supercollider · GitHub – eventually it will get some attention.
hjh
damn, I feel attacked…
… are you really care?
Good article. Taking inspiration from cool pieces of hardware is great, as it helps you to think about problems in a general way.
I got pretty overwhelmed when starting out with SuperCollider and I was not new to programming or synthesis or music production.
So my tip is more for casual self-learners, that just want to hack something together to make sick tunez after work, rather than the lucky few that get to invest much more time.
My tip is (especially if you feel overwhelmed): you don’t have to go ‘all in’ on Supercollider, when starting out.
There are many other ideas for using Supercollider in a limited way. The point is not to sweep difficult concepts under the rug, but to try and learn them incrementally while still getting your hands dirty writing code and enjoying the new capability. As ideas get more ambitious, there’s more motivation to take on the trickier concepts.
For programmers: one thing I did was cherry pick problems from coding sites like code wars or exercism and solve them in sclang. That was a fun way to explore the language and get a feel for it. Instead of just wishing it had feature x from lang y.
You mentioned Synth secrets, which I quite like. There’s also this old nord modular book - you’re probably aware of it, though I’m not sure if it’s a good addition to your article.
I experienced something similar. I was losing motivation to write supercollider code after writing code all day at work. My productivity increased once I stopped caring about the usual things when developing in a professional context.
My music code doesn’t need to scale, it doesn’t need to be readable or maintained by anyone else, it doesn’t need to be DRY, etc etc. It just needs to sound good! If I were collaborating, then ok sure, I would have a different approach.
Just discovered this lately. Certainly a lot of very useful recommendations! Some of them with a strong opinion – I might not agree with – but that’s ok.
I especially like the emphasis on practice, keeping things technically clean and simple and – at the end – LISTENING to the results. Having said that, sometimes curiosity inevitably leads you to things that are not simple … 
One side-remark concerning the Amplitude UGen you are mentioning in the collection of SuperCollider Tips: it’s not only the default settings, it’s mathematically wrong in more than one regard – a bad bug, as Julian described it (my example of June 4, 2020 is clearer than my first post). However, Amplitude is still of practical usage:
I can only partially confirm what you have been experiencing. Indeed, I’ve developed several classes for miSCellaneous_lib that I have never used musically in serious projects (E.g.: Sieve / Psieve patterns, ironically, I know that others did use them). However, I’ve used several classes intensely over a long period of time: VarGui is serving my GUI needs since 2007 or so for all of my projects. I’ve used it in combination with PLx Pattern classes for Pattern-based granulation very often.
What also happens quite often is that classes turn out to be useful with a delay of several years. I’ve used PbindFx – which took me three years to develop – for the first time in a larger project last year.
Yes so true. That’s my preference - for curiosity to lead me towards complexity, rather than racing towards it, as I have in the past. I guess there are some parallels there with premature optimization.
Edit: And yes your miSCellaneous_lib is super cool and very useful! Thank you.