So ziemlich jedes Projekt der letzten Monate, an dem ein Raspberry beteiligt war, landete in einer Plastikbox, wie man sie z.B. bei Conrad oder Reichelt bekommt. Was ich bislang nicht wußte: Das sind Gehäuse von einer Firma namens ‘Donau’. KGB11, KGB13 und KGB21. Hier gibt es die Datenblätter dafür.
Anfangs war es immer ein ziemliches Gefrickel, die Aussparungen passend hinzubekommen. Das hat sich mit dem 3D-Drucker schon etwas geändert, aber perfekt war das immer noch nicht. Meine bisherigen Konstruktionen sahen immer so aus, dass der Raspberry IN der Frontplatte befestigt war, was immer zu einem ziemlichen Klapperatismus geführt hat.
Without that Corona-thing it’s about once a month that I am deejaying in my favourite bar in my hometown (Trash in Osnabrück). Few months ago I bought a projector which I am using to do live visuals in parallel. It took me some time to figure it out but I think I found the setup with the best possible balance between transportability and useability.
A few weeks ago I successfully managed to build Mixxx 2.x on a Raspberry Pi 3. Once I got that done I immediately identified “more than enough” (that is: one) situations where it would be great to have yet a smaller piece of hardware to run Mixxx on (placing a link. Just in case you might not already know what we’re talking about). That’s why I think running Mixxx on a Raspberry PI Zero ist the next logical consequence.
I once (and only once) managed to successfully build the latest branch on a Pi Zero (2.3.0 alpha pre, as of time of this writing) but was not able to reproduce it. Good thing: After some tedious trial-and-error I finally found a way to reliably build Mixxx 2.2 for (and on!) a Raspberry Pi Zero.
I wanted to build a sample-player (“soundboard”) and decided to use Mixxx because it has all the necessary features that I was looking for (open source, runs on a Raspberry, highly customizable, …).
My target scenario for this installation is to use it together with a Midi-controller and the official 7″ touchscreen for Raspberry Pi. While Mixxx comes with a set of skins (i.e. user interfaces) with focus on different aspects all of them have in common that they are providing all the functionalities for DJ’ing: 2 or 4 decks for playing tracks, crossfader, mixer-section, library, etc. Many of these things can be hidden from the screen but even then there are still too many things left visible consuming precious real-screen-estate.
While every skin provides the functionality to hide the mixer section or the sampler there is (technically) no way to completely hide the decks via temporary selection. They seem to be seen as an integral part of every Mixxx-skin. That made it necessary to do some serious work on this. Since building a skin from scratch was completely out of reach I took the skin “Deere (64 Samplers)” as a starting point and worked my way up from there.
Due to … massive … request I took the chance and did a major overhaul of my post about the GrandMA remote command line from a few years ago. Back in the days I pulled together a quick ‘n dirty version which somehow worked and caught some interest but never really became more than a proof of concept.
tl;dr: This program provides a remote command line to a GrandMA Version 1 lighting desk (console or onPC). Since it’s implemented in Java you can basically run it from every computer that you have at hand ( yes: even a Raspberry PI ). Having a command line proved to be quite handy especially when you are setting up a show from scratch. It is simply faster to issue the command “fader 1.1 thru 5.10 at 0” than to manually set 90 faders to zero (or -god forbid- use a mouse to do this on the onPC-version without a touchscreen).
I’m a little late on that topic: Meanwhile ( meaning: a few years ago ) the GrandMA Version 2 has been released and it incorporates a native Telnet interface. This somehow makes my version obsolete but … people asked for it and I owe it to myself, I think.
<TL; DR> I’ve built a TCPSyphon Server myself in Java and tried to circumvent some of the flaws of the original Version </TL; DR>
Maybe you heard about Syphon. “Syphon is an open source Mac OS X technology that allows applications to share frames – full frame rate video or stills – with one another in realtime” (Link). It was originally intended to only work locally and not be shared between different Hosts on a Network. Fortunately someone took care of this and built a set of applications to share “Syphon data” between multiple Computers. Actually it doesn’t: It renders local Syphon data into single images (jpeg, for example), applies a compression and sends them over the network. Anyways, this is one of the applications you don’t get around as a VJ. You just HAVE to have it: TCPSyphon.
The person behind the TCPSyphon-apps also built a client for the Raspberry Pi. The TCPSClient. Now things become really interesting.
This idea caught me a while back and it took quite some effort to rebuild it from the leftovers a few days ago. Kids don’t forget: The only difference between noodling around and being a true specialiologist (they don’t call me “Doktor Andy” for nothing) lies in a reusable form of documentation. Fortunately I got this website. What would I do without it.
<TL; DR> video from Mac to Raspberry via network</TL; DR>
The approach uses Syphon, Open Broadcaster Software (obs), nginx and Omxplayer. I guess this ain’t too revolutionary. Using RTMP is quite a common task to distribute video. But it’s a good idea to have it all written down at least once. Furthermore I couldn’t find any kind of writeup like this covering this topic so … it’s okay.