I don’t know about A4 but AR has these added dimensions of sound pool and sample management. It’s a ton more complicated than MD and MM. They also originally came without +drive.
3 Likes
The problem I have with the Model:Cycles (and it’s only a problem because I feel it stops it from reaching its full potential) is that there’s two ways of working: trigger various patterns without modifying the sounds too much, or stick to one pattern and modify the sounds. I feel these two working techniques could be brought together for some fantastic creative results. I really feel there is so much potential to this tool that isn’t quite being realised, and it wouldn’t take much to fix it.
4 Likes
I completely agree.
1 Like
Ah, yeah, I forgot the silver boxes didn’t have a sound pool.
The way kits are implemented, with the option of automatic kit reload when patterns are changed is really good imho.
It’s a very seamless process, even with all the possibilities. If a pattern is selected, that doesn’t have a kit assigned, it simply continues to use the ‘active kit’. So it’s possible to build a pattern structure, even without going through the process of building kits before.
Good idea! I guess a simple option to exclude certain patterns in a bank from the usual behaviour (on/off option per pattern) would be possible to implement. Those patterns could then all use the parameters of the first pattern in a bank which has this feature active. Doubt it’s gonna happen, though.
3 Likes
Sounds like a lot of positivity for my idea. How do I go about requesting this as a feature?
What would be really amazing would be access to the firmware source code and the ability to upload it to the Model:Cycles. With the ability to do a full factory reset of course, in case you run into trouble.
See:
3 Likes
I think the idea is really good and I have also requested something similar in the survey.
At the moment, the sounds are hard linked to a pattern and I totally get the idea of staying in a pattern, improvising on it and then changing a pattern for something completely new.
However, I find it difficult to realize longer (live) arrangements. At first I thought that having the option to switch the pattern while keeping the sounds invariant would do the trick, but soon realized that this also may be too limiting.
For instance, maybe one would like to keep a bassdrum sequence on track 1 going and would only like to switch the bass sequence on track 2.
Ideally, each track in a pattern would have multiple, e.g. 8 instances of sequencer information that could be freely mixed and matched during a live performance, for instance:
Pattern 1
Track_1 Track_2 Track_3 ... Track_6
TS11 TS12 TS13 ... TS16
... ... ... TSij ...
TS81 TS82 TS83 ... TS86
TSij is basically the sequencer information with parameter locks and everything, just as it is now. In addition, one could use the same track sound with different sequences and sound locks would still be functional also. With this setup, one could mix and match the sequences, for instance:
Performance
Track_1 Track_2 Track_3 ... Track_6
TS11 TS12 Mute ... Mute
TS11 TS22 Mute ... TS16
...
Here, track 1 is played by the information in sequence TS11 twice, track 2 is played by TS12 followed by TS22, and so on. But, how to deal with polymeters? For instance, TS11 could be 64 steps and TS12 and TS22 could be 18 steps long. Personally, I would just chain them and let the sequences play out completely, but things could get complicated quite quickly, which may be desired, by the way (phasing sequences). Another question is how to handle pattern switching in case of polymetric patterns?
A “song mode” could be realized by simply having a table that specifies the order in which the sequences are played within a pattern.
However, looking at the concept, I can understand why Elektron is a bit reluctant with implementing something like this.
- In the above example, the sequencer information would be multiplied by a factor of 8 per track, adding to the fundamental structure indeed.
- It is not clear how an ergonomic live switching of sequences (per track) and patterns would work with the current user interface.
- Keeping the back compatibility with the current state is important, so that the current tracks of the users are still playable.
- People seem to like the sequencer as it is. For this reason it may be a bit risky to alter the workflow.
- …
At first sight, an easy solution could indeed be to use an external sequencer, however, one would lose all the goodies of the parameter and sound locks.
After all, I still think that having an option to be more creative with the sequences is a really good idea, potentially opening a lot of new performance and compositional options. However, I would also make sure that the current workflow is still functional. In the above concept this could be the case, because one possible configuration is simply
Pattern 1
Track_1 Track_2 Track_3 ... Track_6
TS11 TS12 TS13 ... TS16
1 Like
You’ve certainly thought this through, but I doubt they would go for anything so complicated. I thought maybe about completely turning around the concept of patterns and tracks, so instead of:
1 bank -> 16 patterns -> 8 tracks
It could be:
1 bank -> 8 tracks -> 16 patterns
But this would introduce a lot of complications. I think any suggestions would have to work with the existing workflow and be easy to implement.
1 Like
Have to say I agree. Seems highly unlikely to me they’re going to radically change the architecture at this point. Even
might be a stretch.
Yes, I totally get that idea. Spontaneously I was thinking about this too. By this way one could jam with more complex arrangements while also live tweaking the machines. But indeed, it may cause some complications.
I believe the idea of switching a pattern without changing the sounds could be a nice compromise, because it does not take anything away from the existing workflow and simply adds to it.
However, I am enjoying what can be done with the existing workflow. For instance, I really like the midi tracks on the digitakt, because one can use the parameter locks via midi cc on external machines. Very cool.
One solution to this problem is using an external sequencer, such as another Elektron device, but the problem there is that CC messages are interpolated by the M:C so you can never get the same precision as with P-locks. This is particularly bad for the COLOR and SHAPE on the Chord machine. During the holidays I put in a feature request to disable this behavior. If Elektron can’t add “kit persistence” on the M:C then hopefully at least they can do that so you can use the M:C as a pure sound generator and do your sequencing externally.
OK, feature request has been sent to Elektron. I’ve no idea if they read these or not? I put together a little presentation for them to outline my point: https://youtu.be/hwV5Lmol5-w
Like I’ve already said, it’s a very simple change that could open up a wealth of possibilities.
2 Likes