My ER-301 has sat gathering dust since I bought it because there is no SDK or user programming method. Where is the SDK or its timeline for the few of us that purchased it to specifically to program it? Thankfully there is a large waitlist, so I can make space and help those in need but I would rather get to finally use this really nice module the way I had hope to! FYI the new Percussia kick starter is promising a C++ SDK too!
Respectfully I totally disagree about the user programming method - the OS as it stands is an excellent user programming environment, albeit not code, the possibilities are already vast!
My advice, if you’re interested, is to think ‘patch programming’ and get stuck in, it’s ace!!
Respectfully, it is not programming it is actually called patching! I am talking specifically about the C++ SDK that Brain had promised and has gone black on now for months…
No I get it, I know what programming is, and that’s why i put patch programming in quotes, but it’s already been stated that it’s going to be some time coming, going black isn’t exactly generous or accurate. I can see that you’re disappointed, but not sure this approach will help matters any.
Many of the mathematical relations you probably wish to create using programming are already available, just because it’s not code doesn’t mean they are not equivalent.
Shrugs… up to you, but you’re missing out on a great deal of fun and letting your expensive machine gather dust
An exact release date wasn’t given. Right in the purchase it even states “The software is still under heavy development” so I knew going in things would take what they take to get sorted out.
I’m sure there’s tons of variables until the hood to consider, and this can’t be released in the wild if there’s still potential internal changes that would throw off 3rd development or the way unit guts are constructed. That would cause a larger frustration imho.
Knowing O|D, he’ll release it when it’s right
Here’s a couple of posts that might get you going, they’re much lower level than the typical patch, and replicate functionality that you would normally associate with higher level programmed functions in a modular system:
I’m sure there’s more, and certainly more to come
It would be great to see what you can come up with given your skill set!
Whatcha gonna build, if you don’t mind me asking?
I don’t believe O|D ever promised an SDK before the software had reached a 1.0 release. The software itself is still in very active development with improvements and features being added on a very regular basis.
I might wonder why you would let such a powerful piece of gear just sit and collect dust for the simple fact that there is not yet an SDK. It seems like the time would be better spent learning the ins and outs of how to use the ER-301 while taking note of its features and limitations so that when the SDK is released you’d have a better understanding of the ecosystem that you would be developing for.
It seems to me your grievances have more to do with the fact that you pulled the trigger and bought a product that you didn’t really understand than the Brian not delivering an SDK to you in a timely fashion.
If you get sick of waiting, I’m sure you would have no trouble getting what you paid for your ER-301 on the used market.
This makes me sad, Mr Becker! Why would you say such a thing?
Is this a call for me to compete more aggressively with other eurorack manufacturers? I’m sorry but I prefer not to operate that way.
Actually, to be honest I didn’t really understand this sentence. What is this waitlist? Who is in need? At least you said the ER-301 was a nice module! I’m happy but confused.
Here is something I can bite on. My goal is to have the first version of the plugin SDK out by the end of this year. The two major obstacles are:
- Weekly volatility of the ER-301 firmware.
- The ER-301 is bare-metal (i.e. no Linux) which means that I have to write my own dynamic linker. It will be fun and educational but by no means trivial.
One more thing. As I agonized last night over how to respond to your post, I brainstormed about the possibility of releasing a monolithic OS-only unsupported code base that would let the intrepid users write their own firmware. No application layer, just the RTOS+drivers. I could probably put something like that out in just a few weeks. Would that encourage you to dust off your ER-301?
Don’t you just love being a di**bag tbecker. Find yourself another hobby.
Let’s keep this civil
The essential content of @tbecker’s post which I believe was “When is the plugin SDK coming?” is a valid question after all.
While I too am incredibly stoked about the Percussa SSP it is incredibly bad form to bring that up here as a ruse to prod a release date out.
As has been mentioned the 301 is bare metal. It means there is no OS layer providing driver support and pre-established sdk’s with which to build a subset sdk.
The SSP is aspiring to be something that while not entirely different from the 301 is in a league of its own. Two very different approaches.
I see the 301 and SSP working beautifully together and I say that with no desire to see a sdk (but will be happy with one for sure) for the 301.
Brian, great work, and I’m really looking forward to getting mine.
Just to weigh in, which I should be careful to do as I have little insight into programming and what exact goals may be achieved in parallell to others, but seeing as that you are as limited a resource to the ER-301 as George R. R. Martin is to Game of Thrones, I don’t personally see this as something worth pursuing, nor is it something (again, based on my limited to non-existent knowledge of programming) which would encourage a lot of user programming around the ER-301. Why prioritise low level programming? And to be quite honest - whatever weird “consumer power” I might summon here - it’s not what I expected from going into this kind of product
I would also be curious to what exactly the OP is looking to achieve by programming, if not what some other projects have been? What are some of the end goals?
I don’t find any of the stuff going on at this point trivial, there’s nearly 40 videos around worth learning from with some pretty complex musical possibilities already. I think the progress of the firmware is very promising, transparent and correctly prioritised.
This is the first time I’m seeing anyone suggesting the opposite so to keep the discussion on track I’d be keen to know what @tbecker is trying to achieve.
Thanks, this is a nice compilation of using the existing units to achieve something new. I would consider these examples still patching though as opposed to programming. The real issue, is what if an existing unit doesn’t exist for the user to work with? Then having an SDK would let someone work on something specific for example a variable length probablistic envelope generator.
I see myself as a potential user of the plugin SDK. I have a coding background and I think I might be able to add something interesting to the ER-301 ecosystem when the SDK arrives. I don’t have anything specific in mind yet - it’s just a general thought that sounds fun and educational for me.
This seems like it would benefit a incredibly small slice of ER-301 owners. Just speaking for myself, if you released something like this, I wouldn’t do anything with it - way too much work for me.
The plugin SDK to me is far more interesting since it would allow us to tap into the years of brilliant hard work you’ve already put into the 301, and add something small (or large) that can work alongside the rich collection of units and routing possibilities you’ve already built and continue to grow. Something developed with the plugin SDK could also be shared freely or sold, which in turn could be a benefit to 301 owners who can’t/don’t want to do any code level development.
For my two cents, the plugin SDK is where it’s at, and no rush. The vast majority of 301 owners are going to benefit most from the official Orthogonal Devices firmware development. The ER-301 OS is already a high level graphical programming language that’s quite powerful. A plugin SDK will be icing on the cake.
Thanks for the answers Brian. Having a SDK on top of your application layer for the ER-301 is important and as I mentioned it was an idea that was good enough on your part to be included in the Percussia kick starter feature list. This shows that people are interested in a platform that has a way to program a unit or plugin. That Percussia project is still set for a May 2018 release and it is always good to know what other manufacturers are up to and why. It sounds reasonable to target year end for the SDK. I was wondering if the existing units were being dynamically loaded at runtime and it sounds like the current OS is not doing this yet? A RTOS+drivers release might be nice to play with a few details on the cross compilier toolchain you have set up. But I would prefer to work with a plugin framework so I could integrate the existing units with some new ones. I am looking at getting a Mod Duo because of its linux base and LV2 plugin framework, but with only one input and two outputs, it is not suited to eurorack. The ER-301 on the other hand has the perfect amount of I/O for a designer to work with!
With so many man-hours been put in by you and the contributing testers on the forum to refine your 301 OS… opening up the entire thing to make this module everything for everybody from ground zero would take away from what makes the module so special as it is.
I’d leave it at the unit SDK. 3rd Party Units have insane potential.
If some users want something even more specific - then maybe eurorack isn’t the way to go… use MAX, Reaktor, Audulus and a few ES-8’s on a laptop?
This kind of post saddens/angers me because Brian has taken extra care to explain that the ER-301 is in active development and that you shouldn’t purchase it for non-implemented features. I’m grateful that this thing even exists and astounded that O|D is a one man operation. If you’re not using your ER-301, there are definitely people who would.
Percussa SSP looks cool, but who knows if it’ll be postponed, which happens with many projects.
I totally get that we are emotionally led creatures a lot of the time and I am definitely very capable in this department, but we have proved beyond doubt that civility and respect are very achievable in an online forum like this. So no judgement, at all, but yeah… lets keep it sweet!
My suggestion, and my practice, when feeling a little hot under the collar, is to re-read this;
This is a great example of why I think you should get to know the current programming method of the ER-301, if you did I am certain you would be thinking of this as two separate units:
A variable length envelope generator unit…
…a probability unit!
The beauty of the way the units are implemented is that they strongly represent the very mathematical functions you would use when coding anyway.
If I can encourage you to do anything at al with your ER-301 it is to understand the programming paradigm that is being implemented.
This will help you in two ways, one it will get you going on your ER-301 and when you do come to put those skills to use in the SDK, you will be programming things in a way that is both familiar and easily adopted by everyone else.
By all means, there will be nothing stopping anyone from developing higher level units that are combinations of lots of functions and I hope to see this as well, but I would be much more inclined to use the ones that fit the paradigm well, than those that don’t.
edit: an afterthought, check out some of the threads on MuffWiggler where clever folks have built Eurorack modules without really understanding the ecosystem first, a very high profile case is the Strymon delay module. Great idea, pretty much a total fail as a first entry into Eurorack - as far as I am aware, they scrapped the design and went back to the drawing board.