Tidal VS faust

Since then, I've been working more and more with TidalCycles. TidalCycles is an open-source live coding framework for creating patterns written in Haskell. TidalCycles uses SuperCollider on the backend, another language I've been using for live coding. Recently, I started using Tidal Looper for live vocal processing. This blog post will walk you through what you need to get started with vocal looping with Tidal Looper.

So you’re wondering what would making music with code look like? The tools I’m familiar with are TidalCycles, Sonic Pi, and SuperCollider. I’m having a hard time describing what it’s like to make music with tools like these so here’s a video of a performance. One person is live coding the music and the other is live coding the visuals. I think it’s super cool how the music is improvised and built over time by layering commands. Some keywords you could search to see more examples would be Algorave and Livecoding.

https://tidalcycles.org/ is another great example, parsing patterns of text and printing live music.

For sound live coding/algorave sonic pi and tidal cycles are great, both based on supercollider.

I don't know the alternatives but I'm a big fan of https://tidalcycles.org/. People really do crazy things, check out the videos on the front page.

I love when 2 DJs live-code together (on the same document! Editing each other's loops) or when a VJ live-codes some visuals in reaction to the DJ live-coding the music.

If you're interested in ChuCK, there's also Pure Data (a FOSS cousin of the commercial Max/MSP) and SuperCollider and a lot of live coding algorave sorta music things are built on top of SuperCollider like TidalCycles so you can execute lines of code live via a REPL or evaluating blocks of code in a document and generate beats in realtime.

Tidal Cycles! https://tidalcycles.org/

As layer8 mentioned, it is technically Haskell but more specifically a DSL and environment for live coding music.

Pretty fun to play around with!

That's also a big reason why I prefer appimages.

ossia score's AppImage is 100 megabytes: https://github.com/ossia/score/releases/tag/v3.2.0

Inside, there's:

- Qt 6 (core, widgets, gui, network, qml, qtquick, serial port, websockets and a few others) and all its dependencies excluding xcb (so freetype, harfbuzz, etc. which I build with fairly more recent versions than many distros provide)

- ffmpeg 6

- libllvm & libclang

- the faust compiler (https://faust.grame.fr)

- many random protocol & hardware bindings / implementations and their dependencies (sdl)

- portaudio

- ysfx

with Flatpak I'd be looking at telling my users to install a couple GB (which is not acceptable, I was already getting comments that "60 MB are too much" when it was 60 MB a few years ago).

Glicol looks very cool! Also check out Faust if you haven't (https://faust.grame.fr), another FP sound programming language.

The linked (https://github.com/grame-cncm/faust) looks reasonable to me.

Chata probably needs to work out roughly what the semantics of the language should be. Its good to know what the library support is intended to be as that informs language design (assuming the library is to be implemented in chata anyway). Quite a lot of this page is about syntax.

There are some design decisions that have deep impact on programming languages. Reflection, mutation, memory management, control flow, concurrency. There are some implementation choices that end up constraining the language spec - python seems full of these.

Echoing p4bl0, implementing the language will change the spec. Writing a spec up front might be an interesting exercise anyway. I'd encourage doing both at the same time - sometimes describe what a feature should be and then implement it, sometimes implement something as best you can and then describe what you've got.

Implementation language will affect how long it takes to get something working, how good the thing will be and what you'll think about along the way. The usual guidance is to write in something familiar to you, ideally with pattern matching as compilers do a lot of DAG transforms.

- I'd say that writing a language in C took me ages and forced me to really carefully think through the data representation.

- Writing one in lua took very little time but the implementation was shaky, probably because it let me handwave a lot of the details.

- Writing a language in itself, from a baseline of not really having anything working, makes for very confusing debugging and (eventually) a totally clear understanding of the language semantics.

Good luck with the project.

Faust integration would be awesome: https://faust.grame.fr Then again we have MaxMSP, so in the end it feels kind of redundant

Csound is extremely powerful, but my favorite thing in this vein these days is Faust:

https://faust.grame.fr/

It's a functional language with a nice way of generating diagrams of DSP algorithms, but its big killer feature for me is its language bindings, which include C, C++, Cmajor, Codebox, CSharp, DLang, Java, JAX, Julia, JSFX, "old" C++, Rust, VHDL, and WebAssembly (wast/wasm) out of the box.

Have a look at FAUST as well: https://faust.grame.fr/

Once you have an idea of basic programming practice, you need to learn some DSP programming. One of the better tools for this is Faust https://faust.grame.fr/ , bear in mind this is a functional programming language, and has very different syntax to C++, but the same principles apply.