On 06.02.19 09:39, Jonathan Carter wrote:
Hi derpeter!
Hey :-)
(sorry for delay in response, I've been traveling back from
FOSDEM/sleeping :) )
On 2019/02/04 14:13, derpeter wrote:
i was pointed to your blog post about building a new tally light.
We have already build much of what you describe in blog.
See https://c3voc.de/wiki/projects:tallycom
https://c3voc.de/wiki/projects:tallycom:bestand
The script already interacts with the voctocore :-)
Great stuff!
I also have already a version with a small OLDED screen on my desk an
proof of concept mumble setup running on the pi.
For sending messages to the display i plan to use mumble. I also have
already hacked some basic support for the display in go to merge it into
the mumble client (which is also go).
We also have already tested some headsets to use for the intercom part.
Yeah I was told that ccc already had a pi for tally that does mumble,
it's nice to see some details about that.
As our goals seem to be very similar, lets have a mumble soonisch and
join forces!
Sounds great! Yeah it makes complete sense to do that. We plan to add a
display (like
https://www.amazon.com/ThyWay-Touch-Screen-Protective-Raspberry/dp/B07L4PKDK3)
to our PIs and attach them to the camera using a boot. We plan to rely
less on voice because we don't want directors barking orders at camera
operators, and we also don't want camera operators generating noise in a
talk room. That said, we're not at all against the idea of using mumble
and it's certainly nice to have the option to use it when necessary.
I use this one
https://www.amazon.com/HiLetgo-Serial-Display-SSD1306-Arduino/dp/B076DYCWC8
and we mount the pi to the flashmount of the cam by an
flash-mount-counterpart (no clue how to call it) that is screwed to the
pi case. This makes a top mounted display not that usefull.
We have very good experience letting the mixer operator talk to the
camera operators. I agree that it can be an issue if it gets to noisy
but this in most cases it is not a problem. But yes it would be optional
so at the end i only needs to used if necessary.
We'll also rely on using a pi3b+ specifically, because we're planning to
netboot it, with current plans to download a ~100MB squashfs image and
then keep that in memory (so that it can deal with intermittent network
losses as apposed to using something like nfs/nbd). That means that we
can quickly provision by just building the images as part of our ansible
deployment and the only configuration that's necessary on-site would be
to select the pi mac addresses from the dhcp logs and assign their
positions.
I would try to not make this RPI specific. But you can netboot all RPIs
not only 3b+ if you have a netboot loader on a card. This is also true
for most other pi equivalents.
We gave our PIs static IPs and run ansible on a plain raspbian / debian
to configure them. Initial IP can also be set via DHCP
In our current setup we don't have a netboot server and also it is
sometimes very usefull to use wifi on the PI so we don't need to run
Ethernet to the Cam.
Again i don't see an issue here that stops us for working together, the
deployment / hardware is IMHO independent of software.
We're also considering using the touch screen for certain kinds of
communication back (like a "I need help" button or "Yes"/"No").
Obviously that would have to be used very selectively since the device
will be attached to the camera, but I like your idea of using external
buttons for that.
The current plan on our side is to have a footswitch or a button on the
handle of the tripod for Push to talk. I would not wan't the operator to
touch anything on the camera if not necessary as this will always result
in vibrations.
This will probably be hard to have in the same application. Maybe we can
have UX and a non UX version like tallycom-cli and tallycom-ui or so.
For actual tally light, Andy has an idea to attach a small strip of RGB
lights to the PI, which will allow choosing of both brightness and
colour. Typically we wouldn't want to use too high brightness because we
don't want to distract the speaker/audience with it, but we could do
something like have the LEDs burn a bit brighter when a mode is changed
or when it seems like we've lost the attention of the camera operator.
We have an RGB LED attached currently we don't use dim it but this would
be possible by PWM. I also thought about using SPI/I2C controlled LEDs,
having support for both should be no problem.
For messaging we plan to use the socket of voctomix-core and use this
both to choose tally cards and activate lights, I think that might end
up being a better method to send messages than using mumble... but,
having said that we don't have specific code for that yet and I haven't
seen that implementation yet, but I'm sure we can figure it out :)
For activating the light / switching its state the code connects to the
vocotmix core and listens to the "chat" between gui and core. All
information necessary for operating the LED is already in that chat. The
benefit of using mumble chat is that other participants of the intercom
solution can also use the chat / audio. So e.g. people who work as
stream observers can also send messages. We are planing on extending the
intercom feature further as we need it on other places to.
But there adding some messages that get send by the voctogui and are
only picked-up by the tallycom code is easy so we can have both options
(text by mumble and text py vocotogui) at the same time.
-Jonathan
derpeter
