I’m taking this opportunity - as this thread gets upped - to say this:
If the lazy developers at Elektron actually cared, they could have added multiplayer to the A4 in two weeks.
Surely they have just lost focus.
5 Likes
Yeah, I’ve worked as a software developer for (checks calendar…) ~24 years now, and this has always been true wherever I’ve worked.
There’s always been a big disconnect between what some people think is easy, and what’s actually easy. I remember a client bracing themselves for a big project to update the background colour of a website (they figured there were thousands of pages, so it meant going through and changing each one), but wanted a new payment processing system added in an afternoon (“but their website says it’s simple to add in 5 minutes!”).
Usually the technical side of coding something (which often is simple to be fair) pales in comparison to all the other considerations around managing a product, e.g.:
- does it have sufficient test coverage?
- is the rationale for the feature well documented and agreed upon?
- has the system design for the feature been reviewed and approved?
- has the code been sufficiently documented and reviewed by other engineers?
- does it affect the performance of other systems?
- does it keep the built firmware within any binary size limit?
- does it bring in any additional dependencies which need to be reviewed for stability/security?
- does the feature use any code with complicated licensing?
- what’s the opportunity cost of implementing this feature vs. spending time on feature X instead?
- does it fit with with our future product roadmap? (we could add a sampler to the Digitone but…)
- what’s our marketing plan for the new feature?
- can/should we monetise it?
- do we have design/writer/reviewer capacity available for updating the product manuals and walkthrough videos?
- what if the feature is buggy, would that give us more negative PR than benefit from adding it?
- will this cause issues for projects created with an older version? We’ll need to test all of those.
- does this fit with out design and architectural guidelines?
- what’s our testing and rollout plan for the new firmware?
- should we release this now or bundle it with a larger feature release later?
- does the build/release/development/QA/marketing/etc. team have capacity for this in the next week/month?
- do we have developer capacity available after that if any bugs do show up?
- what’s our rollback plan if anything goes wrong?
etc. etc. (plus factor in time for a million meetings and middle managers to get involved, plus internal power struggles and politics for added fun)
15 Likes
Excellent response 
That is exactly what should not happen if done properly.
Don‘t built a house of cards.
Some of us, unfortunately, find ourselves entering houses of cards built by previous programmers.
8 Likes
Hey programming is easy.
Software development on the other hand is hard
3 Likes
developing exactly what is talked about here with the goal to open the box of pandora octatrack. So just throwing that in here I have thoughts to include a javascript/python api that allows anyone to mangle the data as they want and have such scripts as “macros” to call and share with others.
It makes more sense instead of talking about if it is possible to just do it and lead a proper discussion what users wish for to be able to do when they would get such API.
I basically tried to start such discussion more than a year ago and ended up in download somewhere for free request Hell which forced me to stop even publishing tiny stuff about anything whats going on with progress in favour of the actual project that needs to be done.
ps: publishing makes vulnerable to toxic comments which i earned a lot which i tried to see as proof that i am doing something right. Thats internet, but internet is also that any protagonist can go in submarine mode for good. Ended up with false accusations and “you just have to open source” bla bla… even got bricked in this forum, not warned but blocked (actually erased: unbelievable) without further notice why so. Pointing strongly to moderators here!
I didn’t really grasp what you’re trying to build. An API in what sense? A web API? To mangle what kind of data, Octatrack project data, other data?
1 Like
I would imagine (I have to imagine, since I haven’t seen the code) that providing such an API within the firmware while also preventing the user from
- bricking the device
- locking up the UI
- accidentally trashing projects, patterns, sounds, kits
would be quite challenging.
Even providing such an API via adding a wrapper over the existing midi/sysex interface, over just one piece of hardware, has proven to be hard work
have to go around the block for some minutes… comment on it in detail later. Cheers.
just short short: OT has no sysex api. But offline the data can be mangled as everyone wants, its basically open but very complex because of hundreds of different states possible
1 Like
Fair enough. That train of thought was triggered by this thread about the RYTM → Announcing an unofficial SDK for Analog Rytm MKII running firmware 1.70 written in Rust
Been there. Honestly at times I was unable to do it. If the Codebase is to big and too complex and documentation is basically non existent there is no way.
But to be fair. This also happens with old projects of my own, where I was not sticking to structure and documentation. Some things I did in the past I would not open again 
2 Likes
Why are there different states? I’m not saying it’s not a PITA to reverse engineer the file formats, but underneath some possible encoding and checksumming, I’d have imagined a rather simple data structure within a project’s files, because it mostly contains fixed length parameter data: configuration, tracks, patterns. Maybe the way storage of an arbitrary number of locked parameters per patters is different, and the sample references are probably file system paths of various lengths.
1 Like
What’s the worst that can happen…
6 Likes
I have no clue of pure functional programming but as far as I know it‘s less vulnerable to an interconnected mess. No states in the Code.
there seems to be a misunderstanding what sysex does and what an API actually is.
Sysex is meant to be transported via MIDI, an API is a set of definitions and properties to define interfaces to communicate with. The OT has no sysex, so there is also no API possible because it is missing the basic interface. So there can be also no SDK.
What i want to do is opening up my own APP that parses, mangles, visualises and sequences based on and with all OT data offline (offline from the OT), which includes later to be able to interact with MIDI of course. Thats the ground work that needs to be done to even support any API even if ever one would come up for the OT.
Such API based with this (UI accessible, working perfect, valid data) ground work means that its APP can also contain a browser module to surf the net and bind this (hypothetic) API to javascript / python / lua or directly exposing its class models to access them via scripting, either called from command line or in the App or in its browser on the OT data with what ever extra UI you like from external sources. So it comes down to middle-ware offering an API to be defined to do stuff nobody thought of yet. Would not call that an SDK, because SDKs is meant to be implemented in third party developments.
i will keep the learned lesson up and ignore toxic stuff questioning methods the one making toxic comments has no clue about why they are the way they are. If someone is looking for an Excel visualisation of Octatrack data, good luck. The Octatrack depth will evade any attempt to reach that goal and making over simplification comments in the grand internet do not improve anything. So ya all don’t take that personal, i am just straight saying how it is.
So the question is still up for answering and discussing.
What would someone having access to scripting access to OT data expect in detail?
I think you could reasonably say that there is implicitly an API there in your proposed app, even if you didn’t make that explicit in your code. It’s just semantics though, tom-a-toes, tom-ah-toes, we all know what we’re talking about.
It has a serial interface (DIN midi at least) so you could in theory define an API in the firmware, with transport over serial.
1 Like
What would be a typical set of use cases for the data-access ”SDK”?
Find specific samples/list samples used per project would probably be one
API off topic
I’d say sysex is closely related to the concept of an API, the sysex being the protocol such as http and API ”spec”, and MIDI being transport such as tcp. Seeing as you can invoke actions through sending specific sysex commands etc…
2 Likes
Someone please start the thread …
1 Like