the letters in the track tabs are just indicators, the buttons are located below the volume slider:
and the S and M keys also work, as @amaury mentioned. workflow tip: pressing the S and M keys while hovering another tab with the mouse will apply the mute/solo actions to that track instead 
Really fun! Thanks for sharing.
Awesome thanks for pointing that out. You have done an amazing job with this! My only suggestion would be more button like elements rather than text.
thanks!! i’ve got a positive problem now: how to work around the data transfer limitations of the free hosting services that i’m using 
the default sample library is only 10 MB but that really adds up with all the traffic tahti is currently getting. solved it for the most part already though!
Excellent browser-based groovebox! 
Please Elektron, hire this guy and let him work on the Octatrack 2!
digitakt pro
Wow. Insanely cool 
This is great. Many thanks for making this. The only thing that puzzled me for quite a while was how to set the note value for each step. Then I realised that it’s a value called ‘course’, which wasn’t obvious to me, but maybe that’s just me!
made a quick “getting started” video:
fine with me, as long as it has a crossfader, 3 LFOs per track, a dedicated mixer page and send/return FX 
Hey, @maxjvh, any possibility of explaining some of the tech that went into this. I’m on an odyssey to brush up my JS/Node/Python/HTML skills at the moment and the idea that you could produce this in a browser blows my mind!
Same here. I think the SOUL website (https://soul.dev/) would get you far enough with your knowledge. I’m planning to make myself a ‘hello world’ 
Haha, I know that feeling. I do feel I’ve come on leaps and bounds recently as a few key concepts that baffled me for a long time fell into place. Problem with me is I don’t learn very well from tutorials, I need a project. Luckily for me I had a real world problem to solve and made a broadband speed test thing for my dad as he’s always having real trouble with quality of service (wireless broadband). Originally it was a simple cron job that generated a static image of the last 24 hours of download speeds test results (stored as CSV). Since then I’ve leared a lot more about client/server communication and brushed up my JS (I was more experience with Python) and turned the little project into a larger one by implementing it on a Flask server (all runs off one of my old Raspberry Pis). Migrated the data handling to JSON and fancied it up a bit with ChartJS and Bootstrap. Next step is to migrate the data again but this time to a proper database (Monogo/Mongoose). It’s stretching me a bit now as I find it hard to grasp exectly what’s going on with async stuff. Getting there though. There’s a good channel on YT I follow called WDS (Web Development Simplified I think it’s called) - really clear explanations of concepts and techniques.
Oops, sorry for thread derailment!
By the way @maxjvh, regarding making this into a plug-in or mobile app… I’ve done some experimentation into creating JUCE plugins with web technology-based UIs (I’m from a web development background but have dabbled in some audio stuff, and find building UIs in C++ so painful compared to web, so I had to do something about it!).
I’ve created a JUCE module which allows you to pass structured messages between C++ and JS running in a WebView, and it can automatically synchronise plugin parameters between the two if you are using ValueTrees (right now this hooks into MobX on the UI, but it should be possible to adapt it to Redux I imagine, I just haven’t used Redux for years!). I’ve also created a simple synth to demonstrate it.
It’s pretty rough, but I think the basics work and it wouldn’t be too hard to make it more “production ready”. I guess what I am imagining is you could use the SOUL JUCE project generator to create a JUCE app running your DSP, then use my module to integrate your existing UI (running in a WebView), so most of the work would be hooking up the communication between the two (in theory, lol).
Give me a shout if you’d be interested to chat more about this some time!
getting very technical now
@neilbaldwin there’s really nothing that i haven’t mentioned yet. did a quick line count and it seems to be 26% SOUL, 61% TypeScript, 12% SCSS and 1% C++. the thing that actually makes this possible are modern Web Audio APIs, especially the AudioWorkletProcessor which allows for audio code to run in a separate thread. IIRC, for example Safari added support for that this spring good timing!
as for a plugin version, getting the DSP to work is not hard at all because SOUL can be compiled directly to C++. i already have a test project with the exact same DSP running natively because i wanted to see how the performance compared (turns out it’s ~10x better than via WebAssembly in the browser). and yeah embedding a browser should also not be very difficult in itself. it’s just all the wiring and state management which will be a bit painful with the current architecture.
@tdmusic what i haven’t mentioned yet is that besides doing web stuff professionally i also work at plug-in company where we use JUCE i’d like to avoid it for tahti though because of its licensing model, especially since iPlug2 is already in a pre-release stage. thanks for offering to help though, appreciate it!
personally, i also dislike the idea of embedding browsers in plug-ins for performance reasons… but perhaps a first version of a tahti plug-in could be implemented that way. to keep this project interesting for myself though, i’d like to eventually try something like writing the UI completely in Rust (with egui, for example) and using that in an iPlug2 project 
Makes sense and fun to try something different if it’s a side project! You could also look in to Flutter, I know of people who’ve had great results building quite advanced UIs with it, then you can use the C FFI to call in to your native code.
Yeah, JUCE licensing is a bit of a headache if you just want to make something free/cheap. Is SOUL itself licensed such that you can do what you want with the output?
