Question about clocks

[emenel]

Hi @defaultxr and thank you for this amazing library!

I have a question about clocks in cl-patterns vs in cl-collider and sc-extensions. It seems like right now there are three separate clocks possible with these systems: cl-collider's clock (i.e. clock-bpm etc); sc-extensions metro and bpm; and cl-patterns clock-loop.

I'm curious as to why there are at least two separate scheduling systems/clocks, and if it's possible to merge them or use them together?

For example, I'd love to be able to sequence using cl-patterns but also using cl-collider's callback and clock-add etc, and have them share a tempo and sync. I think I could work around this with some custom functions that keep the two clocks synchronized, but it feels strange to have to manage multiple un-coordinated scheduling systems.

There is also a really nice feature in sc-extensions that work with cl-collider's clock, but not with cl-patterns clock -- the ability to change bpm with a lag time in beats for nice slow tempo changes.

Thanks for your insight and work on this!

[defaultxr]

Hello, and thank you for the kind words :)

Yes, it's been a while since I've played around much with cl-collider's clocks/scheduling, nor the ones in sc-extensions, and cl-patterns' own clock definitely has plenty of deficiencies--another being that it can only operate as a master clock and cannot sync to other clocks.

So I'm saddened, but not really surprised, to hear that it doesn't work with the scheduling in cl-collider or sc-extensions. It's definitely something I've been meaning to look into though and it's been on my radar for future work to be done, so hopefully it will not be too long before I can get around to that. I'm making a mental note that this functionality is desired though so I will prioritize it when I do more work on cl-patterns. There has been a lull in development recently but I'm definitely not done with the project yet :)

As for why cl-patterns has its own system instead of just using cl-collider/sc-extensions: the cl-patterns clock was made prior to the scheduling functionality in sc-extensions, and I usually do most of my Lisp sequencing through cl-patterns rather than other systems. Other systems tend to do things differently which doesn't always make it easy to integrate with them. For example, I have yet to crack full integration with Incudine (basically like SuperCollider, but fully CL-based) either.

I'm not sure it would be possible to merge the cl-patterns clock with the ones in cl-collider/sc-extensions because the cl-patterns clock includes a lot of extra (meta)data in it that is not really relevant to cl-collider. I would not want to muddy up byulparan's library with features that are only relevant to people who opt to use cl-patterns. But ensuring they are easy to use together and don't clash is definitely a requirement for me and I'm sure he would be open to PRs on his projects to make it easier to integrate with cl-patterns.

---

Side notes if you're interested: the version of the clock currently available in cl-patterns is actually the 3rd implementation so far. It's surprisingly tricky (for me at least) to make a clock that is as robust and featureful as it needs to be while still also supporting full compatibility with other systems. The recent work on backend has improved that situation somewhat, but I have also been playing around with ideas for the next implementation of clock, and I think it should clean up/factor out the code a lot and allow ideally all of the following features:

• syncing to other clocks
• playing well with cl-collider's/sc-extension's scheduling
• tempo change curves
• general cleanup/refactor for better code
• tests for the clock (to guard against regressions and ensure all features work as expected) - This has been my priority recently as I want to ensure that the next implementation of the clock does not have any regressions from the current one.

I've been gradually working on something called timeline which will be the basis of the new clock implementation (and will allow for a lot of other features and improvements across the library and related projects as well). Basically it is a pattern-like object that allows one to add and remove patterns to it as it is playing, keeping them all in sync. Kind of like ppar but more general. This will factor out the scheduling aspect and should make it easier to apply math to the target time of each event, allowing (at least) tempo change curves to be implemented properly. Compatibility with other clock systems will likely be a part of clock and backend themselves.

The goal is to solve these problems once and for all, so I want to ensure I get it right this time, once I have a solid block of time to get it fully planned out and implemented.

---

But yeah, thanks again for the nice comments and for checking out the library :) I'll keep you posted when I have relevant news.

[emenel]

Thanks so much for the detailed reply. This is all really helpful information.

I actually think that having multiple different clocks isn't a bad thing in general, and would actually be a nice feature if there was a way to sync them, because it makes complete sense that different systems and sub-systems have their own unique clock-feature needs.

One of the things that I love about the sc-extensions clock is that it does have a :lag keyword that allows for some basic clock slew/curve.

I'll also offer that I'd definitely be willing to help out with some code or troubleshooting if there's a way to contribute to theses (and any other) improvements :)

[defaultxr]

No prob - happy to help! :)

Curving the clock's tempo is definitely something I'd like to implement, though I'm hoping that it will be possible to have different curve shapes, rather than just a linear curve from one tempo to another (which I believe is what :lag in sc-extensions does). So sort of like how SuperCollider supports different curve shapes for envelope segments, the clock should support similar for tempo changes. It hopefully won't be too tricky to implement once I have the improvements I mentioned in my previous reply implemented. 🤞

And thank you for the offer! Yes, I'm definitely open to pull requests and reports for any other bugs you might find! Even if I'm already aware of them, it helps to know what to prioritize when doing development.

Oh, one thing about PRs, though: for minor bugfixes/improvements, you're probably good to go, but if you're thinking of making any big changes to the library, I would suggest opening an issue first before you start coding. Just because I have a lot of stuff in my local copy of cl-patterns that I haven't finished yet, and I wouldn't want you to spend a bunch of time working on something I already have a draft of. Plus that way you'd also be more clear on any requirements for the change/feature. I would hate to have to decline a PR for either of those reasons.

If you're looking for ideas for what to work on, my suggestions are:

• Check the TODO.org document. Most of these are bigger feature ideas. If you want to discuss any of these (i.e. if you have ideas for them or things that should be requirements for the features), feel free to open another discussion or issue.
• grep -r the library for instances of the text FIX (in all caps). These are any issues/to-do items that I found while working on the code. A lot of them are notes to myself, but maybe some will catch your eye.
• Any bugs you stumble into yourself :)

Thanks again and happy hacking/composing/performing :)