#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:

#21

@dspk, really stupid question, but i have to ask: are you sure you’re not running a debug build of 0.7.1? (maybe a mislabeled one; if it’s debug, you should see some baudrate settings being printed on the screen at boot.)

otherwise, i agree with @ngwese that this sounds like a situation where the USB stack can’t keep up with the transfer requests.

i’m looking at some diffs and don’t think there was any change to the midi RX handling code itself. we added TX code but it shouldn’a have had an effect.

the most significant changes in 0.7.x were greg’s fixes to app pause/resume , especially nested calls. this greatly improved stability, but also means that interrupts are probably being disabled more often now. this gives the USB stack less opportunity to empty the MIDI RX buffer.

we could always try increasing the MIDI RX buffer size, but this is a sloppy band-aid at best.

i’ll look at it a bit more when i can and also checkout the fixes from earthsea.

#22

While investigating what must be added to support midi clock to earthsea’s usb midi mode I think I might have found a potential source for the glitchy midi input (on both aleph and earthsea).

The code which parses USB-MIDI event packets and turns them into internal kEventMidiPacket seems like it might have a few kinks to work out. After staring at the code for a bit I’m starting to suspect that:

  • running status isn’t handled in all cases
  • the rxBuf contains 32 bit USB-MIDI event packets yet the parsing code is only skipping over the packet header of the first event. If there are multiple event packets the headers get interpreted as if they where midi data. (see section 4 of http://www.usb.org/developers/docs/devclass_docs/midi10.pdf)

…now off to confirm my suspicions.

https://github.com/monome/aleph/blob/dev/avr32_lib/src/usb/midi/midi.c#L67-L125