As a rusty C++ hacker, I'm trying to understand the OSCReceiver implementation. As far as I can tell, I have to create a new subclass for every address to which I want to listen. Is there no way to have a single class with multiple methods so that rather than just specifying "this" as the argument to addListener, one could instead specify a method within a class so that one could just have a collection of methods in a single class to handle various OSC addresses?
Never mind --- the Github example is misleading --- it suggests you're supposed to use multiple inheritence for this stuff instead of using composition.
You can also create an OSCReceiver::Listener (the one without the "OSCAddress" in the name) and then you'll get all the OSC traffic. You can then filter it yourself in the oscMessageReceived callback in any way you like. Definitely no need to create another object for another address, let alone another subclass!
Yeah, that's what I ended up doing. Again, thanks for responding.
I don’t really deal with methods, but I think this thread addresses the same issue…
I also wanted one class to listen to multiple addresses while juce still does most of the address resolution.
So I decided to call addListener() for each address, and it works fine!
oscMessageReceived I pick the last “sub-path” (after the ast “/”) and decide what to do.
After the object’s lifetime another one might register with the same address (e.g. when loading a preset).
Sending data to that address happens to crash the program.
Of course I call removeListenerWithAddress() in the destructor, but I found the following:
Because of the
break; in the for-loop, it will only unregister one single entry, leaving some invalid listener pointers in the array.
I ended up commenting out this line (507) from juce_OSCReceiver.cpp, so it will continue removing all instances.
Is this good in all cases? Speed, yes…
Is it worth a feature request, or is it all a total abuse?
Feels expensive to instantiate a receiver for a number of atomics…
Any other elegant way to address nodes with children (except parsing it all myself) is appreciated!