awesome Joe - i really needed these for the self generating patches i’ve been doing. The random gates, random cv and your bandpass filter were used in this glitch patch. Maybe not your kind of music but it shows the potential, especially with pinged filters. A decent bandpass filter was something i was missing. This patch just plays automatic, no external cv or samples used. Modulation is done by velvet noise triggering random cv.
posted here 3 Clicks - Random Generating Glitch Custom Unit
This is exactly what I am always looking for: a repository of utility units that are easily thrown into a patch. On top of that, they are super inspiring!! Love the motion sensor, that one is a godsend. Thanks, @Joe!
Not the kind of music I make, but I always enjoy watching your videos.
Really great stuff. @Joe I noticed a Github repository there but it seems to only contain Scorpio there. Do you have a repository that we can clone directly on the ER-301 card? That would be quite handy, also for contributions, forking the lua code and so forth.
That’s a great idea, @Bparticle. That was actually my original plan, and then I re-purposed that repo for Scorpio (which is not in this lib, because it was a collaboration with @kel). I’ll get this re-organized.
Here’s the repo on github.
I guess it makes more sense to link to this as I make updates rather than attaching the zip file. That way the download is always current.
Maybe a dedicated Github repository for community contributed units could be another little ER-301 collective effort, as the matter of fact? I know someone on the forum suggested a certain website that collects patches to keep track of them (as opposed to searching on the forum and hoping it’s still up to date with the firmware you’re using), but I didn’t follow that conversation. But a Github repository would be a more stable third party tool I think! What do you all think?
It’s probably a good discussion topic at this point, @Bparticle. @mudlogger has built a custom unit that includes these units. I’m flattered of course. But that custom unit now has a dependency that isn’t in the firmware. So I could see this getting pretty confusing down the road as others start to share unit libraries.
What if someone shares a custom unit that includes units from more than one bespoke lib? You can end up with multiple dependencies to hunt down. And then there’s making sure the dependencies are at the right rev level for the CU in addition to the rapidly moving firmware rev target.
I’m afraid I don’t have much experience with open source development to really make a suggestion based on best practices.
Oh yeah that does sound rather complex, but probably all the more reason to start sooner rather than later thinking about how to organize it. I don’t have experience with open source protocol either, but I do use git every day all day long. There must be some guidelines out there for beginners. I’ll try to find some information and if I can help organizing community units I’m up for it.
I will start here
Awesome, thanks! Maybe “open source” isn’t even really quite the right search term since the ER-301 is not open source, though it may give some good results. @odevices has shared some of the code to facilitate 3rd party plugin development. Maybe community driven development is more the terminology?
I think community driven development is exactly what open source is though, if it matters at all. The fact that the firmware is not open source does not have an influence on the the the users like to share their own efforts? Anyway, I’m pretty excited about this whatever we call it! Should we make a dedicated GitHub account?
I’m using npm a lot for front end development. Maybe this could be the answer for the dependency issue. I will look into it tonight.
monome norns is doing this through the dust repo.
in the scripts folder there, each user has their own sub-folder.
I’m very new to this, so take this advice with a grain of salt. Can the custom unit container collect all the deps within itself? There are drawbacks to this approach (duplication), but I’m thinking that if most units are going to take up very little storage space as it’s just code (and not say require specific samples and such) this probably isn’t that big of a deal. Not sure of the performance implications of how things are set up though.
The benefits are ease of use grabbing custom things. Throwing package management use on there might discourage people who aren’t as familiar with the command-line to grab stuff.
True the term “open source” may be purely semantic as it applies to an approach here. The community efforts may well be open source. As I understand it, there are 4 layers of development for the ER-301.
- Firmware (only @odevices is in this space)
- DSP/C++ layer (not yet revealed to us)
- Middle Layer/Lua
- UI/Visual programming language layer
If you call (1) the top layer and (4) the bottom layer for orientation purposes, then I think anything developed for the 301 has the potential to have a dependency on any layers above it, some of which will be optional installs. And can also be broken by a change to anything above it that it depends on.
This is a little bit speculation since I’m not quite sure how layer 3 is going to be exposed. It’s quite possible something developed at layer 3 by a third party could be closed source. At one point, I’m pretty sure there was discussion that someone would be able to sell ER-301 plugins.
So I guess that’s where a little thought around trying to centralize external dependencies and version control makes sense. If I want a plugin someone developed at level 4, it would be nice if it were easy to get optional dependencies needed from layers 2 & 3 regardless of who created them, and without having to scour the forum, get confused about versions, etc.
Would probably be worthwhlie to understand how it’s done for norns as a point of comparison, if that model is reasonably mature and working well.
I think it makes sense what @jlmitch5 is saying about the command line and package manager thing. It’s a small user base as it is so it makes no sense at all to exclude anyone who is not familiar with the command line. Although for development purposes it might serve a purpose. It could also be distributed or shared in a different way. Github is still a viable candidate I believe, because it has the download zip option right there. And at this point maybe handling dependencies manually is not such a bad idea, since like @Joe pointed out, we are still working with code very much in flux and breaking changes are still bound to occur in any of those layers.
norns is quite new so I’m sure there are kinks that will be worked out. that being said, it does share a similar code layout.
Layer 1 exists outside of this repo. It’s basically a custom linux image.
Layer 2 is supercollider, as opposed to C++. These are referred to as “engines”. These are currently living in the lib/sc subfolder. These are not versioned as it currently stands.
Layer 3 for norns is also lua. It is split up between helpful/generic utilities in lib/lua and the user folders in scripts I mentioned before (which are actual runnable applications, parallel to “units” on the er-301).
Norns doesn’t have a parallel to Layer 4.
This brings up a good point. There was a bit of discussion and varying opinions about using git versus, say, uploading downloadable zips within forums (that’s the way things work with the organelle in the c+g forum) with norns (thread about that here. There’s also some mention of the supercollider quarks package manager in there (no personal experience with that).
It’s not really an issue with people downloading content (because as you mention, you can just click the download button within the ui), becomes a bit more of an issue when consider uploading content has the git knowledge overhead.
I am having the same problem! I can’t get these to work as custom units either. How did you solve it? Damn I feel so dumb on this forum sometimes
There’s no need to feel dumb, i’m sure.
Make sure you’re on the current firmware 0.3.25.
Make sure you have a folder structure that looks like this on your card:
The .lua files should be inside the Joe-s-Bespoke-ER-301-Units folder. Don’t put the
<unit_name>.lua files directly in the libs folder - they need to be in this subfolder. Also, make sure you put all the files in the zip in the folder. The
init.lua file is required to inform the ER-301 about what units are in this folder.
You won’t be able to load these with the same procedure for loading a custom unit. They should appear on the insert unit menu, down at the bottom of the list in the Experimental category. Load them just like you’d load a builtin unit.
If that doesn’t help post back and we’ll get it figured out.