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
i’d go so far to say, we could assume a virtual API exist following the API ‘available’ / more or less known for all other machines of Elektron. Only limitation - no Overbridge audio - doesn’t mean there will be no bridge of some sort that communicates dedicated to the OT in particular.
And because an API would be used to communicate over sysex likely anyway one can focus on the “I” in API, the interface. The thing that you face when using it.
What I’d be interested in is a way to do what Elkherd does for older versions of the Digitakt:
- clean up and rearrange projects, banks, patterns, sample lists, parts
- copy patterns, sounds, settings etc between projects
- mix and match tracks from different patterns
On top of that (nice to have but not essential)
- export patterns or tracks as MIDI files (with the proper CC instead of parameter locks)
Personally I wouldn’t need a full App, a simple SDK (libraries with a simple API) for accessing the data in the files would go a long way, I’d probably build a simple interpreter on top of that to achieve what I want.
2 Likes
even tho i know this thread might blow up by interest…
just for the sake to know what can be talked about… the following video shows the state i am in with the works… in the background you see an webinterface that communicates freshly extra developed full OSC2.0 specs (including bundle support) that listens and talks to the app which also hosts the interface and can be exposed via your router to who ever you want by simply giving the link (for those who know it, works much like subethaedit but based on musical standards [aka OSC protocol]). I did that interface including a extra developed vanilla.js framework because that simply lasts longer than react and co. So that is what i understand as the box of pandora that needs to be opened, so you could share with whom ever you want to work with or do with the data what ever you want mangling it, visualising, shifting, copying or just make it different as you please. That means i have an OSC protocol (set of link-syntax) that grows slowly to communicate. That includes that i had to develop OSC for ableton supporting python3 also with osc-bundle support in full.
I know waiting is the hardest part, even for me, but things are tricky in the details… specifically the visualisation needs to be valid at all time, not just the data. Because if the visualisation has a tiny flaw then you mess up the data for sure without even knowing… So you also see i completely re-interpreted the arranger so you dont have to learn a second time how that works… OT learning curve is hard enough for most, but hey deep as heck. So … here we go.
ps: saying that in advance (again) please no download requests or platform preference requests, it will start on OSX.
7 Likes