Server.default.options.device_ not doing anything

Hi! I’ve been struggling with this issue for a couple days and can’t seem to find any documentation or forum posts that address it. In the past, I’ve been able to change the output device SuperCollider uses with Server.default.options.device_("deviceName") or Server.default.options.outDevice_("deviceName"), pulling the string for the device name from the list printed to the REPL when I execute ServerOptions.devices;. Recently, though, I haven’t been able to do this. I switched from working on an old ThinkPad running Windows to a new MacBook Pro a few months ago, but I’m pretty sure I’ve had this working on the Mac before, and it just hasn’t worked when I’ve tried it in the last week or so, after not having done this specific thing in several weeks.

I’m trying to listen to a SuperCollider piece I’ve been working on with headphones. First, I tried both of the above Server commands to change the output device to my Scarlett 4i4. Neither of them did anything; there was no error message, but the audio still came out of my computer’s built-in speakers and did not come out of the Scarlett. Then I tried it with a Scarlett 2i2 I had around, which is the device I’d had this working on before, and that didn’t work either. I tried changing the output device on my laptop in the system settings, but that didn’t do anything as far as SuperCollider is concerned. I also tried plugging some headphones into my laptop’s headphone jack and selecting those as an output device, but the audio still came out of the laptop speakers, not the headphones. I tried with the Scarlett interfaces again, this time connecting them directly to one of the laptop’s usb-c ports rather than through a powered usb hub, as I’d been doing before, but that didn’t change anything either. My next idea is turning the SuperCollider script into a monome norns script, just so I can use norns’s headphone output. But I’d much rather be able to just use my laptop. Anyone have any ideas as to what I could be doing wrong here or what I need to do differently?

Setting output as you described should work as expected, both on macOS and Windows.

You might need to post the exact code in order to get help for this. Are you sure you’re booting the server after setting the device?

1 Like

pretty sure, yeah! I’m using s.waitForBoot, and that’s happening after the server commands, including for device stuff.

I threw the piece I’m working on in a gist here, including the code I’m using (unsuccessfully) to try to access the Scarlett. I also tried the same device (and outDevice) command(s) in a different .scd file (which is available at this GitHub repo), but it didn’t work there either, which makes me think it isn’t an issue with the script(s).

This looks fine, though for consistency (and to double check) I’d replace s.waitForBoot with Server.default.waitForBoot.

Can you show the output of your ServerOptions.devices? (e.g. ServerOptions.devices.do(_.postln)) The device name needs to match exactly the name as reported there on macOS. On Windows, IIRC, partial names work, but on macOS they don’t.

good call on Server.default! Thanks for that. The output of my ServerOptions.devices is:

[ Spencer Kingman Graham’s iPhone Micropho, Scarlett 4i4 USB, NDI Audio, BlackHole 2ch, MacBook Pro Microphone, MacBook Pro Speakers, NDI Audio, Loopback Audio, ZoomAudioD, Multi-Output Device ]

Another odd thing I’ve noticed is that, when I run this script (the one in the gist above), nothing ever shows up on freqscope, even though I can visualize the audio by going to “Show Server Meter” under the server menu. This is probably unrelated, since scoping works just fine with the other script linked above, but outDevices doesn’t work for that script any better than it does the one in the gist.

If I recall correctly, Windows does partial string matching on device names – because device names tend to be long and ridiculous in Windows, scsynth allows you to write only the first part of the device name. But in Mac (I think) the match needs to be exact. (Self-fact-checking: In the source code, Windows matches device names using the C substring function strstr() [common/SC_PaUtils.cpp], while Mac uses string comparison strcmp() [server/scsynth/SC_CoreAudio.cpp] which requires a precise match for equivalence.)

In your case, the device name is "Scarlett 4i4 USB" and you wrote device_("Scarlett 4i4");.

This would match in Windows, but will not match on Mac. (I did notice in the first post that you said you thought you had it working in Mac before, but based on my reading of the source code, that can’t be the case.)

For partial matching in Mac, you could get the exact name out of the devices array:

.device_(ServerOptions.devices.detect { |name| name.contains("Scarlett 4i4") })

Also, for future troubleshooting of device issues, it’s helpful to post the scsynth startup output from the post window. Error messages would give more insight – a lot of information was provided in this thread, but not the actual error messages.

hjh

1 Like

yes! I noticed that @MarcinP mentioned this earlier. Sorry, I should’ve been more clear: I tried Scarlett 4i4 USB first, and when that didn’t work, I tried Scarlett 4i4 on the off chance there was somehow a discrepancy between the string Server.default.options.device was expecting and the string ServerOptions.devices printed. I just tried Scarlett 4i4 USB to be sure, and the result is the same (i.e., audio comes from my laptop speakers, not the Scarlett). I just double checked for extra spaces or spelling errors in the device name, too, and there aren’t any.

Yes! I should’ve posted this to begin with. Sorry about that. Part of what’s so curious about this whole thing to me is that there hasn’t been any error messaging in the post window at all. When I execute the script, what I get in the post window is:

changed default server to: localhost
-> localhost
MIDI Sources:
	MIDIEndPoint("IAC Driver", "Bus 1")
	MIDIEndPoint("Midi Fighter Twister", "Midi Fighter Twister")
	MIDIEndPoint("Scarlett 4i4 USB", "Scarlett 4i4 USB")
MIDI Destinations:
	MIDIEndPoint("IAC Driver", "Bus 1")
	MIDIEndPoint("Midi Fighter Twister", "Midi Fighter Twister")
	MIDIEndPoint("Scarlett 4i4 USB", "Scarlett 4i4 USB")

(also, since I don’t think I mentioned this earlier, I tested the Scarlett with a DAW, and it’s working as expected; I’m able to select it as an input and/or output device, and it works just fine both ways)

This is quite odd in that there’s no server startup sequence at all. A number of messages should be posted during a successful server boot… Are you sure the server is even being booted at all? You’ve got MIDI startup but nothing is shown after that.

hjh

oh, good catch! Sorry about that. I think that was from my clearing the post window after a cmd+. and rerunning. Here’s the post window from a fresh scIDE session, from opening sc to executing the script:

compiling class library...
	Found 855 primitives.
	Compiling directory '/Applications/SuperCollider.app/Contents/Resources/SCClassLibrary'
	Compiling directory '/Users/spencerkingmangraham/Library/Application Support/SuperCollider/Extensions'
	Compiling directory '/Users/spencerkingmangraham/Library/Application Support/SuperCollider/downloaded-quarks/Vowel'
	Compiling directory '/Users/spencerkingmangraham/Library/Application Support/SuperCollider/downloaded-quarks/Dirt-Samples'
	Compiling directory '/Users/spencerkingmangraham/Library/Application Support/SuperCollider/downloaded-quarks/SuperDirt'
	numentries = 1299810 / 20530260 = 0.063
	6003 method selectors, 3420 classes
	method table size 21400296 bytes, big table size 164242080
	Number of Symbols 15397
	Byte Code Size 464762
	compiled 573 files in 0.38 seconds
compile done
localhost : setting clientID to 0.
internal : setting clientID to 0.
Class tree inited in 0.01 seconds


*** Welcome to SuperCollider 3.13.0-rc2. *** For help press Cmd-D.
changed default server to: localhost
-> localhost
Booting server 'localhost' on address 127.0.0.1:57110.
Found 0 LADSPA plugins
Number of Devices: 9
   0 : "Scarlett 4i4 USB"
   1 : "NDI Audio"
   2 : "BlackHole 2ch"
   3 : "MacBook Pro Microphone"
   4 : "MacBook Pro Speakers"
   5 : "NDI Audio"
   6 : "Loopback Audio"
   7 : "ZoomAudioD"
   8 : "Multi-Output Device"

