Sorry but there is just as much “elektron-flow” in MIDI data. It is an electrical signal. OK it has a carrier wave for the data but it is all electrical, volts pushing amps (well mili-amps).
This. No point beating the dead horse over it.
1 Like
3 Likes
That’s a very interesting playground for quickly prototyping some ideas. Especially the cross compilation into a ready-to-go JUCE C++ project makes it quite useful.
1 Like
wow, thanks for the recommendation. Tho that specific course was not available atm I just signed up for another MAX course that starts in five days!
I know it’s not strictly “coding”, but wanted to share the quick mockup I just put together for my sequencer. Some of these features are already done, others not, but I needed something visual to work from so I could figure out how it all needs to fit together.
6 Likes
Love the design! What platform is it for?
2 Likes
Thanks! At the moment I can build standalone binaries for pretty much any platform including arm devices. The end goal however is to build a hardware unit, and beyond that I’d love to integrate it with Elk OS as a standalone groovebox.
Nice! Weird question but are you left handed? Haha, I just felt like I really wanted Shift and Undo at the left-hand side of the screen, probably because I’m right handed. Anyway, uh, sounds like an interesting project! ElkOS seems pretty capable.
Haven’t given Go a… go, but interesting choice. I think it’s quite refreshing how a lot of people are trying out different languages for music software rather than the super-classic (rustic, even? hehe) C++ approach. As you wrote before, I think Rust would definitely be a great route if you need to go lower.
On another more general note, I’m currently looking into Swift and SwiftUI. It’s incredibly well made but obviously only targets the Apple ecosystem - however, I would definitely recommend it to anyone who wants to dabble in writing programs and is running macOS. Lots of great documentation and the way you can preview and interact with the code is really smart.
3 Likes
Cheers mate! I’m right-handed, and now you mention it… Yeah, they need to be moved to the left. It’s kind of weird because I’m so used to thinking in software terms; I’ve not worked on any hardware before, and I kind of need to get used to the idea of having two ‘cursors’ (hands).
And yeah, it seems like recently a few new languages have been bubbling up; not least SOUL which is at its v1 release now. Everything I’ve ever read about C++ just makes it sound awful to work with, relative to the javascript ecosystem I’m used to. Go feels like it’s employing a lot of the nice parts of that, such as via its package management etc.
I will take a look at Swift - I’ve seen it talked about a lot but never actually read much about it. Previewing sounds very smart.
As a Javascript dev who’s been doing a reasonable amount of C++ audio stuff over the last few years… it does take a lot of getting your head around. But if you use JUCE, it really helps you follow good practices and makes it a lot easier.
And honestly, I’ve enjoyed learning the ins and outs of memory management and real time programming and stuff, and that knowledge of the lower level stuff does come in useful even when working at a higher level.
I’m not sure of the state of doing audio stuff in Rust/Go, I think there have been a few talks at ADC (Audio Developer Conference) on this topic, you should be able to find them on Youtube… Personally I’d think long and hard before using something other than C++/JUCE, just because of the sheer amount of experience and battle testing and knowledge and so on that is out there. However, if it’s just for a fun project and you don’t mind getting your hands dirty, why not give it a go!
2 Likes
Yeah I am actually really interested in learning about the lower level stuff, and I find it fascinating. I’m almost positive I’ll take the plunge at some point. I like to try and wrap my head around the fundamentals first where I can, so I’m hesitant to go straight into JUCE without some decent lower level programming knowledge first. I figure this will mean everything takes longer, but will likely pay off in the end.
Elk OS seems like a great choice for hardware development. I went with Buildroot+Juce on the Raspberry Pi for my own project, but it’s a real pain to setup, especially for deployment and testing (unless you develop directly on the pi, which is not an option for me).
Also, I agree with you on C++, it can be awful indeed, I think the main difficulty is the wide amount of features the language provides and the vast amount of ways to do the same thing and the amount of way things can go wrong. But within a framework like Juce, the functionnality you’ll use are a bit more limited, so it’s less daunting to learn & use.
2 Likes
Depends on how patient you are, how much time you can dedicate to this, etc., but I would say JUCE is decently low level already. You still have to think about things like memory management, real-time-safe programming, etc, it just abstracts away a lot of the boring, fiddly stuff (working with different plugin formats, for example).
You still write pure audio algorithms in C++ in your processBlock function etc, you just don’t have to worry about messing with the VST SDK or whatever… so for me, it feels like it helps you get to the interesting, reusable stuff, without as much of the frustrating stuff that (for me) would probably make me give up on a spare time project before getting anywhere fun.
Though if you are looking to jump straight to writing for hardware and don’t care about running on a computer, maybe you could start with e.g. a Teensy, which can do a lot of stuff out of the box (MIDI over USB, audio with the right expansion board), which you program in C. Because it’s pretty “bare metal”, there’s a lot less ceremony to the code, you basically just have a loop function that is called thousands of times a second where you “do stuff” – it’s actually really fun to go back to programming that way I find!
2 Likes
Cheers all for the advice and tips! I’m jumping into this thing solo and don’t really know anyone else who does this stuff, so it’s super useful to get your takes on it!
I’m impressed - buildroot looks like a minefield to set up; I’ve read a bit about it before. I also tried developing directly on the Pi but it felt like more effort than it was worth, and I didn’t want to pollute my testing environment with dependencies and development tools.
It seems that JUCE is definitely something I will have to try at some point!
I’m not in a rush. I’m interested in learning about this stuff, and with my design and web dev experience, it seems like if I get good enough at it one day, this might even make an exciting career move. I’m working on this stuff most evenings at the moment, and just trying to learn by doing.
The bare metal route is defintiely one that I’ve been mulling over for a while - C sounds a lot more manageable than C++, and I’d love to have some experience messing around with microcontrollers. It may even be that there’s room in this project to do a bit of that too, for hardware control interfaces etc.
I guess one good thing about this ElkOS idea is that it is a VST host, so I could actually start building stuff in JUCE and be able to run it as part of this program.
Ha yea, I’ve kind of half done this, started working with a music tech company on back end API stuff and have moved into music app development over time (using React Native for the UI in addition to C++, so still got one foot in the JS world). C++ for UIs is not much fun when you come from the web world, feels like going back in time 
I really think starting with JUCE is a good idea, then you can work “down the stack” from there as you move to hardware. There’s just so much complex and frustrating stuff with C++/audio dev, that removing some of the pain points will help you learn faster, I think. It’ll teach you good habits/code style too, which a lot of C++ code out there won’t do
Oh nice! It seems that more and more options are becoming available for using web tech to handle native front ends. From what I’ve seen of the existing GUI landscape in a lot of lower level languages, I think that has to be a good thing. Of course that level of abstraction can have performance impacts, but shit, CPUs are only getting faster! I’m using https://wails.app for the front end of my Go app right now, so it’s a full Vue front end with an event handler API that can send data between them, and without the weight of a full chromium instance like you’d have with electron. I’ve heard great things about react native too.
Must admit, you’re definitely selling me on JUCE. I was so looking forward to all the nerd points that I’d get for using Rust. Oh well lol.
1 Like
Same here, and all the places I went to were either for complete beginner or for seasoned professionnals, so it’s nice to be able to discuss this stuff.
I had a hard time finding a good tutorial on the subject, but luckily I found one in french that had (in my opinion) the most comprehensive and cleanest way to explain how it works and how to set it up.
Here’s the link in case you understand french: Créer un système Linux embarqué avec Buildroot
I looked at yocto too, which seems easier to maintain in the long run, but is much much heavier and complicated to setup. It’s all based on configuration files, so when it’s set, it’s a breeze to modify and work on, but you first have to understand the whole logic of it all.
The pros of buildroot is that it’s pretty much self-contained and very small in size, but maintainability is a pain because you basically have to fork the project to use it. There are ways to not have to fork it, but that’s not the intended way to use buildroot apparently.
I think the intended way to develop for buildroot is to compile the toolchain for your system and then send the binaries over the network, but I had a hard time setting up the compiler, so I never got to do it this way.
Also, my 2 cents on Juce is that it’s not a necessary stop for audio development, even for hardware. The Monome team are doing a mix of things and are using Supercollider as an underlying engine. (they probably have C++ for system stuff though)
By that, I mean that if it’s too daunting, it shouldn’t curb your enthusiasm for audio development in general.
Well it depends what your aim is I guess at the end of the day – if you’re just as interested in playing with a new language as actually getting your idea made, it might be more fun to do that… but if the tooling is much less mature there’s a much higher risk of hitting roadblocks. If you like perservering through that kind of thing, it can be a great learning experience… I know for myself that I don’t find that much time to work on my ideas and so anything like that might get in the way has to be minimised!
You could check out this talk from a couple of years ago at ADC as a starting point: Ian Hobson - An introduction to Rust for audio developers - YouTube
1 Like
Nice one! I can’t read french at all, but I might remember this if I ever need to run it through Google Translate 
Thanks - to be honest I’m not usually that easily deterred once I set my mind to something. Just need to make sure I don’t get bored before I finish, and if it’s super challenging then it sometimes can motivate me even more. For the moment I’m sticking with Go to get this sequencer up and running, but I will definitely hit a point where I need more low level stuff, maybe with a slight detour into maths for a bit.
@tdmusic Cheers for the link! Yeah I mean the main driver is to make the thing, but since it’s all new to me anyway, I figure the main benefit I’ll get form it is learning a ton of new stuff that I can then apply to other things. I guess I’ll see how I feel at the time, and a bit of tinkering first will probably help me figure out which route seems best.
1 Like