Meters for all instruments and fx busses

Questions
1

I was wondering how you handle monitoring multiple instrument and FX busses for mixing. Do you have a meter synth at the end of the server tree that listen to every bus and sends peaks and rms to a custom GUI with level indicators?

How important is it to you to have a level meter for every instrument and fx bus?

I’d like to be able to do this with vanilla SC, without any extensions, some hints how to do this from a dictionary of all my instrument and fx as keys? Or is there a way easier solution?

2

To achieve what you’re asking for, I think LevelIndicator seems to be appropriate if you want to build a custom GUI:

https://docs.supercollider.online/Classes/LevelIndicator.html#examples

However, for a much simpler solution, I prefer using .scope, as shown below. You can scope UGens directly:

{ Ringz.ar(PinkNoise.ar([0.1, 0.2]).scope(\pink), 2000, 1, 0.25).scope(\Ringz) }.scope

Clipping can also be observed in this example:

{ Ringz.ar(PinkNoise.ar([1, 0.2]).scope(\pink), 2000, 1, 0.25).scope(\RingzCLIP) * 0.1 }.scope

Additionally, if your instruments and FX are routed to specific busses, you can simply call .scope directly on those Bus objects:

~anAudioBus = Bus.audio(s, 2);
~anAudioBus.scope;
{ Ringz.ar(PinkNoise.ar([0.1, 0.2]), 2000, 1, 0.25) }.play(outbus: ~anAudioBus);

In my experience, this is the simplest and most practical way to monitor signal output. It would be great if .meter behaved similarly to .scope for UGens and Busses, but currently it does not.

1 Like
3

Thank you very much for the scope examples. I find it difficult to detect slight clipping just above amplitude 1 using the scopes. But the ability to open a scope directly on the desired bus or for a UGen is great!

It looks like I’ll go with the LevelIndicator for mixing and level balancing.

4

Regarding the absolute values of amplitude: SC uses 32 bit float for signals, which don’t have the concept of clipping as their upper limit is not 1.0.
Clipping is only relevant and can occur when passing the output of beyond 1.0 to the audio interface.

5

Yes SC uses 32 bit float signals. But my main concern is that when mixing, if there’s clipping in the output or master mix bus, I have to troubleshoot which instrument stem or send FX might be causing it. Without a visual overview of all my bus levels via multiple level meter in one GUI, I have to laboriously turn everything off and then listen to every bus in isolation to check each one individually using the server meter. I also think the scope is too imprecise for that.

6

If you are working with JITlib (i.e. Ndef and/or proxyspace), you could use the ProxyMeter from jitlibextensions, see JITLibExtensions/HelpSource/Classes/ProxyMeter.schelp at main · supercollider-quarks/JITLibExtensions · GitHub

ProxyMeter measures the peak levels of proxies (e.g. those showing on a proxymixer),
determines pre- and post-slider volume, and can displays these two levels on a mixer,
or generally, on a MonitorGui.

7

@dscheiba
ProxyMeter is cool!

@VactrolDrifter
Might this be useful for you? It’s very similar to UGen.scope: https://www.dropbox.com/scl/fi/axuo26n3byuthyi3sizwq/Screen-Recording-2026-07-28-at-05.15.23.mov?rlkey=6s9e83q6bdafzy0xmdpxtb3wm&st=7tnybd0l&dl=0

(ProxyMeter is better than this, of course!)

added

I updated the demo video.

1 Like
8

Yes, I think that would be useful for me, but .meter doesn’t work, is that an extension, too?

Since I’m just getting started with SC, I’d like to stick with the standard version for now… I don’t know why, but that’s just how I feel.

9

This is not an extension; it is simply a class file I wrote, with some assistance from Gemini for testing. If you are interested in testing it, I can send it to you via a private message.

The code is currently in a preliminary state. I expect to open a PR after cleaning it up, most likely after mid‑August. If you provide feedback, I can finalize it and proceed with the PR. Once the PR is accepted and merged, this method will work consistently when using SC 3.15.0‑dev and above.

1 Like
10

I don’t like having many windows around, it annoys me. Instead, I just create one mixer window. I usually do this by defining a ‘master’ node with a bunch of busses. I find this makes mixing easier. The down side is that you need to declare all the inputs and update the master node as you go. For what I do, this isn’t a problem, but I can see how this is an issue with live coding where you might not know (or even want to know) the structure before you begin.

1 Like
11

I’ve given it some more thought. It would be more useful if it is possible to meter a bus with this, like: ~bus.meter, then it would be nice to have, but i tend to code my own meter GUI now with one window for all my busses with LevelIndicators. Then it looks cleaner!

12

The approach in my ddwMixerChannel quark fully, neatly, intuitively solves this problem. Bus routing: ddwMixerChannel's approach

hjh

13

For Bus, it works now.

i tend to code my own meter GUI now with one window for all my busses with LevelIndicators. Then it looks cleaner!

This is, of course, better. .scope and .meter are useful for testing and quick, on‑the‑fly inspection, but they’re not as good as a well‑designed GUI.

How would you handle the variable number of instruments and busses? Since each project uses different SynthDefs, Synths and busses, the GUI would have to be different for every project… If you create meters only for busses, the whole setup becomes simpler.

1 Like
14

That is pretty easy actually when i thing about it. My whole project uses a instrument list, and this list is used to collect all the instument stem busses in a dictionarys. I only change the list in the beginning and the whole project routing is done. A meter GUI synth could use the bus dictionary afterward to generate all correct In UGens and SendReplys, also the OSCFunc and the GUI to build it.

1 Like