#do your samples start and end points
1 messages · Page 1 of 1 (latest)
@plain salmon have you noticed a big difference porting your picoseqstep to C?
I guess you are not running audio on that, but noticed in circuitpython midi also gets a bit phased out (even when commenting all the audio / UI stuff, just running the seq)
that is a 8-voice example running on the pico w/ circuitpython
and it's funny because it's a domino delay because of the loop iteration, from 0 to 8
my code might not be efficient anyway, it's just readable and pythonic, C dev's eyes will cry
I'll keep debugging. Timer interrupts might be more accurate for sure, but seems that my cascading issue is happening inside the same loop cycle
heh I do a lot to try to make up for the timing inconsistencies of CircuitPython in my PicoStepSeq, but it's ultimately doomed. If you keep track of how much time you're over the mark, you can subtract some of that off your next duration to try to get back in time
@wheat halo And yeah, Arduino version of PicoStepSeq is pretty rock solid
If you're using adafruit_midi you may have better luck using winterbloom_smolmidi. It's got a bit less overhead https://github.com/wntrblm/Winterbloom_SmolMIDI
and you really don't need adafruit_midi for sending midi
It would be interesting to try a version in Micropython since they have timer interrupts
yeah, you're right, sending midi is just sending a 3 bytes through serial
I've seen it's supported in micropython too. although, one must be real quick inside them, seems like they're not supported in circuitpython for some reason
I've said that C dev's will cry looking at my code, but I guess I'm the one that'll cry because of timing issues 😅
thing is that circuitpython is pretty close, but not perfect for this kind of project
CircuitPython is not very forgiving of timing-sensitive applications. The CircuitPython lead Scott has a philosophical stance of "no interrupts" for CircuitPython because most of the time when people are asking for that, they're thinking too low-level ("I want interrupts so I can output audio") when really the question should be "I want an audio driver that uses the DAC", because there's no way an interpreted language like CircuitPython could produce data quickly enough for an audio DAC. Also, there's the complexity of no atomic reads & writes if an interrupt modifies a variable while the main thread is in the middle of updating said variable: Micro-/Circuit-python memory structures are complicated and not atomic
I agree with him about those cases, but I really think a sort of timer facility could be done that could still guarantee memory safety while also giving us more reliable timing
agree tod! yeah, just a hardware timer would be nice