Kalliste – Interactive Harmonic Sequencing for VCV Rack

Announcements
1

Kalliste is now officially available for VCV Rack.

Kalliste is a free and open-source plugin designed for interactive harmonic sequencing. Rather than generating harmony automatically, it lets you build chord progressions and arpeggios yourself, while hearing every change in real time.

K-ARP K-SCENE
K-ARP K-SCENE850×573 90.6 KB

The plugin includes two complementary modules:

K-ARP — combines a chord sequencer with a visual programmable arpeggio matrix.

K-SCENE — stores complete K-ARP configurations as scenes and lets you organize them into longer musical structures, with automatic or manual playback.

Kalliste can be used with musical knowledge, but it was also designed for experimentation by ear: choose chords, modify arpeggios and listen immediately to the result.

Since the pre-release announcement, the documentation has been significantly expanded. A new Quick Start Guide now covers both modules in detail and includes visual reference sheets for their controls and mouse actions.

Kalliste is free and open source (GPL-3.0).

VCV Rack 2

Kalliste in the VCV Library:

Quick Start Guide:

Feedback and musical examples are very welcome!

13 Likes
2

I’m starting to play with K-ARP (as in, I just now added one to a patch for the first time). I’m excited by this as a fellow VCV plugin developer who wants to become a musician but is still in the early stages of learning music composition. I really want to learn about chords, scales, etc. and how they work at an emotional level for the listener.

The first thing I notice about K-ARP is that it has a built-in clock, but no way to override it with an external clock signal. Would you consider providing a clock input port? If no cable is connected, it would keep using the internal clock like it does now. If connected, it would use the rising edge of each gate input as the next time step.

This would allow doing interesting things like Euclidean rhythms or Bernoulli gate random stepping, while keeping in sync. Generally, there is one master clock signal in a patch. If two different modules want to be the “clock boss”, it’s hard to use them both in the same patch.

I’m assuming the “RST SEQ” input port is essentially a reset/sync trigger already, which is the only other thing you need for generalized external control of stepping the sequence.

2 Likes
3

Thanks for the detailed feedback — and yes, your understanding of RST SEQ is correct.

An external clock input was actually considered during K-ARP development. I initially explored the idea of letting an external clock drive the chord sequencer, but this introduced a number of timing issues: K-ARP would have to measure the period between incoming pulses, deal with jitter and resynchronization, while at the same time deriving the ARP subdivisions from that changing period.

Because ARP LEN subdivides the duration of each chord internally, I eventually chose a simpler and more deterministic architecture: K-ARP is the time master, its internal BPM defines the chord duration, and OUT CLK is provided so other modules can follow K-ARP.

That said, your use case is very interesting — especially Euclidean or Bernoulli-controlled stepping. Now that K-ARP’s timing engine is stable, I think it is worth revisiting the idea and seeing whether an external clock mode could be added cleanly without compromising the current behavior.

So: not a promise yet, but definitely something I will look into. Thanks for suggesting it.

3 Likes
4

Just to add some technical context to my previous reply, the main difficulty I encountered with an external clock was not simply detecting incoming pulses.

K-ARP has to use the duration of each chord to calculate the timing of the arpeggio steps inside it. With the current internal clock, that duration is known in advance: the BPM determines the chord duration, and ARP LEN divides that duration into equal arpeggio steps.

With an external clock, K-ARP can only measure the interval after two consecutive pulses have arrived. For example, if the measured interval is 500 ms and ARP LEN = 4, the four arpeggio steps should each last 125 ms. But the duration of the next interval is not yet known.

In practice, an external clock may also have small timing variations (jitter): 498 ms, 503 ms, 499 ms, etc. K-ARP would then have to decide whether to use the previous interval, average several intervals, filter the measured tempo, or continuously resynchronize the internal arpeggio timing.

Your Euclidean/Bernoulli example makes the question even more interesting. If an expected clock pulse is deliberately removed, K-ARP cannot know in advance whether the current chord should simply last longer, whether the tempo has changed, or whether the external clock has stopped.

These were essentially the reasons I eventually chose the current architecture: K-ARP generates its own timing, and OUT CLK allows external modules to follow it.

However, this was decided quite early in development. Now that the timing engine is stable, I am very interested in revisiting the problem. Since you are a developer, if you have thoughts on a clean way of handling the prediction/resynchronization issue while preserving ARP LEN subdivisions, I would be very interested to hear them.

2 Likes
5

OK, I’m starting to understand that having a general CLOCK input would cause some problems in K-ARP functionality that either need to be solved or ignored.

I have a similar issue in my delay/loop module Sapphire Echo. It does not have an internal clock; it receives an external timing signal through a clock input port.

When the clock pulses are arriving at a regular rate, there is no problem. But if there is an abrupt change in the pulse interval, all of my virtual tape loops have to adjust their speed to match the new rate. They can’t do this immediately (I simulate them as actual wheels with angular momentum), which gives some temporary distortion as they slew to the correct new speed.

And of course, Echo doesn’t even know that the rate has changed until the next pulse arrives at an unexpected time.

The temporary pitch distortion is unpleasant, so what I did was to provide an option to toggle the input port between a CLOCK mode and a RATE mode. The CLOCK mode preserves the older time-between-pulses behavior for compatibility with older patches. But if you click on the word CLOCK, it toggles to RATE, which interprets the port voltage as a steady V/OCT signal, where 0 V represents 1 Hz. If you want the tape loop to be 4 seconds long, that is 1/4 Hz, so the RATE input to achieve that would be a steady −2 V.

In RATE mode, I still have tape slewing problems, but it is much less annoying. The instant the voltage changes, even a little bit, Echo knows immediately and can start slewing the speed immediately. It does not have to wait until the next pulse to find out that the rate has already changed. This approach might fit better for K-ARP?

Thinking more about it, my idea of a Bernoulli or Euclidean gate input may be too fanciful for what K-ARP actually does; it was just a random idea I had, not something I would struggle to implement if I were in your shoes.

So I would like to revise my request! Would you consider

  • A CLOCK and/or RATE port.
  • I think I still prefer CLOCK to RATE, because it fits better with how most patches operate. So if you can only pick one, I think CLOCK would be better.
  • In either/both, if the resulting BPM changes, it would be acceptable for it to have to wait for 2 or 3 consecutive loop cycles that are consistent before changing the timing behavior.
  • Don’t worry about supporting exotic Bernoulli/Euclidean signals. Correct behavior is only guaranteed while the effective rate is steady. If you change the rate, we all agree it’s OK for K-ARP to act “wonky” for a brief time before it settles down again.

In summary, the benefit is that users can control K-ARP’s speed externally, and sync it with everything else in the patch that needs syncing. It would support changes of rate from a “configuration” standpoint rather than a “performance” standpoint, if that makes sense.

What do you think? Great conversation!

3 Likes
6

Thanks, Don — this clarification changes the problem quite a lot, and your revised request makes much more sense to me.

I agree that the original Bernoulli/Euclidean idea would make K-ARP responsible for interpreting irregular musical events as timing information, which is probably asking too much from the current architecture.

What you are proposing now is different: use an external signal mainly as a tempo reference, while allowing K-ARP to keep its internal subdivision engine.

That seems much more realistic.

My first thought would be:

  • No cable connected: K-ARP behaves exactly as it does today, using its internal BPM.

  • CLOCK mode: K-ARP measures incoming pulse intervals, waits until a new rate looks stable over a few consecutive cycles, then updates its internal chord duration. ARP LEN would continue to subdivide that duration internally.

  • RATE mode: conceptually even cleaner, because the target frequency is known immediately from the input voltage, without waiting for two pulses.

I also agree that CLOCK is probably the most natural choice from a VCV Rack user’s point of view, since most patches already have a master clock. RATE could perhaps be an optional secondary mode rather than the main interface.

The remaining question, as I see it, is less about BPM detection and more about phase correction: when an external pulse arrives slightly earlier or later than K-ARP’s internal prediction, should K-ARP snap immediately to it, tolerate a small error, or correct gradually?

But your suggestion that rate changes are more of a configuration change than a performance gesture makes this much easier to reason about. If K-ARP is allowed 2 or 3 stable cycles to settle after a tempo change, I think this becomes a very plausible feature to investigate.

