search

defaultxr / cl-patterns

Library for writing patterns to generate or process (a)musical sequences of mathematically (un)related (non-)compound values in Lisp.
https://w.struct.ws/cl-patterns
MIT License
77 stars 10 forks source link

Sync MIDI and SuperCollider backends #17

Closed TatriX closed 3 years ago

TatriX commented 3 years ago

Hi! I'm trying to use both :alsa-midi and :supercollider backends at the same time and it seems I need to properly setup *latency* to make it play in sync. If I set (setf *latency* 0) then midi stops playing. Any advice is appreciated!

defaultxr commented 3 years ago

With the recent changes to it, by default the clock skips any events that are "expired", i.e. occur in "the past". If *latency* is 0 then the clock has no time to calculate events from a pattern, so all events it generates will technically occur in the past. If you want the clock to play all events even if they're "expired", you can do this:

(setf (slot-value cl-patterns:*clock* 'cl-patterns::play-expired-events) t)

Then even if the latency is 0 it will still play all events. However, you may still get warnings from SuperCollider (i.e. "late 0.004638016" and similar) when it plays them. It's also possible that with 0 latency there may be more "jitter" between events since the clock processes events in batches and the backend will be told to play them as soon as it receives them. For example:

(pb :test
  :instrument :kick ;; or any percussive sound
  :dur 1/8
  :pfindur 4)

If you play that pattern with *latency* set to 0 you should hear the jitter between notes. You can compare it to when *latency* is at its default 1/10 value which sounds much smoother and consistent, as expected.

If you're curious, the "skip expired events" change to the clock was made in order to prevent tons of events from being played after the user recovers from an error. i.e. if you do:

(pb :test
  :instrument :default
  :dur 1
  :x (p/ 1 (pseq (list 1 2 3 0)))
  :pfindur 4)

...you'll get an error every 4th event on this pattern since it's attempting to divide by 0. If you wait a bit and then choose the SKIP-EVENT restart you'll likely get a bunch of late messages and maybe hear a few of the events. You probably won't hear them all since they're being told to end as soon as they've started. However if you do (cl-collider::server-query-all-nodes) you'll be able to see all of those notes still running in the background. They will stay running even though you never hear them because of this bug in scsynth where notes that are short enough aren't cleaned up. Just something to be aware of; if you notice scsynth using an abnormal amount of CPU, it may be these "ghost notes" lingering.

defaultxr commented 3 years ago

Oh, also, unfortunately the ALSA MIDI backend doesn't support timestamps yet. So SC and MIDI likely won't be 100% in sync even with *latency* set to 0... Though it's possible they may still sound synced enough for your purposes.

But yeah, MIDI timestamps are definitely something I should fix when I'm able to; I'll leave this issue open as a reminder to do that.

defaultxr commented 3 years ago

Ahh, actually it looks like even with play-expired-events set to t the MIDI backend will throw errors because it's trying to sleep a negative amount. Fortunately this won't be too hard to fix; one moment.

defaultxr commented 3 years ago

Fixed in c27c6e09a689eda0c0f89d9f7a8b46cc6a4bc6f4 :)

defaultxr commented 3 years ago

Also I did see that the ALSA MIDI backend was erroneously adding *latency* to the event timing even though the clock already includes latency in its calculations. I fixed that in 37dc8f20e2948db470b463b0a29037d5f1cabc69 which should bring the backends even more in sync with each other.

TatriX commented 3 years ago

Magic! It's almost perfectly in sync now. Thank you as always!