Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Big sur (in)compatibility #216

Open
yaxu opened this issue Nov 29, 2020 · 8 comments
Open

Big sur (in)compatibility #216

yaxu opened this issue Nov 29, 2020 · 8 comments

Comments

@yaxu
Copy link
Collaborator

yaxu commented Nov 29, 2020

I've seen MacOS users increasingly report problems with the new 'big sur' os update. Tidal+SuperDirt work fine after a reboot but then timing drifts in one direction or the other, either causing 'late' messages or very long latencies. Some say this happens after a resume, but I'm guessing the problem is time since last reboot rather than a sleep-resume cycle in particular.

This is very likely caused by a general issue with supercollider + big sur:
supercollider/supercollider#5168

Just wondering if there is a workaround, how come supercollider uses a different time source to tidal - could that be fixed? Or with the new tidal<>supercollider API, could we do a quick+dirty hack, e.g. a 'resetClockDirtyHack' command that readjusts the latency via a simple ping-pong?

@telephon
Copy link
Contributor

telephon commented Nov 29, 2020

Yes, supercollider doen't support big sur yet, we should (have) warn(ed) tidal users.

One possible workaround, which may cause inaccuracies, but still better than nothing:

try to change in DirtEvent:

playSynths {
		var cutGroup;
		~cut = ~cut.value;
		if(~cut != 0) {
			cutGroup = orbit.getCutGroup(~cut);
			~hash ?? { ~hash = ~sound.identityHash }; // just to be safe
		};

		server.makeBundle(nil, { // <======================= 

			orbit.globalEffects.do { |x| x.set(currentEnvironment) };

			if(cutGroup.notNil) {
				server.sendMsg(\n_set, cutGroup, \gateSample, ~hash, \cutAll, if(~cut > 0) { 1 } { 0 });
			};

			this.prepareSynthGroup(cutGroup);
			modules.do(_.value(this));
			this.sendGateSynth; // this one needs to be last

		});

	}

@yaxu
Copy link
Collaborator Author

yaxu commented Dec 1, 2020

Had a positive report for this workaround, no perceptible differences so far. Thanks a lot @telephon !

@yaxu
Copy link
Collaborator Author

yaxu commented Dec 1, 2020

Ah I spoke too soon, they shared an audio file of the timing, it has a definite shuffle!
https://slab.org/tmp/SC_201202_012946.mp3

@yaxu
Copy link
Collaborator Author

yaxu commented Dec 1, 2020

I guess another option is for tidal to do the timing and send messages to play 'asap'

@yaxu
Copy link
Collaborator Author

yaxu commented Dec 1, 2020

I tried sending as plain messages (no bundle), like this:

image

That works but causes late messages in sc. I can also hear jitter, which is probably quantified in the difference between late messages, e.g.:

late 0.059494577
late 0.064735330
late 0.070150778
late 0.051138094
late 0.057052164
late 0.061236595
late 0.066223818
late 0.048788407
late 0.053193565
late 0.058108672

@yaxu
Copy link
Collaborator Author

yaxu commented Dec 1, 2020

The Big Sur user reports that this is an improvement and they don't get late messages. It does sound better, I can sense a bit of a shuffle though:

https://slab.org/tmp/SC_201202_015301.mp3

This workaround is a case of editing BootTidal.hs, and changing the startTidal line to:

tidal <- startTidal (superdirtTarget {oLatency = 0.1, oAddress = "127.0.0.1", oPort = 57120, oSchedule = Live}) (defaultConfig {cFrameTimespan = 1/20})

i.e. add the , oSchedule = Live bit

@telephon
Copy link
Contributor

telephon commented Dec 1, 2020

You could also try this (untested) branch I made:

https://github.com/musikinformatik/SuperDirt/tree/topic-send-immediate

Just set

~dirt.set(\latency, nil)

And hope for the best.

It will schedule the shuffle in the sclang scheduler (less efficient, but you can try.)

@yaxu
Copy link
Collaborator Author

yaxu commented Jan 23, 2021

There's a supercollider build that works apart from audio input supercollider/supercollider#5168 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants