OSC routing hardware

243 views
Skip to first unread message

Rich Walsh

unread,
Oct 21, 2021, 2:54:45 PM10/21/21
to ql...@googlegroups.com
Scratching my head about dual-redundant OSC again. Someone suggested ETC's OSCRouter as a way of having two devices receive the same OSC messages. I was wondering if there's a piece of hardware that could do that – or maybe it could run on a Raspberry Pi or similar?

Obviously you still end up with a single point of failure, but that's always been true using MIDI distribution amplifiers in redundant systems too…

Maybe a small dedicated PC running OSCRouter to marshal signals to the right places is the way forward?

Rich

Dominic Bilkey

unread,
Oct 21, 2021, 3:45:21 PM10/21/21
to ql...@googlegroups.com
We’ve been running the router on QLab machines pointing at multiple DS100’s for over 12 months now and it’s not missed a heartbeat.

D


> On 21 Oct 2021, at 19:54, 'Rich Walsh' via QLab <ql...@googlegroups.com> wrote:
>
> Scratching my head about dual-redundant OSC again. Someone suggested ETC's OSCRouter as a way of having two devices receive the same OSC messages. I was wondering if there's a piece of hardware that could do that – or maybe it could run on a Raspberry Pi or similar?
>
> Obviously you still end up with a single point of failure, but that's always been true using MIDI distribution amplifiers in redundant systems too…
>
> Maybe a small dedicated PC running OSCRouter to marshal signals to the right places is the way forward?
>
> Rich
>
> --
> Contact support anytime: sup...@figure53.com
> Follow QLab on Twitter: https://twitter.com/QLabApp
> User Group Code of Conduct: https://qlab.app/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups "QLab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/27942E57-3B30-4C63-B53C-46343A8521C0%40mac.com.

Rich Walsh

unread,
Oct 30, 2021, 7:08:25 AM10/30/21
to QLab
Conceptually, I don't find that very satisfying though: what if you need to combine OSC from multiple sources – eg: object tracking and QLab, and maybe lighting as well? Do you run a piece of software on every OSC source – assuming that you even can (mixing console?) – to echo messages to localhost out to multiple clients? It might work for quite a few specific use cases, but it's not scalable.

How do you switch between redundant sources? I've yet to see an elegant solution for switching OSC: the best so far is to trigger a QLab cue via GPIO-to-MIDI from the changeover button that does KVM & audio, and have that cue somehow work out which machine it's on and set the master overrides accordingly. I don't particularly like that as you rely on the QLab you are switching away from to turn itself off – but why are you switching away from it if it's working well enough to do that? For me, a dual redundant system needs to turn off all output from a device when you're not using it, even if it has crashed.

Wouldn't it be nice to have a separate bombproof router that you could trigger via GPIO that handles all the OSC, just like an XDANTE-1 does for audio?

It's a real shame that when OSC was developed it didn't account for one-to-many (but not all) messaging – unless there is a way of multicasting it (with IGMP snooping of course)?

I wonder if there's a managed switch that can recall presets instantly – so the ports stay on but you allow / deny relevant traffic on the fly? Mirroring would be tricky as the packets need destination address change – is that even a switch function? Something to ponder another day…

Rich

Freddy Komp

unread,
Nov 3, 2021, 12:54:13 AM11/3/21
to QLab
Long time no post,

But being faced with currently creating a multi-machine redundant QLab Playback, I have pretty much everything solved except the networking part. For all tracks, we are running a Radial SW8 that takes both all audio channels and our LTC tracks and can switch both instantly, either on dropout of 1K tone, or manually, but in between tracks, we could fire OSC to run actor movement dependent cues... looks like we will go down the track of running individual LTC cues from QLab now instead, as we will have the same failover working right there, but would be great to know for posterity if we ever find that golden, nifty device...

Cheers,
Freddy

Reply all
Reply to author
Forward
0 new messages