I’m looking at implementing step clips in our solution since I am working on a drummachine but now having played with it a bit and reviewing the code, I have a few questions:
Some of the data decisions are quite odd, such as concatenating notes into patterns via 1001, and feels really limiting - Is there a particular reason for it? Same question with the comma separated values in the properties for sequence.
By default the step sequencer is giving me 8 channels, with odd intervals for each of the notes that are assigned by default. I know I can change this but is there again a particular reason for it, given that for example the micro drum machine in waveform has 16 channels?
Is it possible to do triplets?
In all honesty, the whole thing feels a little less mature than the rest of the code body that I’ve been exposed to, but there’s some really nice touches there such as the probabilities and pattern repeats.
Is working with step clips still the recommended solution for anyone looking to implement a step sequencer in this application, or would it be better to work with midi directly?
I think you have to bear in mind that this is a shipping product that has evolved over time. Sometimes you’re just stuck with legacy design decisions. Having said that, I don’t think StepClip is that bad…
Well it’s a grid so a binary pattern seems most appropriate. What other form would you use? The only thing I can think of is a set of velocities but these were added years after the initial grid where only the channel had a settable velocity. The binary pattern is very quick to parse and interact with (usually via a juce::BigInteger.
I think that was just a sensible layout at the time. I think it comes from a standard mini MPC layout or something like that.
No, not at the moment. We are toying with the idea of adding note-splits (so you could split in to 3 to make a triplet) and note-ties (to make long notes).
StepClip really does lend itself well to grid based patterns but if you need complete control MidiClip should get you there.
Thanks for the detailed responses - sorry, I think I came off as a bit rude in my post but it wasn’t my intention. I had a hunch this might have been one of the earlier aspects of code base and you guys had other higher priority items to tackle other than reworking this, which probably is hard to do considering production code relies on it.
That said, the product we’re working on caters for the moment mostly to electronic/hiphop/trap producers, and that genre can have intricate hi-hat rolls and dynamic triplets/time-signatures with their percussion which I’m not sure the step clip is evolved enough to solve, so maybe working with midi is the best bet.
All in all, really enjoying the tracktion engine so far and it’s proven invaluable to our business so great job to you and the team for creating this piece of tech!
I guess the main things that have undergone serious surgery in the past few years are all the playback engine stuff. It’s harder to change to model as so many people rely on the properties etc.
I think for your case, having your own model of what your step grid looks like and then just generating MIDI for it is probably the best bet. Hope that helps.