"Scarlett 4i4 USB" Input Device
   Streams: 1
      0  channels 6

"Scarlett 4i4 USB" Output Device
   Streams: 1
      0  channels 4

SC_AudioDriver: sample rate = 44100.000000, driver's block size = 512
SuperCollider 3 server ready.
Requested notification messages from server 'localhost'
localhost: server process's maxLogins (1) matches with my options.
localhost: keeping clientID (0) as confirmed by server process.
Shared memory server interface initialized
MIDI Sources:
	MIDIEndPoint("IAC Driver", "Bus 1")
	MIDIEndPoint("Midi Fighter Twister", "Midi Fighter Twister")
	MIDIEndPoint("Scarlett 4i4 USB", "Scarlett 4i4 USB")
MIDI Destinations:
	MIDIEndPoint("IAC Driver", "Bus 1")
	MIDIEndPoint("Midi Fighter Twister", "Midi Fighter Twister")
	MIDIEndPoint("Scarlett 4i4 USB", "Scarlett 4i4 USB")

Ok – it claims that it’s connecting to the Scarlett.

I’m not on Mac so I don’t have much more I can say. It looks like it’s definitely trying to hook up to the right interface – maybe something is failing silently and it falls back to built-in?

hjh

The abbreviation of devices on OSX seems to cause some problems if the abbreviation of the input device equals that of the output device. In such a case I was successful to choose the aggregate device as an output in SC (with correct abbreviation), and the interface under the aggregate device menu in Audio-MIDI-Setup.
Also, you might have to choose the headphone output as device (I think that’s only the case on newer OSX versions)

I haven’t seen a situation where after reporting using a particular device, the audio would be routed to another one… Are you absolutely sure that after this boot you are not getting the audio out of Scarlett?

Also, can you try a simple noise test like this:

x = {PinkNoise.ar(-12.dbamp)}.play;
// x.free; // to stop

Finally, which OS version and which SC version are you using?

Well, certainly not if you want to use an external soundcard :slight_smile:

The issue of using headphone as a distinct device does not pertain to the OS version, but to newer hardware - computers with Apple CPUs. They do present headphone out as a separate hardware device, but if it’s selected by default in the system and one does not specify the output device in SC (thus using the default device), then it works fine without any extra effort.

What does not work is switching from headphones to speakers (and vice versa) when the server is running.

unfortunately, I am. I just tried your test code in a blank .scd. The only other line I used was to set the output device, so the whole file was as follows:

Server.default.options.device_("Scarlett 4i4 USB");
Server.default.options.outDevice_("Scarlett 4i4 USB");
x = {PinkNoise.ar(-12.dbamp)}.play;
// x.free; // to stop

(I didn’t use both of the above Server.default lines at the same time; I just tried one and, when that didn’t work, tried the other, but neither of them worked, which is to say, the result, after running either of those Server.default lines, booting the server with cmd+b, and then running the simple PinkNoise test, was that pink noise came out of my laptop speakers).

I’m running SuperCollider 3.13.0-rc2 on macOS Ventura (13.3.1 (a))

EDIT: Just fixed it! It was loopback.

While reviewing the devices listed at boot time that I shared above, I noticed that loopback audio was in the list (blackhole 2ch was too because I’d tried that prior to shelling out for loopback). I realized that I’d given a performance on zoom several weeks ago and had had to route SuperCollider audio through to zoom using loopback for that performance. This overrode other settings and led to the problem above. Once I turned off loopback and re-ran the pink noise test above, it worked exactly as expected. I’m sorry I didn’t think to mention this loopback business earlier; it was several weeks ago, and I’d honestly forgotten that I’d done it. But for future travelers: this could be the cause of your problems if you’re experiencing this issue, and it’s certainly worth checking! And thanks, everyone, for patiently troubleshooting this with me.