#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

#23

Well it would appear that USB-MIDI disallows running status which means that a greatly simplified “usb midi” specific variant of the midi_parse(...) function might be in order (little more than some bit shifting seems to be in order).

1 Like
#24

Oh I think youre right, I would put it differently for my own understanding:

If the rx buffer contains more than one midi event, their data will be munged together into a single avr32 event, instead of posting 2. Right?

I guess this would happen more often in 0.7.1 for the reasons above

I think yr right that it could be much simplified… this looks like the aftermath of some messy refactor

#25

Well if I’m running through things in my head correctly I think the following sequence is possible with two (or more) midi events in the rxBuf:

  • status byte is found => packet.data[0]
  • two data bytes found => packet.data[1] and packet.data[2]
  • start of next incoming midi packet
    • if midi packet header has CN value >= 0x8 then the header itself is interpreted as a status byte, the previous event is posted and all subsequent parsing is off by one byte
    • if midi packet header has CN value < 0x8 then header byte itself => packet.data[3]
      • if the next byte (which is the beginning of the actual payload for the next midi message) is a status byte then the previous event is posted with garbage in the LSB else the whole previous event is discarded because (dst > packetEnd)

…basically the first event will probably get posted, possibly with some garbage at the end. Subsequent events may be posted but are likely to be entirely corrupted.

I hope to have time tonight to test out an alternate version midi_parse along with one other tweak. If all goes well I’ll port over the changes to the aleph code base for testing.

#26

… you’re right, the basic bug is that it assumes CN is always the first byte each time the endpoint is read. i think it was originally interrupt-driven…