How about the other option of changing the patterns without changing the sounds? This would not complicate the workflow and would be easy to implement. Such a simple thing to add but it would open up a wealth of possibilities.
2 Likes
I’d be up for something like that. But consequences can sometimes be deeper than we first think, or create new usability issues.
In another thread I proposed a ‘live mixer mode’ in which track levels are retained when switching to a new pattern. That would solve an issue that for me is very annoying when I play live sets: jumps in volume when I’m mixing track levels live and the next pattern doesn’t have it at the same level. Your proposal goes further and retains all sound parameters.
1 Like
I like that idea. I think it’s probably doable from the point of view of: will it fit in the present hardware interface, though I can’t see exactly what would be the best way. I have no idea how much firmware upheaval would be caused by that though, because effectively you’d be in a new pattern that’s distinct from the old pattern and the new pattern … but I suppose it may not be a lot different to a version of one of those patterns, but with unsaved changes.
Not sure I can see a use for it myself, but if it was there, I guess I’d find myself using it.
1 Like
Another slight variation on that, which I actually just asked for in the survey:
- Move to new pattern but optionally preserve sound and sequence from selected tracks. (E.g. keep rhythm tracks constant while changing melody, chords, or bass)
2 Likes
My suggestion was that when changing patterns, instead of pressing pattern then the trig key, press pattern and trig key. This would signify ‘change pattern but keep current sounds’. I would propose that you have not changed new patterns sounds, you effectively changed the pattern then automatically changed all the parameters to what they were in the old pattern. There for if you pressed func+pattern to reload the pattern, it would change the sounds back to the actual sounds for that pattern. Am I making sense? This way it would fit the hardware interface.
As a software engineer myself I don’t think it would be a huge problem, but I’m just guessing because I’m not familiar with the firmware codebase.
Also, where is this survey you mentioned? I might add to that.
1 Like
1 Like
Having started out with the Digitwins, then a M:C, I was pretty used to their pattern workflow.
I recently bought an Octatrack and the whole parts structure has been a revelation. It really does kinda ruin the M:C pattern workflow a bit for me, so now I’m probably going to end up sequencing it from the OT so that I can use the M:C’s pattern structure as kits.
I think it would be pretty difficult to implement some sort of kits structure within the M:C itself, even if Elektron were inclined to do it, which I’m not sure they are.
2 Likes
That’s interesting … I’m considering getting an M:S so that I can use one as a constant “kit” while the other has developing melody and harmonic structure … not 100% thought this through though.
1 Like
Yeah, that could work, but, as much as I love limitations, the sacrificing of audio tracks for midi tracks and no audio in makes using them together feel a little bit like multiplying the limitations.
If the M:S had an audio input and sampling capabilities the two models would really be awesome together.
After a month of owning the OT, the possibilities for controling, Sampling, looping and processing the M:C are hurting my head, it’s just endless.
2 Likes
Isn’t the kit structure on A4/AK and AR similar to MD and MM?
Octatracks parts are basically kits, though only four are available per bank.
Anyways, I don’t think kits are complicated per se, just requires some time to get to know the machines and structure, rtfm, you know^^ 
For a new user that wants to dive right in, of course it can be confusing when the sound changes, seamingly out of the blue and there seems no way of getting it back.
But then, those machines were not made to ‘dive right in’ without rtfm-ing…
I thought about getting non-kit Elektrons many times, especially Digitakt and Digitone, but also Model:Samples. Ultimately the lack of kits is a show-stopper for me.
1 Like
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.