So yes: I am now much more interested in revisiting external timing than I was after my first experiments during development.

And thanks for the Sapphire Echo example — it is very helpful because it is essentially the same “you only know the rate changed after the evidence arrives” problem in a different context.

1 Like
7

I don’t know all of the details of what you’re doing, but you could ask that the incoming clock signal is already to some extent multiplied. My Entrian Sequencers ask for an x4 or 1/16th clock, so they see four ticks per beat. That minimises (but doesn’t eliminate) the jitter introduced by clock slew.

I use an internal clock multiplier to go from the incoming 4PPQ clock to the internal 96PPQ used by the sequencer engine. To ensure that every clock tick produces the required 24 internal pluses:

  • If the clock slows down, you get a pause in the ticks.
  • If the clock speeds up, the missing pulses are output during the next tick, so the rate briefly accelerates.

Giving it a wildly variable clock gives janky results (which of course you might find delightful because why are you giving out wildly variable clocks?) but some “normal” level of slew in the clock produces the “right” results.

(This system doesn’t allow you to get good results from a swung clock, but Entrian Sequencers have internal Swing support that goes much further than just swinging the clock.)

2 Likes
8

Thanks — I think I understand the approach.

If I understand correctly, the important point is that your sequencer does not receive only one timing event per beat. By requiring a 4PPQ external clock, it gets four timing references per beat, then multiplies that internally from 4PPQ to 96PPQ. So the engine has much more frequent opportunities to detect and correct timing errors.

That is particularly interesting for K-ARP because my main concern with an external clock is exactly the interval between the timing information I receive and the subdivisions I have to generate internally for ARP LEN.

Your description of what happens during tempo changes also helps: rather than trying to predict a change perfectly, the engine accepts a temporary timing error and either waits when the external clock slows down or briefly catches up when it speeds up.

I also understand the limitation regarding wildly varying or swung clocks, and I don’t think that would necessarily be a problem for K-ARP. Following the discussion above, I am now thinking primarily about external clocking as a way of synchronizing K-ARP to a reasonably stable master clock, not as another source of musical sequencing information.

One question from your experience with Entrian Sequencers: how important is the 4PPQ requirement to getting satisfactory results?

In other words, do you think 1PPQ with some period filtering/stabilization would inherently be too sluggish or inaccurate, or was 4PPQ simply the best engineering compromise for your particular sequencer architecture?

I’m asking because keeping the external clock interface as conventional and simple as possible would be valuable for K-ARP, but if a higher PPQ makes a substantial difference to synchronization quality, that’s obviously worth considering.

K-ARP has only just been released and its current timing engine is stable, so I’d like to take some time to explore and understand the different approaches before considering how external clocking might fit into a future version. For now, I’m very interested in learning from your experience and discussing the possible solutions.

9

One other approach is phasor control of time. It is the most completely solid timing method, sample accurate timing.

4 Likes
10

Thanks — this is an approach I hadn’t considered, and I think I understand why you describe it as the most solid timing method.

If I understand correctly, instead of K-ARP trying to infer continuous timing from discrete clock pulses, a phasor would continuously tell it where it is within the current cycle. That seems particularly interesting for K-ARP because ARP LEN is fundamentally a subdivision of that cycle: with ARP LEN = 4, for example, the four steps could correspond directly to four quarters of the incoming phase.

So conceptually this actually seems to fit K-ARP’s architecture very well, and it appears to avoid much of the prediction/jitter problem we have been discussing with CLOCK.

My question would be more about interoperability: how standardized is phasor timing between VCV modules in practice? Is there a commonly accepted voltage range, cycle definition and reset/transport convention that a module like K-ARP could reasonably expect?

K-ARP has only just been released and its current timing engine is stable, so I’m taking the opportunity to understand these different approaches before considering what might belong in a future version. This discussion is proving extremely useful — thank you.

3 Likes
11

I’m afraid have no evidence, because it’s always worked that way. It seemed intuitively obvious that that 1PPQ would be too janky with a variable clock, so I never even tried it, but that was just one inexperienced guy’s opinion. :slight_smile:

Why didn’t I go to higher multipler? I don’t remember, sorry. 4PPQ felt like a good compromise. All based on vibes, not a satisfying answer…

