Programming paradigm: callback vs main

Software Development
#1

Hi all,

I’ve recently programmed Arduino with the Mozzi library. In Mozzi, we have an audio callback and a control callback, where the audio callback should be kept short and lean so we don’t get any glitches in the output. Hardware polling (checking buttons and pots etc) is in the control callback, which runs much less often.

I know the Daisy is a much faster beast. But I am new to it. I’ve looked at some example programs, for example the EuclidianDrums, where everything is done in the audio callback routine: filling the buffer, but also keeping time, checking buttons and pots etc.

Wouldn’t it be better to place everything else in the forever-loop at the end of main() so as to keep the audio callback short and fast? Or will I get problems communicating with the callback logic?

Thanks,

Staffan

#2

It depends on numerous things: how heavy are the non-audio operations, if the load is predictable, the callback frequency, if tight timing is needed, etc.

Communication may require a special care if you have to pass complex structures. The main loop can be interrupted at any time and data integrity could be compromised if not carefully planned. Use lock-free communication schemes to be on the safe side.

1 Like
#3

I understand what you mean, but keeping everything at sample rate is probably a good idea if one is using it with Eurorack.

For VCV Rack, everything is also updated at sample rate, to keep it precise and closer to cv. Personally I could do with control rate, but there are probably reasons for keeping it all at sample rate. For the VCV comparison, it’s not the same I know, but sometimes doing everything at sample rate is a choice made to keep higher precision. Which I think is probably the choice here, since all the modules have cv inputs.

1 Like
#4

I totally agree with you. I just have the CODEC read/write in the callback running at the full sample rate, so not evenfilling a buffer. Everything else is then done from other calls from main() so that they can be done when time permits.

1 Like
#5

@Firesledge, @Jaffasplaffa and @MikeDB, thank you for your interesting answers! I gained a lot more understanding!

#6

I am thinking that if you send lfo data from a high precision Eurorack module, it’s probably the best to have a decent resolution on the inputs too.

But yeah, I guess having high resolution inputs and control rate params directly on the module probably can coexist :slight_smile:

Just worth keeping the resolution in mind if one plans to use the inputs with eurorack modules or other higher precision devices :slight_smile: