So a graphic designer from Amsterdam, Bram Fitz, got in touch recently through Twitter with some ideas for improving FoxDot’s identity. I’m a big fan of the work and hope to implement some of these ideas soon along with an overhaul of the website. Have a look below (credit: Bram Fitz)
I’ve been developing a small Python application for collaborative Live Coding called Troop (https://github.com/Qirky/Troop) that allows for multiple performers to share the same text buffer and truly live coding together. Following this, I would like to actually see it get used and probably the best way to do this would be form some sort of Live Coding ensemble around this.
The group would not necessarily use FoxDot exclusively – there are several other languages for collaborative Live Coding that exist – but it would be exciting to see Troop in action and get some feedback on the interface etc. Troop can (or rather, will) either be run on a LAN where the server-side application handles all scheduling and sound creation, or on a public server and the clients execute code in sync. Local meet ups will most likely be based in Leeds, UK as that is the where my University is based, but with the magic of the internet it will be quite possible for members to take part remotely.
If this sounds like something you would be interested in, please get in touch below:
So FoxDot is now executed as pure Python code now (finally!) which means that it doesn’t have to be run through the UI that comes with the package – and I can start thinking about putting it on PyPi too. Since its inception, FoxDot used regular expressions to preprocess some of the code but this meant that saving any work as .py file just wouldn’t make sense to a Python compiler. Now, however, FoxDot reserves all one and two character variable names for Player Objects so that using a double-arrow syntax a la
p >> pads() updates an already existing Player Object instead of creating a new one. Hopefully this makes for more flexibility and people being able to import FoxDot into their own work somehow. I’m still figuring out the best way for people to actually run the environment but I’m really excited for what this means for FoxDot.
FoxDot is a combination of two things: an interactive Python mini-text-editor and a library for making algorithmic music with code. It has been designed for Live Coding music, a practice of performing music with programming languages in front of a live audience. If you would like to know more about Live Coding, checkout toplap.org for more information!
There are several languages used to Live Code music and each has their own identity, syntax, and philosophy. One of the most widely used languages is SuperCollider, which is actually used by FoxDot to create sounds. It is extremely powerful and flexible but the trade-off is that it often requires a large amount of typing and has a fairly steep learning curve. FoxDot could be considered as a user-friendly interface to a subset of SuperCollider’s many great features.
Another language that is becoming increasingly popular in the Live Coding community is TidalCycles (often referred to as just Tidal for short). This is based in the functional programming language called Haskell and chains together pattern-making functions and applies them to the playback of audio samples (although it is also using SuperCollider now create sound as well). One of the few drawbacks to Tidal is the difficult install on Windows machines but it is still in development.
FoxDot, like Tidal, is a language that is used for describing musical patterns, but in a slightly different way. It gives certain data structures, called Player Objects, instructions defined by traditional musical concepts such as scales, octaves, and notes to play until stopped. For more information on how to get started with FoxDot, check out the start Starter Guide.
Part of making any piece of software accessible is the use of clear documentation. I had originally planned to do it all automatically using Python’s docstrings and some scripts but I’ve now come to the conclusion that I’m better off doing it by hand and making it as simple as possible. My aim is to write up the basic documentation of how to use FoxDot by the end of the summer and add some more technical description of what’s going on behind the scenes by the new year. A lot of it will be grabbed from the GitHub and wherever else I’ve been writing things down but it’ll be good to have it all in one place.