I’m not bringing arguments to not develop, just trying to instill a sense of realism. Nothing I say is going stop anyone doing anything. I just happen to think it’s unlikely that Elektron will see any value in helping these things along. OTOH the digi boxes got song mode (which it was long claimed would never happen), and Deluge went open source, so what do I know.
2 Likes
In threads which are addressing demands similar to this I encounter a lot of educated assumptions about why sharing/maintaining docs or just sharing docs in an unsupported form makes sense or doesn’t.
What I’d really fancy is a defining statement from the relevant Elektron dev team to say either we’ll consider it or we’re never going to consider this. I’m ok with both answers but it would clear the feeling of “maybe they’ll share the docs” situation.
My two cents on this is,
I think Elektron would benefit from flourishing 3rd party development but without knowing precise company state and internals it’s impossible to know for sure.
5 Likes
Likewise, here’s the pattern and project management software I use, which is quite dear to me but not exactly user-friendly:
Field Notes makes a nice graph-ruled book that works well for electronic music management.
So does my current favorite notebook maker, HOBONICHI.
They just came out with this great alternative rule that I’m enjoying:
8 Likes
Absolutely. Because there are valid cases where it would make sense as well as valid cases where it wouldn’t. As you note, only Elektron can know for sure, and I hope they respond to you with guidance.
But failing that, and lacking any greater understanding of the business, we have to keep an open mind regarding both the “makes sense” and the “does not make sense” scenarios. And, if possible, not read malevolent intent into either.
4 Likes
this is the way
1 Like
Wait… you guys are playing the same song again???
I erase and write/program and hour or two of new songs for each performance.
Why the hell would I repeat myself, people already heard last months ideas… let’s move on.
Besides I’ve probably swapped out or sold the drum machines and synths I had plugged into my OT.
Writing from scratch is total freedom!
Don’t be lazy! 
What do they have to gain by making such a defining statement? It only makes the future less flexible for them. I think that it is reasonable to expect that until the day when they announce open developer tools, that we can expect them to continue exactly as they have always done, keeping things closed and proprietary. As a huge open source fan, this is not ideal for me, I would adore an open SDK. But I think it has been very clear what Elektron’s stance is on who can develop firmware for their products.
If you’re hinting at Apple: their public APIs are the excellent and well-documented SDKs for MacOS, iOS, iPad OS.
These are hard to answer for mostly even the company founders or CEOs.
As a person who had relatively enough experience working in and interacting with software companies of different sizes and with different departments of them, “What do we gain?” or “What do we loose?” are usually questions which give birth to discourse internally also. Long discussions happen which does not make everybody happy in the end.
I can empirically say that the decision makers are not usually right with the answers either.
Because these are very complex matters and it involves taking calculated risks and relies on a cocktail of assumption and previous experience if it exists.
No company has 100% control over their success and usually great deal of that is not planned but happen as happy accidents. (Not talking about gigantic enterprises or conglomerates which have scaled into a huge operation to increase precision on these calculations.)
Basing my thoughts on this, I think the benefit is somewhat indirect.
If you take actions which enables more creative individuals with passion to use your products alternatively and make it easier for them to make creative tools for themselves and the community the ecosystem around your product will grow in time with your “little” investment.
When the ecosystem grows, it will become a direct selling point for your product. You’ll get that relatively for free because passionate people will grow the ecosystem by their own will.
SDKs, low level libraries, or MaxMSP interfaces might not seem very appealing and also niche for the major part of the community but eventually people will make tools using these building blocks which would appeal to a wider audience. Then people will talk about it and probably a few of those tools will become indispensible and set new standards about how we approach these machines.
I believe this would benefit Elektron greatly and make it more special.
3 Likes
Just about the “defining statement”. Yeah not something solid which I can think of now. Some part of the community would gain a lot though. I have the belief that it would benefit them indirectly.
1 Like
Plus you can hire these people based their already proven track record with your product, and integrate their invention into your product portfolio.
3 Likes
Oh I completely agree about the potential benefit of opening up their code. I actually work on open source music instruments, so I am wholeheartedly in favor of that. I just don’t see any benefit to them making a statement beforehand. Like “We like open source (or community development, or w/e), but we can’t do it yet” just seems like it just creates expectations that they might fail to be able to meet. Where coming out of the blue with community tools would be a massive PR win for them, and it gives them the flexibility to not do that without any community backlash.
3 Likes
For what it’s worth, I recently had to merge about 100 patterns from multiple projects into one project for a live set on the DT. I was using a similar sample pool among the lion’s share of the projects. That’s key, because otherwise I’d be stuck noting the sample assignments manually. The biggest obstacle in this case is having to wait for the sample pools of every project to load (45 seconds or a 1 min x 100 patterns x 2 projects (source/destination)…
This is the best method I could manage:
- Save a second version of each project you’re pulling patterns from
- Proceed to delete the entire sample pool of every ‘backed-up’ project you’re pulling from
- Create a new project with an empty sample pool
- Copy and paste the patterns you want in the live set project manually, loading between projects
- Reload the sample pool in the same order present in the source projects
Yes, you have to load between two projects constantly. At least in this method, you don’t have to wait for the sample pool to load each time, at least it took 2 hours instead of 6 or 8
5 Likes
This right here shows how severly lacking a project management tool is.
Its surreal levels for a device&company of this popularity level.
I hope that @mzero will throw out another update for elk-herd…
4 Likes
It’s kind of why I’m partially coming back from DAWless. Those boxes are sitting between grooveboxes of yore (think analog ones, no preset), and full fledged computers. They’re incredibly more powerful than the first ones, incredibly less than the latter. And usually the pain point is sample management, where you end up doing a lot of weird backups you’re not even sure you’ll be able to restore if something goes awry.
I ended up keeping only the A4 MKII and the Syntakt (also had a Rytm MKII and a Digitakt), whose projects are fully and more easily backup-able, as they don’t handle samples at all. I’ve got a better peace of mind knowing that if my Syntakt burns I can buy another one and restore everything.
Of course some people don’t care about backups or sample management. And to these people, those boxes with samples are fine.
Did you ever get a reply?
I arrive late, but after 120 there is 122 because 121 is on the other side of the road
Honey u lost?
The request address just takes them for whatever product owners/mamagers but does not actively reply to submitters,
Those don’t appear to have mentioned in this thread yet:
3rd party Project / pattern managers
For A4
For DT
For DN
6 Likes