This is definitely not the case for every developer. what I’ve read about open sourcing goes a bit further than just dumping the code on GitHub, at least for some afaik. If it’s complex code there needs to be instructions, walkthroughs, some help or even at least a little support to get the ball rolling.
But hey I’m not a developer so maybe I’m talking nonsense. But I’ve read about this from a few open source projects.
Absolutely, just dumping code on GitHub does not necessarily mean you have a viable open source project, that people will jump into and improve. A lot depends on how much the code already explains itself to other coders (besides the one who wrote it)
Of course. I’m not saying that just dumping the code is enough.
I’m saying that if you upload the code on github and create a post here on Elektronauts that there is a chance that people are willing to make this a viable open source project.
IAW the “no time” argument can be solved by involving others.
Now the code is not (officially) accessible to anyone, so there is definitively no chance on updates or any progress if mzero does not have the time / need for it.
This is not really how things work :). A developer has spend considerable amounts of time writing the code. It can be considered a piece of art in a way. We can safely assume that a developer doesn’t want to just throw their baby online without making sure it’s taken care of in the way the developer would want.
open sourcing something costs time. Involving others costs time.
Say you’re working on a piece of music and decide you want others to finish it. Would you just dump everything online and that is that? I know I wouldn’t 
Anyway, just my 2cents
I would not compare a music piece and a tool other people can use as a tool. I understand the concept though 
BTW quick reminder as this is an Elektron thread, not a Digitakt, let’s give some love to the OT too
A piece of art which now becomes slowly useless because it’s not compatible anymore. That’s also a waste of art and effort isn’t it?
I understand what you are saying and of course you don’t just anonymously dump it and see what happens.
What I’m saying is that there are many lovely people here on elektronauts that could help with this project. Writing docs, helping with tickets, maintain the code, etc.
Or use the code as a base and/or kickstart for something new, it’s open source.
Heck, a repository (without the source) already exists: https://github.com/mzero/elk-herd-project
There were already offers to help in the past:
Which does not mean that I’m saying mzero must open source this. I’m just saying that this project would benefit a lot for/from/by Elektron users without much effort of mzero per sé.
So IMO there seems to be a considerable demand for that kind of tool (supporting all !! Elektron boxes).
Why don’t already existing companies jump on that train?
I don’t expect that a SW dev can spend enough time to develope and maintain such a tool for free.
If it is fairly priced I would license it and buy even updates when Elektron releases new FW versions.
The feeling you get when you create is the same when making music as it is when writing software, it’s the making something out of nothing.
You can choose to release your music under creative commons BY-SA so others can pick it up and add their own to it, similarly with code you can fork the repo on github to get your own copy to make changes to and offer to contribute back to the source.
Because it’s a thankless scene to be in.
Say, as a company, it took 6 man-months to develop and contracting out on any other project we could make $100k a year. We’re now $50k in the hole. So we need to find 500 people who will pay $100 for our software just to break even.
But the synth market isn’t huge, a small portion of that owns elektrons, a small portion of that owns Digitakts, a small portion of that is gigging musicians that would pay for tools, and a small portion of that actually see this as a problem to be solved. So it might be hard to find enough customers.
But even if we do, people have paid us money now. They expect our software to be flawless and for us to spend all our time making it work in alignment with their (contradictory) feature requests. So the next 6 months are blown working on v2, we’re further in the hole, and no one is willing to pay original price for an update half a year later. So now we’re losing money. Probably badly.
That doesn’t account for the fact that we’re building on top of a platform we don’t control. What if a bug isn’t our fault? What if it’s in the DT? No hope of fixing it and customers will be furious. What if Elektron drops a new firmware? What if it’s harder to work around than the original? Can we afford to spend 8 months fixing it up? When we release and now ask everyone who already paid $100 to pay another $120 for the latest version that works, how will that fly? Look at the entitled tone of this thread. All our customers think this should be a free tool that was bundled with the DT to begin with. What kind of hate mail will we get from them on a daily basis?
But let’s say we make it all work. We weather the assholes, we convince people to pay us for our work, we’re on track to having a successful product. Then tomorrow Elektron releases this functionality as a part of Transfer, erasing it all.
No professional org is going to touch this with a ten foot pole. It’s a blooming miracle we had an indie working selflessly for free as long as we did and I dare say we failed to appreciate their efforts.
I don’t think you do as is evident by the following:
I’m going to stop repeating myself though ;). Let’s just say we disagree on this particular point and that I think we should be thankful for the time we were able to use this lovely tool.
PS. just to give you a hint of what I mean, check out this post bij mzero and specifically the Elk-herd 4.1 bit.
And reading back that comment I just hope he is doing okay.
I think the pattern and sample slot managing features would be very handy to have in transfer. I once sent a feature request email to elektron about this - of course mentioning elk-herd just as an example.
I think the best and most constructive way forward is for everyone to just do this same thing at this email address: feature-request@elektron.se, and hoping that electron receives enough emails about this same request.
Another thing to do is to ask for it whenever elektron releases a survey.
In the mean time, I know it’s painful, but the way to go is sysex for the patterns and either pen and paper or sound pool for tracks sounds.
I hope that too, that’s the most important thing of all 
.
Speaking which I never saw any feedback about the previous ones nor any winner for whatever they promised.
I’m sure someone won, but they’re under no obligation to report who, or to summarize the results of a survey (newspapers and public interest groups do, but corporations? rarely). I have the feeling they actually listen. But they may not act on what they hear. (I speak as someone who was subject to surveys for most of my career, which ultimately proved to be of marginal value, except at the very beginning.)
I think that’s the problem there. Elektrons are great for jamming and the bank/pattern management is great for working out tracks on the fly and having them saved with all of the sounds etc. It’s such an awesome thing to have that we tend to forget until we try something like a Roland groovebox.
However, if you’re jamming out an idea, you’re not in a zone of thought and planning up to the point where your patterns will be perfectly structured within one project so that you have all of them at hand for a live set or producing. I often jam on an older idea, come up with something entirely else and copy that to a new bank/pattern. You’re asking us to make a decision at that point: I will play this in a live set together with the patterns that live in project xy, so I will now stop developing the track and copy everything over to another project, and I know exactly which one. Total flow killer, especially if you’re working with samples and copying is even more complicated.
So yeah, I agree that it’s nice we can even think about complaining about something like that because Elektron is already giving us all of this bank and pattern magic that enables us to come up with ideas and develop them without interruption. But it would make developing these even better if there was some bank/pattern management tool. Especially since it makes so much sense within the workflow and structure that these machines teach us. They’re designed to write stuff creatively and then perform it live with the MIDI data and song mode in there, not with recorded audio. So it’s totally logical to help us to get all of that into one project. While I also see that Elektron are quite busy and should probably focus on other things first, there’s no point in telling people that find this feature useful they’re doing it all wrong.
Just sell it, it’s trash
Good points! So we get from Elektron what we’ve paid for that tool.
@prydal I am 100% with you. My liveset preparation was way easier with elkherd, elkherd was a blessing and it made it way easier to quickly compose a bunch of patterns and rearrange them quickly in a more intuitive interface than the regular copy-paste. I still use copy-paste of course but when you are doing like a big liveset it really helps to trim down the projects.
Keeping your tools well organised is the keystone of productivity, for any creative endeavour.
My current workaround is to save sounds I really like from other projects, if necessary but very rarely, and to create livesets from scratch (less productive, slower) with only 1 project.
Agreed. IMHO the most valuable part of the project is not the GUI, but reverse-engineering the file format, which must have taken a ton of time. Even if the code were total crap - which I’m sure it isn’t - being able to document the structure of the file format from the codebase would be a huge time saver. Implementing a new GUI and logic is not so much work for an experienced developer.
And I’m sure that @mzero would have found the time to polish the code and open source the project ages ago, had Elektron saved him that time by publishing and maintaining sysex documentation, as is good (but not common) industry practice. Why they don’t do that is beyond me, it’s not too much work, and enabling the community to build an ecosystem around your products beyond what you could have imagined or built yourself is never a bad idea.
Also, I prefer my data being mine, so open formats that enable me decode and reuse to the music I created long after I sold my device should not be a luxury, but common sense.
Or an experienced and motivated developer who steps up and bites the bullet, this happens way more often than you might imagine. And the complexity here is, as I explained above, not too frightening with all the excellent work that has already been done by @mzero
FWIW, I do most of my sequencing for my Elektron boxes in a Cirklon these days, and I only use patterns to store sounds, which gives me 64 “songs” per project. From time to time I make a backup and delete the “patches” I no longer need. That has simplified my workflow tremendously, and personally I appreciate having a much more capable sequencer more than the tight integration. And it’s so simple using trying out another device for any sound, which helps a lot with experimenting with sounds. But I understand how this would not be an option for a small setup.
I can imagine 
but my point was that some developers would consider their code something quite personal and maybe don’t want to just throw it online without taking care of making clear how it is build so the next person can take it further in a respectful way.
It’s all conjecture but this is not too far fetched I’d say. When I still worked in IT and would hand over a project I had worked on quite hard I made sure instructions were clear and everything was as cleaned up as possible. To me that’s the right way to do this. Heck, even if I ask someone to remix a track of mine I make sure everything is clearly labeled etc.
Saying it doesnt cost any energy to share the code is slightly disrespectful imho. It’s not up to us to determine how a developer open sources something even though there are developers that do throw stuff online without care.