1 Like
12

The short answer is Hetrick phasor devices seem to use the rising saw from 0-10v as timing cycle source, but the very nature of the phasor means I can warp that initial frame of reference very much. The Hetrick Phasor generators and Cv Funk Hammer phasors are great to use as a basis for modular patching, and when a device needs a ticking clock one can use a Hetrick devices that links that ticking to an underlying phasor.

And a number of sequencers and devices can use this phasor, but it is not universal by any means. But 0-10v rising saw seems the usual way to move as expected in most cases and the devices that allow phasor movement all seem to use this “standard” for now. To see some of the Hetrick collection demonstrated, their is a nice long video by Omri about the collection.

2 Likes
13

Thanks Richie and cubistguitar — both answers are very helpful.

Richie, no problem at all about the lack of hard evidence! Knowing that 4PPQ was an engineering choice that proved reliable in practice is already useful information.

And cubistguitar, thanks for confirming both sides of the phasor question: 0–10V rising saw seems to be a useful de facto convention within the phasor ecosystem, while phasor timing itself is not universal across Rack. I’ll definitely have a closer look at the Hetrick modules and the Omri video you mentioned.

For now, I’m going to let all these ideas settle a little. K-ARP has only just been released, and this discussion has already given me a much better understanding of the different approaches to external timing.

Thank you all for taking the time to share your experience — I’m learning a lot from this discussion.

1 Like
15

Thanks — this is extremely helpful. Your explanation of 1PPQ vs 4PPQ finally makes the tradeoff very clear to me: the real benefit of the higher PPQ is not resolution itself, but reducing the time during which K-ARP has to continue subdividing from an outdated period estimate.

Your point about filtering is equally useful. I now understand that this isn’t simply a matter of finding a sufficiently clever filter: stability against jitter and responsiveness to genuine tempo changes are competing requirements, so at some point this becomes a design choice rather than just an implementation problem.

The phase-locking suggestion is particularly interesting. Until now I was mostly thinking in terms of measuring the incoming period and deciding when to replace the internal estimate. Tracking the phase error as well, then gently correcting the internal rate instead of hard-resetting the phase on every incoming pulse, seems much better suited to preserving K-ARP’s internal ARP LEN subdivisions.

Clamping the correction and rejecting obviously abnormal intervals also make a lot of sense.

I’m going to keep all of this in mind and let the idea mature before deciding whether external clocking belongs in a future version. K-ARP has only just been released, so I’m enjoying this discussion as an opportunity to understand the problem properly rather than rushing toward an implementation.

And thank you very much for the comment about the modules and the arpeggio matrix. The visual, directly editable matrix is really at the heart of what I wanted K-ARP to be, so I’m especially pleased that this is the part that caught your attention.

16

You have to be careful of going further than just adapting your rate, for instance to “rejecting obviously abnormal intervals”, because you risk getting out of step with other sequencers running on the same clock. You need to ensure that for every incoming pulse, your engine processes N separate pulses (where N is your multiplier) and so does everybody else.

I suspect that’s also a potential danger with mixing phasors and clocks, although I’ve never done that so I can’t speak from experience.

(This thread has seized on one tiny aspect of your module and mostly disregarded the rest - I’m glad you’re finding this part useful, but if you want to detach it into another thread, please do!)

1 Like
17

Thanks Richie — that’s an important distinction, and I see the problem with my wording about “rejecting” abnormal intervals.

Filtering an abnormal interval out of the rate estimate is one thing; ignoring the incoming pulse itself is quite another. If every other sequencer counts that pulse and K-ARP doesn’t, K-ARP could indeed become permanently one step out of phase with the rest of the patch. That’s obviously much worse than a temporary timing error.

Your point that every incoming pulse must ultimately account for exactly N internal pulses makes the synchronization requirement much clearer to me.

And yes, I think you’re right about the thread too! What started as one feature suggestion has turned into a fascinating discussion about clock synchronization, while Kalliste itself has almost disappeared from its own thread. :slightly_smiling_face:

I’m very happy that the discussion happened here — I’ve learned a lot from it — but if it continues much further, separating the clock discussion into its own thread probably makes sense.

2 Likes