What are the true limitations of midi on bela?
I am building a cv sequencer using external midi device, and whenever there are more than 3 noteouts, I get "underrun 1 blocks dropped" printout, until it is printing too quickly for IDE. I removed all the audio stuff just to test this.
Can you post your code? MIDI itself is not particularly CPU intensive. It may be what you do with the input that matters.
or it may be a Pd issue if you are using Pd. Either way, seeing the code would help troubleshooting
Its a bit complicated patch for external viewers (but not complicated in terms of computation), but I will clean it up and perhaps remove any unneccesary audio bits so it is easier to debug and understand, will do. In short I am sending note outs every 250ms or so and occasionally sending out heaps of midi data (resetting all the lights on my controller) with [until].
radiowaves iowaves#12917 . In short I am sending note outs every 250ms
That should be fine, how many notes at once are you sending?
radiowaves so and occasionally sending out heaps of midi data (resetting all the lights on my controller) with [until].
This could be the source of the issue: [until] runs all in 0 logic time. That is: it will run all within one audio callback and it could be causing dropouts if you are running it a lot of times. Sometimes adding a [delay 1] between calls is preferable instead. See the example below that I adapter for you from the [until] help file.
I checked, I am not sending out with [until] all the time. But when I do, I get dropouts yes, and/or when I am loading up a soundfile to an array.
Here is the project. It is still quite complicated to external eyes, but there are two components that do all the work (I think):
[track] abstraction, which auto-generates sequences with one knob (0-63 value is random sequence increasing in note values/gates amount, 63-126 values are same but generating markov probabilities based on sequence, 127 is random).
[midirouting] which holds all the loops to turn on/off several lights on my controller.
Rest is just re-naming midi/audio inputs/outputs with specific send/recieves.
radiowaves when I am loading up a soundfile to an array.
This is another bad one: [soundfiler] stops everything and reads from disk and so it will cause dropouts. To avoid this, you would normally preload all the files at startup (assuming they fit in RAM). Alternatively you can use [readsf~] to stream from disk, but you need to give it at least half a second between opening the file and start playing it (precisely because, in order to avoid stopping everything it does the buffering in a separate thread!).
I cleaned up the project. There is only the routing which maps my controller (akai midimix), so I could see the lights.
I tested this with midi only and with running audio -- no difference.
After cleanup, the rate at which dropouts occur, dropped, but it still happens at constant rate while running midi out. See printout.
noteout _ port: 0, channel: 0, pitch: 18, velocity 127
noteout _ port: 0, channel: 0, pitch: 14, velocity 0
noteout _ port: 0, channel: 0, pitch: 17, velocity 127
noteout _ port: 0, channel: 0, pitch: 13, velocity 0
noteout _ port: 0, channel: 0, pitch: 16, velocity 127
noteout _ port: 0, channel: 0, pitch: 18, velocity 0
noteout _ port: 0, channel: 0, pitch: 21, velocity 127
noteout _ port: 0, channel: 0, pitch: 17, velocity 0
noteout _ port: 0, channel: 0, pitch: 20, velocity 127
noteout _ port: 0, channel: 0, pitch: 16, velocity 0
noteout _ port: 0, channel: 0, pitch: 19, velocity 127
noteout _ port: 0, channel: 0, pitch: 21, velocity 0
noteout _ port: 0, channel: 0, pitch: 24, velocity 127
noteout _ port: 0, channel: 0, pitch: 20, velocity 0
noteout _ port: 0, channel: 0, pitch: 23, velocity 127
noteout _ port: 0, channel: 0, pitch: 19, velocity 0
noteout _ port: 0, channel: 0, pitch: 22, velocity 127
noteout _ port: 0, channel: 0, pitch: 24, velocity 0
noteout _ port: 0, channel: 0, pitch: 3, velocity 127
noteout _ port: 0, channel: 0, pitch: 23, velocity 0
noteout _ port: 0, channel: 0, pitch: 2, velocity 127
noteout _ port: 0, channel: 0, pitch: 22, velocity 0
noteout _ port: 0, channel: 0, pitch: 1, velocity 127
Underrun detected: 1 blocks dropped
Link to patch:
UPDATE:
It seems the dropout was caused by triggering 4 leds at the same time. I notice there is also a delay in led lightup, which should not be there.
When I removed the code for lighting up leds, underruns stopped. I triggered leds digitally.
radiowaves Link to patch:
this code doesn't cause any dropouts for me when running it. Did you have to do something with the midimix to cause the dropouts?
giuliomoro
You are right!
When I disconnect my midi controller, it runs almost fine, saw only 1 random dropout. I do trigger leds on my midicontroller.
Since it was also caused by leds on the module itself when simultaneously triggering leds on my controller, I think it is quite clear it is power issue. Now I have to test out how many lights on my controller can bela/salt handle.
radiowaves Since it was also caused by leds on the module itself when simultaneously triggering leds on my controller, I think it is quite clear it is power issue.
I doubt that's the case. A power issue is unlikely to happen on Salt and it would probably have different consequences from what you can see there.
Can you describe what input causes the dropout? This way I could fake it in the PD patch and reproduce the issue for further investigation.
My guess is that it's probably down to the printing so maybe I should look into removing all those automated MIDI print statements.
If you update your board to the latest dev branch with the instructions here, you can add to your patch:
[loadbang]
|
[verbose 0(
|
[s bela_setMidi]to disable printing and see if that removes the dropouts