#1

a minor update:
[ https://github.com/tehn/aleph/releases/tag/bees-0.7.1 ]

bees 0.7.1

  • BIGNUM should now remember x/y location
  • add new boot mode: hold down SW1 (second from left) to perform a “clean boot,” loading “clean.scn” file. unlike SW0/SW3 “firstrun” mode, this doesn’t perform any writes to flash, so is a little faster and safer as a live performance panic-button.
2 Likes
Default scene in Aleph
#2

next goal: block processing on DSP for efficiency. today i successfully made a basic ping-pong DMA on a 16-sample block, executing a simple 4x4 mixing matrix. amazingly, it works without glitches, so the tricky parts seem basically under control. for the next few weeks i will be (re)building audio algorithms on top of this, hopefully with significant speed improvements. hopefully this will allow computational headroom for more voices and more advanced processing (like FFT-based.)

which is all just to say, i would prefer not to look at BEES or the control side in general for a little while, with the intention of completing significant progress on DSP improvements. i think BEES and avr32_lib are in a pretty good state and relatively accessible for further customization.

<3, ez

6 Likes
#3

thank you.

about to go to a rehearsal with mine in 15 minutes. such an amazing instrument and tool for sound research.

#4

whoaa, thrilled! I´m just starting with an attempt on internal modulation and some other stuff for the prgm module, and it’s starting to get pretty crammed. if there is anything I can do to help, just let me know!

1 Like
#5

Looking forward. Exciting times!

#6

i believe that there’s something wrong with lines. a. receives incoming audio but ignores all the manipulations. i was scrolling via all options without any success.

#7

haven’t touched the lines code in quite a while, but i did check the factory scenes last night and all seemed fine… ?

#8

oh! actually are you sure you’re using the newest lines? (0.2.4) there were some changes, including clearing buffers on init and fixing a race-condition parameter init bug exposed by same. now there is some incompatibility between new lines / old bees and vice versa.

#9

sorry! i was sure that latest lines were included in 0.7.1. i’ve replaced the lines files and now everything’s fine. thank you!

#10

ah, really? so sorry, mixup in the .zip, my fault. will update 0.7.0 and 0.7.1 release pages

#11

ok, updated bees 0.7.0 and 0.7.1 release archives with modules from the lines 0.2.4 release… so hopefully all is good now

2 Likes
#12

Wow! Thank you! :smile:

#13

Very very very exciting news
And super willing/ ready to bug test ( as I can’t offer coding help)

#14

so i’ve just got my head back into developing some new Aleph scenes to work with a midi controller and finding some weirdness in both the 0.7.x versions.
The new MIDICC operator retains its values which is great BUT it jumps around randomly at random moments. (i re-flashed with 0.6.2 to confirm this doesn’t happen in previous versions)
any thoughts?
my test set-up is
Faderfox PC4 plugged in via usb
load clean scene
create MIDICC receiving on all channels (have also tried specifics)
send thru MUL to value on Waves.
At certain values it will then begin randomly jumping around after you have sent it a value.

  • real weirdness is if i send another a value from another midiCC that i haven’t created an operator for the jumping usually stops.

hope someone has some advice @ngwese @zebra @rick_monster @Yann_Coppier ? …
it’s an awesome combination to get direct knob access to all the different aleph parameters

#15

ok! I should also bridge the aleph serial protocol to osc when I get a minute. Shouldn’t be hard at all I’m now very familiar with osc/common lisp - using that combo at work along with a bunch of mouldy faust code to pretty devastating effect (if I do say so myself).

Maybe that would be enough to tempt a few more users onto my dev branch & testing corner then push for a new bees release…

Hummm I would just love to have enough time to work on aleph long enough to get a really properly working rig (currently waiting on switches for my beaglebone black foot-box-controller-aleph-midi-boomerang-glue-thing).

Whatever - I learnt enough dsp through aleph dev to upgrade my day job from accountant’s perl-lackey to microspeaker-torture-engineer! Now, if I can just convince the boss we should really be in the open-source hardware synthesizer ‘business’…

1 Like
#16

i’ll look when i can. you confirm it’s new between 0.6.2 and 0.7.x?

#17

i just built a really stacked scene in 0.6.2 with 24 midiCC operators to check.
In this situation just 2 of them jump to a very low value at very sporadic moments, sometimes at up to 45secs intervals. (strangely the ones connected to low0 and low1, not sure if that’s connected or chance, they are not assigned to consecutive operators)

so… behaviour is sort of new in that it is continuously rapidly jumping and seemingly affecting all of the midiCC operators.

#18

I can’t offer much at the moment without some cycles to look at the code…

If memory serves the midi handling code in the eurorack modules came from the aleph code base. When adding USB midi support to earthsea some months back I did run to ground a situation where the ISR handling midi input was queuing up USB transfer requests faster than USB stack could service them. I think there might have also been one or two cases where midi packets weren’t parsed correctly if the incoming midi data was sufficiently dense. I have no idea if that could play a role here. I could imagine the quantity and timing of interrupt handling changing between bees releases.

My intention has always been to further harden the midi parsing logic on earthsea then back port all the changes to the aleph…

1 Like
#19

I just updated to 0.7.1 from 0.6.x and the display is much darker now. Is that normal?

#20

rebooted the hex and it seems better now :confused: