One thing I would mention though, just as a footnote to your very good point, is that it can still be quite hard to leave detailed documentation of your own work. You either have to note every step as you go along, or you have to do it all at the end. It’s very important to do, but never a priority compared to bug fixes, feature implementation, deadlines, shareholder meetings etc.
If the original product owner behind something leaves, it could definitely slow down the process as the next person has to look under the hood and understand what the heck is going on. Especially if the now former-employee is seen as a bit of a prodigal genius.
Totally depends on the company structure though, and lots of other factors. So that’s why I only mention it as a footnote.
I recently picked up my first Elektron device, a Model:Samples for $200. (In fact my first hardware non-iOS groove box of any sort…). I’m having a blast with it as is: any future updates would be gravy on top. It really is a powerful machine, especially for the price, and though I don’t need one of its bigger brethren, getting to know the model:samples sure has me taking a good hard look at them. Which I’m sure is part of the plan…
Usually I don’t like to speculate on such levels, but like others mentioned, I don’t think it’s reasonable to assume an employee would take part of a product with them.
I’m on the fence about getting one, I bet the knobby interface is tons of fun and it seems to have a certain digital gritiness to it when pushed hard.
The synthesis is actually macro based (afaik), so it’s probably going to be a gold mine of happy accidents. The lfo can be p-locked, so you could basically transform it into a totally different lfo on certain steps by p-locking destination, wave, speed and depth and in the spirit of a happy accident machine, the single lfo would actually help mining accidents.
If you have anything that can send midi lfos, M:C’s parameters are accesible via midi cc.
The LFO menu parameters can be parameter locked. In GRID RECORDING mode, press LFO to open the LFO menu. Press and hold a [TRIG] key, and then use LEVEL/DATA to change the settings.
So I guess the lfo setup parameters (reset, fade and phase) are not p-lockable. This limits the possibilites somewhat, but no big deal, imho.
Btw I like that there’s a short cut for lfo destination and depth. That’s clever. Don’t have to open the menu (which would take away some of the benefits of the knobby interface.
Press and hold [LFO] and then turn a TRACK PARAMETER knob to set that knobs parameter as an LFO modulation destination. Keep turning the TRACK PARAMETER knob to set the modulation depth. This functionality is also available on individual steps on the sequencer using parameter locks.
This distinction between setup and “performance” parameters might exist due to available processing power. For instance, the Octatrack has setup pages for all parameter pages (src, amp, lfos, effects, midi note page, midi arp, lfos, cc) which are also not p-lockable and can’t be modulated (this includes lfo wave shape, lfo target and trig mode, but OT has three lfos per track so it’s not that big of a limitation).
The lfo already is a menu and you can p-lock in the menu. There are also shortcuts for setting target and depth, as discussed above, but it is a “p-lockable menu”. So, if they’d make the lfo setup parameters available for p-locking, it wouldn’t mean major changes regarding UI and UX.
I did not count the analog products because of how different they seem to be from all other elektron products, I do not know how hard/easy it is to add more LFOs to analog elektron products actually. These are absolutely out of reach for me anyways tbh.
I’m quite biased by prior experience in hardware sustaining engineering, but firmware and hardware are rather different use of energies.
Accessories are bells and whistles but not very important to the core product. They rarely sell in enough number and scale to make much money back, so if something fails at launch, losing more money on a loss leader is probably not in the cards.
I don’t think the super simple no-digital-components of the hardware battery handle design would affect firmware development, since they’re not developing a new design and subjecting it to even more stringent safety requirements. It doesn’t need to be their wheelhouse and would detract from Elektron’s overall goals and attentions best spent elsewhere, while the firmware is mature for using any other battery device alongside.
Thanks for clarification!
I asked not so much to challenge you or suggest that just because things work for me that all uses work for others, moreso to spread your knowledge so that if others found it to be concerning, they could email Elektron and also request the bugfix to help it be resolved before it enters EOL.
Model:Samples and Model:Cycles to my knowledge were developed to leverage the R&D of the Digi series in other form factors, helping to amortize whatever investments.
Maybe there might be an extra feature ported from their parent boxes down the line as they mature out, but I have no clue what embedded resources might be free at this state of general stability and I don’t think there’s a lot of… headroom there for additional featuresets considering how they were late added and optimized for the faster (and more maintained) parent platform.
Thanks as well, helps understand what you’re comparing
I think the Models are more or less feature complete in terms of what it needs to do and what bugs there are are quite minimal (secret “mute mode” I’m looking at you).
Of all the features to add. I’d personally like it to have Trig Preview. This feature is essential to how I make music on the Digi boxes and I was very disappointed to discover that the M:C did not have it. However, I use this limitation as a creative tool and utilize other unique features of the Cycles instead (like Machine lock, control all on machine, distortion per track, etc). I ended up getting the Syntakt as well and of course I use Trig Preview all the time on it.
I would love for Elektron to fix what small bugs are left and add a few features, but overall I’d say it’s still a great instrument even if there are no more updates.
My point here was simply that after a perceived Model fiasco, internally I would expect that to influence how they prioritize their overall efforts. I’ve seen that happen, where a project is de-funded from a resource perspective just because “no one really wants to go there”. Not saying this is the key reason for the lack of firmware updates, but it could be a minor influence. Imagine a successful launch of that handle, and a better-than-expected sales performance - that could have led to them thinking the opposite and prioritizing more investments to develop the series.
