Gotcha, I see what you’re saying here. There would be no way to crossfade between the two patterns though, it would just be an immediate switch between the two. But I think I understand a bit better what you are going for; thanks for clarifying.
I agree with you. This can be relatively easily achieved by a firmware upgrade.
On the other hand there are number of UX concerns which needs to be solved.
The feature needs to be presented properly.
The major audience of the rytm might not find this useful because the majority of live sets are if I put it properly wants to be on the “safe side”.
While I appreciate that, I hope that the designers and developers in Elektron also understand that a lot of interesting art comes from creating the core material in the moment also. Rytm could be a great device to do that with the right future design decisions.
1 Like
On top of that, I’m imagining a future where we could have open source firmware for these kinds of devices.
The real value of the device comes from the analog sound engine, the hw interface, design etc.
I don’t say that firmware is not valuable but subjectively that is secondary even if it is a beautifully designed one.
Let’s take Rytm as an example.
Imagine a lot of forks of the firmware where people experiment on feautres. Some distributions will not be stable, some will be even malicious which might brick the device but in the end working with the community Elektron will obtain a lot of real life testing and original ideas for free and the Rytm users who would like to use only the stable firmware published by Elektron will benefit from that because the most loved experimental features will naturally land on the stable firmware.
Some cheap clones might appear but I think the hardware of Rytm is rather sophisticated so that is not very likely.
Long story short I’m pro open source firmware and I hope we’ll have a future like that.
I’d like to have control over the software of a device when I buy it.
1 Like
This feature is clearly aimed to people that want to perform live and improvise a set starting from a blank canvas, and all empty patterns. Would allow to break the limit of the 64 steps patterns and have more complex arrangements on the fly. This will also be useful when the set is performed by more people jamming, because the more the number of people the less you can hope that a pre-arranged material would fit the situation.
But this would be useful imo also when composing, bringing the act of composing nearer to the act of performing. Obviously is aimed to professionals that know what they are doing (i find my background with traditional instruments helps regarding this).
I would be curious to know what you think about my proposed keystrokes, and how would you imagine the feature and the UI. Also, if you see any drawbacks in what I proposed so far.
I’ve read your feature request in detail.
The proposition is just how I’d think about it also.
I don’t see no drawbacks with your approach other than having to extend the user manual with a few more pages.
A major portion of Elektron user base is learning how to play this instrument from youtube tutorials. I think a feature like this would be easily covered there in detail.
I also do not agree with the “this feature might break simplicity” argument. Elektron gear are if it is the right way to put it notoriously complex for a beginner and almost requiring you to be a power user if you’d like to reflect your style. I’d say that the complexity introduced by exposing this feature will play well with the existing design.
I personally recently building a street setup using the Rytm and the general idea is to enable improvisation in big variety of outside spaces. The setup is rather complex and rich but Rytm is also a crucial part of it.
With this setup I never know even the general musical style when I start touching the setup and doing everything on the fly. I think after laying out some musical material, composing a pattern (you can sort of hear how it’ll sound when you look at the sequencer if you have enough experience) on the fly and then immediately starting it has a powerful effect on the improvisation.
But if just after that I would like to make a dramatic change and I don’t want to stop the rytm, I’m sort of stuck.
If I really need this change, I kind of integrate, stopping the rytm - composing another pattern on the fly and restarting it to my general musical approach to the improvisation. This is somewhat limiting.
If this feature was in place, it could be much more fluid and also I can do incremental changes through patterns. If I’d like I can slowly transform the kit track by track composing a new pattern for every track. I can also go back if it is necessary. Many other ideas could be implemented on the fly.
It would make working with the Rytm much more intuitive for those cases.
If there are firmware devs among us I’d really like to know the reason behind deciding not to integrate this feature.
I’m sure you’ve thought of it but then decided not to integrate it. I think the requirement comes quite organically.
I think the answer to why the elektron devs haven’t implemented this feature is the same answer why they have not implemented lots of features desired by a niche group, because they are a small team and simultaneously need to be very strategic with where their dev hours go, and also are fairly specific in how they use the devices. So the question becomes “Do we design an entirely new interface for an almost 10 year old instrument, so that the 10% at best of our users who use the device for live improv, can have an amazing experience” The answer sadly, is no. Like maybe it would happen if the devs were also very passionate about this idea, but they clearly have a specific use case in mind with these devices, and live improv is not their highest priority. Or maybe something like this could show up in the next generation of instruments. But if they did this on the old hardware, they would spend many many hours (thus tens of thousands of dollars at least) working on this update, and how many more Rytms would it sell?
1 Like
The surprise of not having this feature originates from the fact that it is relatively easy to implement.
I think your arguments are realistic and probably in a general sense expresses the current status quo in many hardware product producing companies.
For the specific feature being discussed here, I have the gut feeling that it might worth for them to try it out since it might make a portion of their users happy which in turn would advertise their device more and it might not take a lot of dev time to implement. It feels like a relatively easy win win.
On the other hand we’re just talking around a lot of assumptions. The inner company dynamics and concerns are impossible to guess.
Where do you get the idea that it is “relatively easy to implement”? Just because an idea is simple in concept and seems simple when you think about it, once the rubber meets the road of actual implementation, things get very complex very very quick. Like the data structure that the patterns use in order to switch instantly might make it very complex to separate the pattern currently loaded into memory for editing and the pattern loaded into memory for playback. Expecially on embedded devices like these which are programmed for absolute maximum efficiency, it is very possible that the pattern and sound memory are linked at a very core level. No one outside of Elektron can say though, but I think if firmware updates were that easy we would be seeing a lot more of them.
1 Like
Have two boxes or just come prepared for your set.
the needs of the many outweigh the needs of the few…or the one
your way of using it is very similar to mine, and the same exact scenario happens to me. Let’s say I develop a jungle pattern, starting with hi - hats, and then bring in kick and snare. A trick to have dramatic change here is to mute kick and snare tracks, program the pattern I want, and then unmute it. If then I decide I want to go on a bridge section, lets say with a four on the floor and swing hihats, I can’t program that in a new pattern and have the ‘dramatic change’ you just mentioned and I’m stuck.
I think the answer to why the elektron devs haven’t implemented this feature is the same answer why they have not implemented lots of features desired by a niche group
this is very true, but on the other hand the music made is influenced by the instrument used to make it, and the thing is bidirectional. Today electronic music, like ambient or techno, is influenced by the fact that in these drum machines is easy to change the sounds and build evolving music in this way, and much more difficult to change abruptly the patterns. But that doesn’t mean that a feature like the one proposed, once rolled out, would not influence the style of music made and thus become necessary for more and more users.
Do we design an entirely new interface for an almost 10 year old instrument
and
Where do you get the idea that it is “relatively easy to implement”
my impression too, as I imagine the feature, is that is relatively easy to implement. there’s no new interface, everything would be exactly as it is now, from UI perspective, but with the difference that the pattern played is not the one edited. Maybe the flashing lights on the pads, I would turn them off as the light going through the steps, just to underline that the pattern played is not the same as the one edited. I think all the project informations are already loaded in memory, and so all the patterns. In code I imagine they refer to things as Sequencer[pattern]->step[current_step]->note_value just to make a silly example, so like a classical C array. they would have just to change the index the way I explained on a couple of posts above.
Have two boxes or just come prepared for your set.
I don’t understand why so much negativity, as if a feature like this one, that would not influence any workflow of anyone unless they want to use it (and they probably quickly would), attracts those hate reactions.
The point is, this in a way it’s a feature that is already in, with the [Page] button and used by the majority of the users. The way it’s proposed here, and what you would be able to do with that, is in the end an extension of what you do with page button. Instead of 64 steps, you could have 8 patterns of 16 steps in a chain, and you would have created in essence a pattern of 128 steps. With the much more powerful options, for example you could change a kit for 16 steps in the pattern 5, or have pattern 5 made of triplets, like 24 steps with bpm with a factor 1.5. I mean, how this is not so appealing to people is a mystery.
1 Like
I can see this going the way of the recent threads on model:cycles and model:samples. Only people who know this particular code (people who have had a direct or close relationship to it) have any idea how easy or hard it is. Anything else remains guesswork.
Obviously we are guessing here, for experience things are never so straightforward in practice, but if I would have to bet, I would bet that it’s an easy change on the code base, especially compared to the added powers it would give to users.
Surely the impact on performance for example, would be zero, compared to another popular feature request as the second lfo, just to quote one.
So what you are talking about is the simplicity of the concept, not the simplicity of actually developing and programming it. And even then, you still need new functionality to actually do what you are asking. What button combo would you use to change the which pattern is currently playing? what about the button combo to change which pattern is being edited? Is there going to be something on the screen that lets you know that a different pattern is being edited than being played? So there are lots of concerns about the user interface for a development like that, and that takes lots of time and consideration, and that is just the user facing side of things. You also have the underlying memory structure of the device. It is very possible that the device is built around a memory structure where the active pattern being edited is the same as the one being heard, so only one pattern is ever active in memory. This update would require them to have the information of two patterns active in memory at the same time, which might be possible, but might involve a complete rewrite of the way the pattern memory is handled, which is absolutely fundamental to the functioning of the device, and introduces soooo many avenues for bugs that would impact existing user’s live sets that need to be reliable. It’s just never as simple as it seems on the surface, especially with embedded processors like these.
That is to say, that I do really like this idea, but I think for it to really be taken to the best possible conclusion, that it would require having this as the core functional idea while developing the device in the first place, and it is extremely unlikely to be seen on any existing devices. But then again I never thought the digi’s would get song mode. The fact that Elektron only release like 5 firmware updates a year shows that there aren’t any easy firmware updates, or they would be doing them all the time.
1 Like
If you look at the very basic big blocks.
We’re able to edit while playing sound and also update several user interfaces. This hints that a sort of RTOS is running in the device. This means that the framework for concurrent tasks are there.
I assume that the memory loads are not dynamic for a project to achieve performance. If that is not the case loading a pattern to memory and the performance overhead which comes from that background task shouldn’t effect the use case directly.
One more assumption that there is enough memory allocated to load just one more pattern and the device is not using the memory to its limit while in operation.
Data structures might be tightly squeezed and the firmware code is probably designed in a data oriented way but expecting a wide spread refactoring effort for extending a couple of data structures sounds like a bit overkill to me.
I wouldn’t expect that pattern and sound memory are linked at a very core level but we don’t have an easy way to know that.
All these and my gut feeling tells me that it might be relatively easy to implement.
I don’t claim that it is easy to implement, no outsider can. I just wanted to hint that it is likely. Maybe using is was misleading. My bad.
Yeah, all I mean is that this would be closer to song mode in difficulty/time to develop than a bugfix update, and the rytm doesn’t seem to even be getting bug fix updates any more. It seems pretty clearly near the end of its life to me, so i just don’t think Elektron want to invest any more time into it. I think to Elektron, it is likely complete as an instrument.
Thanks this is actually what I think these posts would be great, to define the user scenarios and think about these details, I’ll try to answer to your questions about the feature:
What button combo would you use to change the which pattern is currently playing? what about the button combo to change which pattern is being edited?
As I imagined it you have two modalities, that you enter with the keystrokes I wrote in a previous post above (I will not repeat that part). when you are in legacy mode you change both patterns (edited and playing) with the usual keystroke, for example [D]+[1]. when you are edit pattern mode, you change only the pattern to be edited, for example [D]+[2] edits the pattern d2 while d1 is still playing. Then you go back to legacy mode and the pattern you see on screen and control is the one that is playing , d1. at that point you can press [D]+[2] to play pattern d2. In other words, when in ‘edit pattern mode’ you cannot change which pattern is playing, it will be constant or following the chain/song if in chain/song mode.
Is there going to be something on the screen that lets you know that a different pattern is being edited than being played?
Yes, as I wrote in the post above I’d advise to have some indication on screen, an icon or maybe both pattern indicated (edited and played). Personally, in chain mode I’d love to see more of the patterns sacrificing the track level, (as happens when i think you keep chain button pressed). If you editing patterns through the chain, maybe the selected square brackets could indicate the pattern edited while the inverted the one playing, similar to song mode.
It is very possible that the device is built around a memory structure where the active pattern being edited is the same as the one being heard, so only one pattern is ever active in memory.
My impression as a software dev, and of course is guesswork, is that all the patterns and project info (kits, 127 samples etc) are in memory. If you would need to load those it would be much more difficult to have seamless transaction between patterns or kit switches. All patterns, or kit parameters, are just few numbers, compared to information you need for example to load a sample, as order of magnitude.
1 Like
Regarding limited usefulness, I just bumped on this random post (the current last one on " Too repetitive or too much changes in a song")
I watched a Tom Cosm Video years ago, he did two seperate sections in Abelton live with lots of space between these two complete build ups, he then removed from these build ups parts , /sounds, untill section 1+2 intersected. So he got two different escalation points, where he just had to figure out a way how to move from A to B, this way forces you to think also how much you can strip from your arrangement. I think this is also applicable to Elektron, Make Pattern 1 and 3, and then copy pattern one to two, remove elements , and copy a track from 3 to two.
It’s a shame that those kind of workflows (which I think are soooo common) cannot effectively be done live. Also in a studio, after making pattern 1, you need to stop, then make pattern 3, stop again, then start to work on pattern 2, stopping every time you want to take elements from pattern 1 or 3. I think this stopping disrupts the creative flow so much.
With our proposed functionality instead, you would never need to stop having music playing. While pattern 1 is playing, you could set edit pattern mode, select pattern 3 and program a rough version of it, then go back to legacy mode and play pattern 3, adjust it and make it prettier (this live would be effectively percieved as evolving music), jump again to edit pattern mode, go to pattern 1 (while 3 is still playing), copy the pattern, go to pattern 2, paste the pattern, maybe removing the bass part, then go to pattern 3, copy the bass part, go to pattern 2 and paste the new bass part, modify it, and then finally go to legacy mode and play the pattern 2. Consider that during all this editing phases, you can still keep music flowing and changing tweaking other instruments, and having the trigger probabilities on the pattern playing contribute to movement. If you have clear ideas (which a musician should always have), this editing phase could be quite fast and not impact the flow of the performance. The audience will only listen to what is written in bold and italics, and yet so much could be done under the hood and presented to the audience at the right moment.
1 Like
There was a very popular relatively-simple feature request for machinedrum and monomachine more than 15 years ago
(when elektron forums were still community-run and were called elektron-users, so it might be hard to find now)
This feature is very related to this and it shows how this need exists for a long time.
It was as simple as:
‘Copy and save current pattern to next empty slot’
This allowed you to save a snapshot and continue editing your pattern live, giving you at the same time the option to save your new pattern and load the previous snapshot.
2 Likes
Hi, I think the need comes exactly from the same origin and our functionality extends on that. However, I think what you quote here is currently doable. You could:
- copy the pattern with [FUNC]+[REC]
- paste the pattern anywhere else holding: [Bank]+[Trigger]+[STOP] until display confirms the paste operation, for example for bank A2 [A]+[2]+[STOP]
- use direct jump to jump whenever you want to the copied pattern, or use sequential to cue the copied pattern
You need to know which one is the empty slot, but this is easily understandable if you keep pressed a bank button.
However, our proposed functionality adds to that on the fact that you could change the copied pattern however you want, without any time constraints, and then present to the audience (or to yourself if you’re just composing) the change in one go.
In the scenario you are considering, two copies of the same pattern, currently it’s always a race with the playing cursor. Let’s say the playing position is currently step 1, and you want something to happen at step 13, you have time until the playing position reaches step 13 to edit your desired change in. This can be fine if you just want to plock the increase of the decay for the open hat. But what if you want to do that, and also add four steps on the snare at 13, 14, 15, 16 and change the level on those with plock and open the filter slightly and add 4 chromatic notes on the bass, for example D,D#,E,F at steps 13, 14, 15, 16? Will you have enough time to complete this operation until the playing position reaches step 13? You can easily see that there is a race condition, that limits the kind of changes you are able to present to the audience (or yourself) in one go. With our proposed functionality, and the feature you quoted, you could copy paste the current pattern on a new one, edit that without any time limit constraints (no more playing position induced anxiety), and then actually play the new version of the pattern when you are ready.
With my post I mainly wanted to express the fact that this is a need expressed for a long time for elektron live performers, and a solution that apparently doesn’t require a lot of programming has been requested.
Doesn’t this require you to load an empty pattern first, and thus not really doable live?
(For a moment I thought paste into target pattern had already been implemented and I missed it)
Edit: it is there!!! That’s great! I wish I could have it on my MNM. Does it exist also in octatrack?
1 Like