a couple of suggestions for OSCServer 🙂
so... I was trying to use OSCServer in place of my own MEC library for some high volume, high speeds comms,
and had a number of problems with it - that have some simple solutions which I think would make it much more useful...
a) checkMessages - usleep()
if you are sending a lot of message, this causes lag, and also potential loss of messages as you overrun the inbuffer.
I think this should be configurable , during the setup call (can default to 1000)
its probably wise to also make the inbuffer size configurable
b) popmessage is causing mode switches when used on audio thread
(Ive a suspicion this might also be causing a certain amount of lag)
I think this is probably the std::queue
Id recommend you move to a lockless reader writer queue for this kind of stuff.
I personally use moodycamel - which is absolutely brilliant (imho !)
background:
basically im sending 100s / second of tiny osc messages from an Organelle from an expressive controller,
currently (though might change this) they are coming over the USB network connection.
i know it works as if i do this MEC, i get zero lag , or message loss - so the link can cope quite easily.
i thought id tried with OSCServer on the bela end, just so i didn't have to included my mec library , which makes it easier for others to build - but alas at the moment - a no go... but i think the above would resolve the issues, given its pretty much what im doing in mec.
its not high priority for me, as i'll just use mec for now, but perhaps useful for others... and I guess I will update when possible.