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
- export patterns or tracks as MIDI files (with the proper CC instead of parameter locks)
done, check, already implemented. The solution i might have to refine again exports all data as MIDI or *.als aka Ableton Set.
- clean up and rearrange projects, banks, patterns, sample lists, parts
- copy patterns, sounds, settings etc between projects
- mix and match tracks from different patterns
done. check you can even open multiple projects, which means the data can be moved around. All it needs is (as i wish for myself) a javascript API or python API that lets me generalise this process so that i dont have to develop all possible combinations of weirdo mangle processes but rather define a set of functions that can be called to do the job. If those are triggered from the app itself to implement copy / paste / sort / cleanup / validate doesnt matter anymore because i would have one single interface that you go thru to do just that. So yes, good point. Actually that is very much what an API is.
So the basic idea is, if we don’t have Overbridge for the OT means we build the missing bridge on our own and make use of audio interfaces and midi interfaces we usually use for that already. It needs a central place where that is kept together to actually walk over the bridge. Doesnt hurt if there might be actually overbridge support for the OT in future. More the contrary in my eyes, we could define the API we wish for.
Maybe i give also some clue what that is so complex. The visualisation is based on so much paramaters all the time that in example changing one parameter has to show up valid when you press Scene A to see what tracks and pages make use of the scene. Shift all Trigs 5 steps to the Left. Oh! Slide Trigs have to move as well, oops, all data belonging to those Trigs will come back at the end of the loop, rrrgh round robin code. Uff! All in 8byte data chunks, ok let’s do bit operations. Gosh its not big endian, ok lets flip the bytes back to endian memory. Erase a Trig by fast hitting the button, when i release the button will it empty the trig or did i just hold the trig to edit its properties? Ouutsch, the actual editing needs to be done when i release they key (button) not when i hold it. So i keep the operation in memory and apply when you do the action “lifting your finger”. Yikes there is a CUE button to the right of FUNC, where do i place that button? Hmm… maybe just same layout to the right of SHIFT (which is FUNC in the app). But this key is not supposed to work as Modifier Key for other Keys… how do i do that… ok - lets invent modifier key code for normal key letters. And on and on… it’s insane, if i’d know before in what hell of a UI work i dig into I might have never started… haha.
By slowly doing the check step by step i make sure that my interpretation of the OT format is really really correct, because - well - i had to discover what is what myself of course and some properties are surprising simple and then it turns out they are not simple because they interfere with another property like, lets say just accationally switch to another track - boom. Do i re-evaluate again (CPU intense) or do i just call pre-validation to show up risking invalid visualisation. It is like writing the most complex liveset of my life… lol. Then implement code that speeds things up and reduce function calls and so on… Ok lets shift the pattern to the right two steps… ok what data does have to change as well? Am i sure i did all of them and not miss one single out ? Did i parse the scene again correct? See that is what is time consuming and kinda crazy to even do that as a single developer…
4 Likes
All that looks and sounds excellent. Take your time, but please let me know when this is ready!
As I understand it your app removes any need for planning Octatrack projects because everything can be changed so easily. Which is a gamechanger for people who can only spend very little time on making music.
If I understand this correctly, one could even use your app to record patterns via midi into another sequencer in real time?
I like that, this would allow people who no longer own an OT but still have backups get access to their music again.
Now what would be really cool is a way to connect your App to rytm-rs and some software for the Digis (probably a future iteration of Elkherd, or something new entirely) to transfer patterns between devices. I guess that even approximations of sounds might be possible, especially between OT, DT and AR, or between AR and ST.