I’m seeking help in resolving a persistent issue with OSC feedback in Arena. I’ve build a OSC application to facilitate communication between Resolume Arena and Resolume Wire Patches. The problem is that they both listen to the same incoming and outgoing OSC port, to solve this I want to implement the behavior as explained below, but I am doing something wrong.
Expected behavior:
-Arena sends an OSC message with the address “/composition/something”.
-The Bridge prepends the “/comp” prefix, making the address “/comp/composition/something”.
-The Wire Patch receives the message, strips the “/comp” prefix, and restores the original address “/composition/something”.
-The Wire Patch processes the message and sends a response to Arena with the address “/arena/composition/update”.
-The Bridge strips the “/arena” prefix from the Wire Patch’s outgoing message, making it “/composition/update”.
-The Bridge sends the modified response message to Arena, effectively relaying the Wire Patch’s response.
Actual behavior:
Arena continues to receive OSC feedback, indicating that the Bridge is not effectively isolating Arena from its own outgoing OSC signals.
The Question: What’s going wrong
I really appreciate any insights or suggestions you can provide to help me troubleshoot this issue. Thank you for your time and assistance.
Thanks for the reply. I don’t think this should be too complicated and this is the easiest way to make this work. I want to use Vuo only as a bridge in between wire and arena. And I like Vuo, but in this case, the stuff I want to do is way easier to do in Wire, and it’s also more integrated into resolume.
The application is like a translator for OSC messages. It takes messages from Arena, adds a prefix, and sends them to the Wire Patch. It also takes messages from the Wire Patch, removes a prefix, and sends them to Arena. This allows Arena and the Wire Patch to communicate with each other even though they use different naming conventions.
Without the Wire patch and the Resolume project it is very hard to try and identify the issue and I’m no Wire aficionado anyhoo.
I already understood what you wanted to do within Vuo but it’s very convoluted, hence my questions. If it’s not possible in Wire alone my suggestion is to do it solely in Vuo.
If it’s not a GPU intensive operation I doubt the overheads or operability between Wire/Vuo are even measurable.
Have you asked on any of the Resolume chanels? Maybe a feature request for replace/append text there?
Hi,
personally I don’t know Arena; my doubt however is why are you building a FFGL filter a not a normal Vuo composition. The described features - OSC bridge between apps - shouldn’t require to be developed inside a filter, I’d go for an app that you run in parallel with the OSC sender and the OSC receiver. Don’t know if this solves anything, but I’d try to reproject the thing as an independent app.
regards
mic
Thanks for the replies. I make it into a FFGL filter just because that way it will run inside arena, but it could just as well be a standalone app, but that doesn’t change the problem that I have. My problem is I am doing something wrong with the filtering of the incoming messages. I think that the problem come from the find text node. I’m trying to split the incoming list into two different streams by using the find text node connected to the Select Output node. I’m thinking that this doesn’t really split every instance in the list to a different output so that’s probably the problem. Do you guys have any ideas how to solve that? Because as you can see, that patch isn’t and shoudn’t be so complicated I think but it’s just that I am missing something.
The “select output” node in the patch you designed direct on “option 2” node every message that include “/arena” in the message, other messages are directed to “option 1”.
What sounds crucial to me is the idea that more than one program could listen to the same port. Usually this is not allowed with OSC. If you run a Vuo patch that instantiate a OSC listener on a port on which another software is listening, the Vuo OSC listener simply does not run. Indeed you can find an error log in console. And this is true for every other OSC software.
Not considering how Arena and Wire could listen concurrently to the same port, I exclude however that you could listen to the same port.
I’d start investigating on this.
OK let me clarify that part. Arena and Wire are two different programs. The moment they are open at the same time they can communicate through OSC on their own individual ports, just like any other software communicate through OSC. But if you build a wire patch and open that patch in arena, it will listen to the same in and output poort as arena does. So this means that there is normally no way for them to communicate. That’s why I would like to build this application. I hope this clarifies some things.
I dont’ know Arena, but from the description you are giving, it sounds to me that the bridge approach is not correct. A bridge could work between distinct apps communicating through OSC. In this setting, you can filter outgoing messages of the first app and resend to the second app, and viceversa. The description you gave in this last post, however, is of Wire as a sort of plugin into Arena. If this is correct, they seem to be two environments not independent; sounds like if Arena shares with Wire compositions the messages Arena receives via OSC. I think the best forum to ask is not this, but rather Arena’s one, as it sounds to me that your issue is not in how you manage the flow in the Vuo app, but rather in the bridge approach. Perhaps, the filtering you wish has to be done in the Wire path itself.
Cheers
mic
@NoodleDesign, I haven’t had time to look in detail at the problem yet, but my general suggestion would be to try to break the larger problem down into smaller tests and check things one at a time.
I understand you’re normally running the composition as an FFGL plugin. For purposes of debugging, maybe you could run test compositions within the Vuo editor, so that you can click on ports and check their values.
Is your composition actually receiving OSC messages? I don’t know of a reason it wouldn’t be able to receive from Resolume/Wire running on the same computer (maybe @cremaschi does but I’m not sure what he’s referring to). At any rate, it’s always good to check since the device has to be specified exactly right or it won’t work.
You had a hypothesis that your method of splitting the incoming list into two different streams might not be working. Can you send OSC messages slowly enough to your composition to watch the data going through and see if it’s working as expected? If not, you could copy-paste that piece into a small test composition and add nodes to simulate the data that would be coming in through OSC, and see if it works or not.
One further thought — you might have better luck with Filter by Address instead of Find Text, something roughly like the attached composition (which I have not tested): VuoBridge.vuo (4.5 KB)
Thank you so much I think that is it. I know what I’m doing is not really the way it supposed to be but it should work for sure and the filter by address was the thing I was looking for. Great thx. Don’t have time to really test it now, but I’ll report back.
@jstrecker that you so much. Your solution fixed my problem, but it left me with a other ;) the whole idea of the app is that it is a relay between arena and wire, and it will relay every 0SC message. In my original patch which worked, but sometimes gave me feedback. I just connected to the receive OSC message straight to the send a OSC message. But the way it works now I have to specify what kind of OSC signal I want to send. If I use generic, it will change all incoming OSC messages into Boolean values. What would be the best way to send through all different types of messages? I was trying to split them up in different types but can’t really figure that part out. Also tried to get a message to the sent OSC out without a Make Message but then it stays a text message and it’s not a OSC message anymore. Any more help you great people could give me would be greatly appreciated.
When you send the message from Arena/Wire, you could include the data type to the address. Then in your Vuo composition, you could use Filter by Address to route the message to the Get Message Values node of matching type. See this example: OscRouteByType.vuo (3.4 KB)
I think you’re asking for a more dynamic/automatic way to select the data type within Vuo, but this is the best you can do currently. The Get Message Values node is limited in that you have to select the Value data type when creating the composition and can’t automatically change it as the composition runs.
