Ok, thank you. Before I would want to get involved in a deeper look at any of that stuff (like the pd wrapper) I’m thinking of working on an operator idea/definitly getting a complex scene together for a performance next month.
Ok, I am perplexed.
I downloaded the .zip of the headers from the link you gave, which is labeled as exactly the one used in the example on the github readme (atmel-headers-184.108.40.2065.zip). However, when I unzip, there is not two seperate folders (avr and avr32), there is just one folder named avr-headers with a bunch of .h files. Here is a list of the folder contents if this helps: avr-headers-output.txt (2.6 KB)
Not sure where I’ve gone wrong here!
ok, those are just the 8-bit avr headers i guess. (sorry)
i’ve uploaded my avr32 toolchain folder here:
you can probably just use that as-is on any linux system, setting your $PATH to include
the headers in question are in
that was my bad, I should’ve checked the link before posting.
I’m happy I was able to create a simple operator called order (really should be called order2), it just flips the order of operations of another operator. I’m using it to flip the grid-classic operator’s z to execute before x, which allows z to control a gate’s opening and closing, so that it only passes a new x coordinate on z == 1 and not z == 0.
Also I’m combining another order operator to grid-classic y to control the output destination of a route8 operator, so if z == 1, x gets routed out the route[y] output! Alright!
that is pretty neat
There’s a Dockerfile for the toolchain documented in the README on GitHub. Lemme know if it fails because I wrote it.
Sorry I won’t be able to test that…I’m not familiar with Docker images, and looks like it’s intended for macOS. I’m on parabola/arch linux.
I just added changes that could be a first step towards loading samples, just want to bump the discussion here and we can hopefully find some common ideas on how we would like this to work from the artist/user perspective too.
what exactly do you mean by “loading samples”…just want to clarify before I add my opinion
this will enable loading samples from card within the bees ecosystem.
it should work as normal (please let me know otherwise), if you want to test the sample feature, go to the MODULES page and load the ‘mix’ module, then go to the new SAMPLES page and press ‘load’, atm this loads everything in the samples/ folder, this version of the mix module is really just a test to figure out how samples could be handled inside bees. these are the parameters;
level, sample playback level
start, start point
loop, loop point
and again, it’s just for trying stuff out still…
note, this version will only work with the modules included in the zip, however if you have a scene for one of these (waves, dsyn), these scenes should work as before, actually it would be interesting to find out if they don’t for some reason.
oh, and I could not find a proper download for the lines module code, I didn’t get it to compile, but when I do I can include that as well.
continuing with some more baby steps, added some more feature to the sampling test module, which is now called ‘sample’, new upload is here…
bees.hex and the sample module need to be file copied
they have to be the same format as prgm? (16 bit)
yeah, this version is using raw pcm like prgm, 32/48k or 16/96k.
I have always used a Delay operator for that, on x in your first example. I found that a time value of 1 is usually enough to modify the order of operations within a grid, for instance. But great idea!
you can also use combinations of MEM0D & SPLIT to reorder outputs without using DELAY 1:
GRIDRAW/X -> MEM0D_1/WRITE
GRIDRAW/Y -> MEM0D_2/WRITE
GRIDRAW/BUT -> Y4/IN
Y4/OUT1 -> MEM0D2/READ
Y4/OUT2 -> MEM0D1/READ
Y4/OUT3 -> …
MEM0D2/OUT -> …
MEM0D1/OUT -> …
With the announcement of the approaching norns, what is the current perspective on the future of the aleph?
I can clearly see how norns has come from the aleph. Does it still have any big advantages norns doesn’t address?
With the announcement today about the use of SuperCollider as the sound engine, this opens up huge doors for me personally, since I have a pretty good grasp on SC already. I don’t know Lua, but I don’t think I would have too much trouble learning. I’ve looked at the codebase for aleph, it’s complex to me.
its main advantages are still ultra-low latency and, potentially, stability.
with a hardcoded custom app (no SD card) it functions just like a purpose-built DSP hardware unit (think OP-1 or commercial delay/looping pedal.) it boots instantly and reliably does the same thing every time. (not that norns is unreliable, but it is a full-on linux machine, with the attendant power and complexity, and easy customization of a deep software stack means many possibilities for user error.)
BEES on the other hand is still, to me, a sort of proof-of-concept, that badly needs stripping down enough to fit a single scene in internal storage.
aleph’s main disadvantage is simply its scarcity and the high barrier to entry and time cost for creating custom firmware. those are not motivating factors… and i’m sorry to admit that i simply burned out on developing features for the aleph after spending a couple years alone building its firmware architecture. it does a handful of things that i really like, and i’m personally content with that, for now.
For what it’s worth I don’t have plans to let go of my aleph even with norns around - in fact the module additions made in the last year provide additional character to explore.
Care to elaborate on this? I don’t really understand this point.
in my opinion, the sd card is too exposed as a point of failure. the bees firmware and its data types are a little too large to fit even one scene on internal flash.