#4

I was thinking along these lines! Another big push would be great… Much like last year, wish I could somehow get a whole month off to work on bees & aleph this year. Just having proper headspace & full brainpower dedicated to it would really make things shift. Anyway dedicating a weekend or long weekend would be a great start.

#5

would love to participate if there is a hackaton happening.

1 Like
#6

almost everything aleph related is somewhere on my old HD so i’ll check and upload for you

but it would be nice to have docs archived for posterity in one location ( github? )

#7

here’s most of them …
only thing is that a bunch of them might break with latest version of bees/lines… as i think they were made in BEES 5.5…

if they don’t work tell me and I can give you tips on how to make them work… or even just to build them from scratch. none of them are very complicated in BEES, are there any that you’re specifically interested in?

Streppa.scn (256.1 KB)
GhostPulse.scn (256.1 KB)
Gripper.scn (256.1 KB)
Beatslip.scn (256.1 KB)
Stasis.scn (256.1 KB)

3 Likes
#8

Time to brainstorm some ideas for an aleph hacksession. How about a tonality diamond operator for BEES?

grid + aleph + FMSynth module could be a fun way to explore ratio-based scales & harmony.

I’d want to focus on BEES for the hackathon. In particular continue work on grid ops (grid op state -> scene memory, fix focus swapping. optimise whitewhale for BEES usage). Be cool to have the 11 or 15-limit tonality diamond sitting on left half of a 128 grid - then use the right half to organise ‘raw’ tone diamond into particular scales with another op. Or play the tonality diamond in it’s raw form (it’d be an x-y-addressed grid op). Wonder if possible to figure out focus grabbing/swapping localised to grid regions (rather than always grabbing the whole grid).

Maybe try to find a way to ‘load’ custom scales into whitewhale based on ratios/semitone. These enhancements to BEES would be crying out for some kind of groovebox DSP module…

3 Likes
#9

Would just like to reiterate my love for Gripper, an astoundingly complex/beautiful delay/pitch shifter. Anyone with an aleph MUST try it out!!

Which brings to mind:

@dspk
What does Gripper do EXACTLY? Been using often for quite a while with fantastic results and still can’t quite understand what’s going on.

2 Likes
#10

wow. honestly can’t remember… will boot it up and have a look
glad you like it!

#11

ok. so it doesn’t load up in my current version of Bees, but looking at the video and trawling my memory i ‘think’ there are two metros, one is choosing how often it records new input to del0 (ENC0 sets speed) and the other is choosing how fast the del0 buffer is retriggered from the start (ENC1 sets speed)… it’s likely i added a slight randomisation to the playback so the position varies slightly… … then the other two encoders seem to send del0 into del1 and del1 is pitched up an octave.

1 Like
#12

After speaking with @zebra last week it became clear to me that it is possible to create a custom application for Aleph without loading DSP modules from an SD card. This is demonstrated in the mix app. I got the toolchain from the dev branch on github to build on a new laptop, compiled the app code, loaded it up and it works! Yea.

During this time, I began to think about how I would begin porting some of the preset parameters in the Bees lines module to an embedded configuration. It’s an intimidating amount of things to do, though less than I expected. Here’s my list and an excerpt below describing what I see as a development pipeline.

  1. Build a dev toolchain on your laptop
  2. Open source code in your editor of choice, like vim or emacs
  3. Make changes to files using the C functions provided by the platform
  4. Compile your changes
  5. Run tests (TODO: make tests)
  6. Copy the new firmware to an SD card (install.sh script in root dir)
  7. Insert SD card into Aleph
  8. Hold down the mode switch (big button at top right) and power on the device
  9. Choose your firmware to load
  10. Wait for the firmware to load
  11. Power off device and remove SD card
  12. Power on device

Is this the basic gist? I’m very rusty on large C applications and mostly do systems programming so vim + ctags seem like the way to go? Would anyone like to share their dev environment?

Thanks!

2 Likes
#13

Glad you’re digging into this. Don’t have a lotta bandwidth right now but you might want to check out the work @rick_monster did on “hot-loading” Blackfn firmwares

#14

Thanks I’ll check that out. My goal tonight was to get the lines.ldr translated into a byte array like in the mix example. I found the correct hexdump incantation and now I have a file like the one in the mix example. Haven’t tried to load it on the device yet. Anything I should know if I mess up?

#15

I’m pretty sure I stuck some tool for that in the repo…?

#16

Lol well it’s a one liner with hexdump. I also learned about od which can do the same thing differently.

#17

I’m dormant but still ‘here’, just overloaded with building work for a studio in a shed… give me a buzz if you have any specific questions on aleph tooling…

There’s lots that can be done on Linux host with some cross compile trickery

1 Like
#18

I would very much be interested to learn the tricks enabled through cross-compiling on Linux.

I loaded the byte array of lines.ldr into my new app scaffolding based on mix and it works! Next I’ll actually design what I want this thing to do. I did depend on operators in Bees to build some of the read speed modulation.

#19

In a nutshell bees ops and blackfin modules can be developed on Linux host in C - bees ops cross compile as pd objects via an external and blackfin cross compiles to osc-enabled Linux/Jack console program.

Nothing in place to enable offline avr32 app development, no encoder/screen emulation at present…

#20

That’s pretty cool. Most of what I’m going to do is UI work from existing modules and modes for the encoders and drawing to the screen so it looks like I’m stuck with the process I described above :frowning:

I noticed that there is an ELF binary generated by the build system, which I guess could be loaded into GDB, so it could be possible to debug outside of the avr chip, right?

#21

From past experience with the device… Whatever you can do to offload development to host will probably be worth it in the long run…

But maybe that’s just my (as-yet-undiagnosed) ADD tendencies… I’d rather faff around over engineering emulators than sit around waiting on flash cycle.

If you are gonna do lots of flash cycles, I found press-ups and beer helped a lot with boredom during on-device development…

#22

How do people in The Real World do this with the same chipset? I’m guessing expensive platform products and IDEs.

#23

As far as I can tell the ‘industry standard’ approach is too throw man-hours at any problem!

Cross-compile techniques seem poorly understood and under-utilised across the board (in my limited experience). I see a cultural trend to force embedded engineers to use debugging techniques in development which are applicable to ‘field failure’ scenario.

In the world of ‘firmware as product’, this is prudent I guess. I’m glad there is a weird alternative reality (somewhere) where ‘user’ and ‘programmer’ are not mutually exclusive.

1 Like