Yes. It’s fantastic. The initial learning curve is rough, but the IDE and built-in help have improved a lot since I started a few years back. The nice thing is that it scales very quickly. Say you have a simple sine wave:

{SinOsc.ar(220)}.play;

So, that looks like a ton of syntax to create a single-channel sine wave. Now, my favorite aspect of SuperCollider is “multichannel expansion,” or a quick way to create numerous objects. If you modify the line with the [] multichannel syntax:

{SinOsc.ar([220, 330])}.play;

This will put a 220 Hz sine on the left channel and a 330 Hz sine on the right. You can load this up with as many channels as you please. Panning that may seem like a nightmare, but the Splay uGen will help situate each generator in the stereo field:

{Splay.ar(SinOsc.ar([220, 330, 440, 660, 880, 110]))}.play

That will give you a rich, wide additive wave. For reference, we are spawning six oscillators in one line of code. Once you learn more, you can use faster methods for populating all of the channel arguments, adding MIDI inputs, turning that one line into a reusable SynthDef, etc. Start simple :slight_smile:

Speaking of which, cmd+. is perhaps the most important key combo to learn while learning SuperCollider. It immediately kills all active synths. When learning SC, it’s super easy to write something jarringly loud, so keep that key combo handy. When I start experimenting, I start with a

{WhiteNoise.ar()}.play

to test how loud things could be expected to get. This can save you from a traumatic headphone accident when changing uGens.

cmd+D is also great. It opens the help document for whatever uGen your cursor is currently on. If you have your cursor on “SinOsc”, it will bring up the SinOsc docs. The help documents are interactive. You can modify and execute the examples as though they were in the main editor window.

I just bumped the SC tips thread: Supercollider tips, Q/A

Here’s an interactive homework assignment that I turned in early in grad school when learning how to generate patterns in SC: Supercollider tips, Q/A

I’m definitely buying a Norns once the page goes live.

Oh, one weird tip: Don’t buy The SuperCollider Book as your first stop. It was written a few SC versions ago, so a lot of the code is out-of-date. In particular, I had a lot of “fun” when trying to execute the Microsound chapter examples a few months back. One of the uGens used in every example was no longer in SC 3.8. It’s a great book to have eventually as you get more comfortable, but it will cause a lot of headaches for beginners.

51 Likes

So maybe this means that multiple sound engines can run simultaneously, and Lua code can switch between them

2 Likes

One point for Csound :wink:

1 Like

From SuperCollider guide: Client Vs. Server:

In SuperCollider the client and the server make use of a specific subset of CNMAT’s Open Sound Control (OSC) protocol in order to communicate (over TCP or UDP). As a consequence, you will see many references to “OSC messages” in the help files.

But I don’t know if norns’ script ⇋ engine interface is this SuperCollider OSC interface, or some higher level one.

@tehn said: “it’s perfectly possible to use a different dsp application,” My aim would be to use a different control application! So, if the knobs, buttons, and display are available somehow (C library?) then I might be able to use those from, say, a Haskell / Vivid / Euterpe application I write…

2 Likes

Since Norns is built on Linux, it seems like it would be possible to get CSound, pd, ChucK, and all the other usual Linux suspects working at some point. As mentioned above, @TheTechnobear did a massive amount of work on the Organelle, turning it from pd-only into something much crazier.

The SuperCollider book isn’t that bad, but it’d be similar to recommending The CSound Book for CSound, which has a lot of out-of-date information since it was written two major versions ago. Plus, both books are plagued with copy-editing issues. It’s not just an issue with deprecated units, but also an issue with typos. (“Why isn’t this compiling?” …three hours later “How the hell did they forget that semicolon in Chapter 1?”)

2 Likes

at risk of jumping the gun on @tehn, gonna answer some yes/nos that are piling up

not really, scripts are self-contained lua applications, and should clean up all resources and processes when they exit.

but they also have full access to the UI, filesystem, and lua modules, and can be as modular or multilayered as desired. there are a couple of ways of acheiving parallelism within a script - lua coroutines, and callbacks from our own high-resolution timer system. so you could implement something like a teletype environment (for example) in one script. [details later]


likewise:

no, at the moment there can only be one Engine in use at a time, but Engines are pretty arbitrary supercollider classes that have access to all the features of sclang. @jah has already prototyped an Engine that implements a small modular synthesis environment.

it would be straightforward to create an Engine that aggregates other Engines, but for reasons have not yet done so [details later]

no, it doesn’t use a lua-based scsynth client like Lua2SC or similar. instead there is a full-blown sclang instance with some classes providing an OSC interface to our scripting process.

so,

higher level.

there are a number of reasons we decided to go with vanilla sclang - can get into it later. (but i want to say kudos to developers of sonic pi, tidalcycles, and overtone - they are great projects that required a lot of work.)

yes, it is possible to adapt the platform to run another SC client (or Pd or an LV2 host, or what-have-you.)

anyways, much more info to come on the development environment and software architecture.

yes, they use standard linux interfaces (sysfs, cairo). so it should not be hard to roll your own control application or FFI glue.

yes. though of course it will limit the battery life; m128 at full brightness with all leds on, draws almost 1A at 5V. (note that this is maybe 4- 5x more than a typical use case.) norns lipo battery is 2250mAh at 5V. i’ll check the base norns draw next time i have the battery removed :slight_smile:

there could, and its something i want to investigate further; AFAIK there isn’t a USB class for that -“DisplayLink” and “Magic Control Technology” (“MCT”) are two proprietary chipsets that should be supportable - the former is the most widespread by a good margin.

22 Likes

script-engine

10 Likes

…for example, when you need to close up the chicken coop at night and can’t find your flashlight. (in reality all-on is really only useful if you want to drain your battery or need really high impact visuals.) i’ve measured the impact of a typical grid application’s current draw to be around 120-180ma.

14 Likes

All of this sounds excellent. Two SC questions:

  1. Would it be possible to include the massive sc3-plugins repo in the main image? https://github.com/supercollider/sc3-plugins There are a lot of excellent classes in there, and they are pretty well vetted since they are on the main supercollider GitHub account. The main issue is that a lot of them lack high-quality documentation.

  2. With the WiFi adapter connected to Norns, is it possible to make use of the Quarks system? I’m already thinking of creating a parameterized BBCut box (https://github.com/snappizz/BBCut).

2 Likes
  1. yes (out of the box) 2. yes, why not
4 Likes

Same

20 chars of tbh

So if i had to choose one, what should i learn first in order to have some fun when norns will be out there? LUA or SC?

3 Likes

image

Fascinating.

Asking myself this same question.

1 Like

seems like lua would be your best bet
from what i can gather

3 Likes

I expect you can use norns with without really knowing either, but I would learn Lua first.

It sounds like Lua is used to compose and interact with the sound engine(s). If/when you want deeper control over them or to write your own, then it’s time for SC.

4 Likes

The thing I’m wondering most now:

Can Norns talk to other Norns in their common tongue, say at a scripting level?

1 Like

The Lua Crash Course - http://luatut.com/crash_course.html

If learning Lua will help me use Norns then I will lean Lua.

9 Likes

looking at the i/o and specs and trying to imagine the realistic cost

am i wrong to expect a price tag in the range of teletype / opz / organelle?
regardless I expect this to be one the best selling monome devices ever (for many reasons)

11 Likes

that would be amazing, but I’m imagining this would cost something closer to a grid/arc

1 Like