Hacker News Reader

Hacker News

Comment by chaosprint | Hacker News Reader

Full thread

chaosprint

If you are interested in code-based composition, try my project:

https://glicol.org

I am still working on the composition system, together with many other stuff

here is an example of Kraftwerk:

https://glicol.org/demo#themodel

View on HN

What I really want to see is a music programming language that does not require elementary knowledge of trig. In fact, I don't want it to use any numbers at all.

They all do: Faust, Impromptu, ChuCK, csound, SuperCollider, etc., etc. I suppose that by itself should convince me that there's no other way (there are things like Orca, but I'm thinking of things that look more like conventional programming languages).

I seldom think about numbers when I'm programming a synthesizer -- I just turn this knob more this way or this slider down a bit. Why can't a music programming language be more . . . gestural? Not sure what the right word is. I want the benefits of a textual programming language, but I don't really want to have to start thinking about sound waves in terms of literal numeric frequencies, particular since I really don't do that while doing sound design.

I don't meant to pick on your project in particular; it looks really cool. But since you're writing one of these, perhaps you can answer my question. Why do these languages ask synth programmers to think in terms of precise numbers when programming an "actual" synth isn't really like that at all?

TidalCycles doesn't. And you can try it online without installing anything.

https://strudel.cc/

Try evaluating `d1 $ s "bd sn"` to get a bass drum-snare drum rhythm going. Then `d1 $ s "bd*2 sn"` to kick the bass drum twice each loop instead of once. It can be extremely intuitive.

Doesn't what? Doesn't use numbers?

  scale(scales)
  .scaleTranspose("[0 <2 4>]*2")
  .struct("x*4")
  .velocity("<.8 .5>\*4")
  .velocity(0.8)
  .slow(2)
  )
  .fast(1)
  .note()
  .clip("<.4 .8 1 1.2 1.4 1.6 1.8 2>/8")

Require trig.

> I want the benefits of a textual programming language, but I don't really want to have to start thinking about sound waves in terms of literal numeric frequencies

That's a bit of a contradiction. It's exactly the reason to use a programming language to have that level of control over signal processing. Otherwise you're better off with a tool like Reactor or VCV Rack.

What about Orca?

https://100r.co/site/orca.html

Esoteric visual music programming language that uses a 2D grid of operators.

Orca is explicitly mentioned in the comment to which you are responding.

oops!

Because it's a text interface, not a gestural interface.

If you really want a gestural interface you can add it to any language that supports for MIDI control, or some other hardware connection option. (UDP, etc.)

The gestural part is trivial, just as putting a knob on a synth is trivial. The hard part is getting the knob to do something,. Which is not trivial at all.

In fact it's impossible without using numbers somewhere in the make-it-work chain. They may be a few levels down, but they're always going to be there.

I'm not suggesting that we banish numbers from the entire stack. I'm asking why they are absolutely necessary for a textual interface in this domain -- to the point that, as someone says below, it is a "contradiction" to suggest otherwise. As if there's some sort of impassable gulf between csound and VCV Rack.

Let's talk about LaTeX this way. Suppose LaTeX required everything to be specified in explicitly numeric terms. I find this sort of tedious, and I start asking why we can't just express the idea that things be "centered," or "justified," or "kerned" or "Large(r)," or "ragged right."

Would you really say that I am speaking in terms of contradictions? That what I really need is Word, that I must not understand the difference between a textual language and a gestural one, and that the only reason to use a textual language is precisely so that I can have precise control over these matters?

What I'm really asking here is whether we are really talking about the hard limits of programming languages, or if we are instead talking about a certain lack of imagination among programming language designers in this space?

Maybe some constants or enums to give names to specific numbers.

let CENTERED = 0; let JUSTIFIED = 1;

I think what you are asking for is for an abstraction layer that is on top of what the current systems do. LaTeX is a very good analogy, as it is a set of macros that hide away the numericity of the underlying TeX typesetting system. Once upon a time people did use TeX to write papers because LaTeX did not exist yet.

Such a higher level macro system must make tradeoffs between sufficient control and conciseness (though its typically possible to insert low level code in between the macros since before any macro can be executed, rendered etc. it must be converted to the lower level anyway).

Developing such a system is probably a task for tech-savvy musician rather than a music-savvy techie. Its value proposition would be precisely to crystallize composition "invariants" that are expressive and versatile enough to enable people to compose genuinely new things.

But you should keep in mind that all LaTeX papers look a bit alike :-) (though much better than Word papers).

> does not require elementary knowledge of trig

As math fields go, trig is fairly easy. The part you need to understand for music is a nicely-delimited chunk that you can learn quickly. I find it very rewarding as a way to think about music; you might too.

(I'm not talking about Fourier transforms; just basic trig.)

this is an interesting point.

I would say live coding opens many possibilities, for example this one:

```

a: sin 440 >> mul 0.1

b: sin 441 >> mul 0.1

```

and you can use a loop to create 100 sine oscillators with random frequency

it's totally different from a physical synth

also there are tons of variation in terms of "patterns" for sequencing

just a unique feeling

I agree. When possible/working with sound, I would take a tactile experience (right-brain/feel?) over a mathematical/analytical experience (left-brain/logic?). I also don't know music theory and I haven't dedicated time to learn math, so I lean on my intuition more than anything.

Sonic Pi binds MIDI codes to symbols like `:a4` for their corresponding note names, if that helps. It's not comprehensive -- there are no entries for doubled flats/sharps, for instance -- but you can write basic chords/melodic lines with a pretty limited need for numbers.

You'll still need some for `sleep` (or `play_pattern_timed`), but if we're being pedantic about it, note lengths are already numbers as is.

You are looking for what we call an "algorithmic music language", where the focus is on manipulating symbolic music representations rather than digital audio.

OpusMondi is one of these. Others include my project (Scheme for Max, mentioned elsewhere at top level of the thread), Common Music, OpenMusic, etc.

Visual options include Max and Pd, which have an entire message/event layer that does not have to be used for digital audio at all.

All of these can output to standard synthesizers if the digital sound part is not your interest.

Music is numbers. Musical instructions that don't use numbers seem as feasible as architectural plans without measurements -- which is to say, somewhat, but impossible to do precisely.

(Music notation might not have explicit numbers but it's got stand-ins for them.)

What's the core benefit in comparison to all the other existing open-source audio/music programming environments (https://en.wikipedia.org/wiki/List_of_audio_programming_lang...)?

Glicol has a synth-like syntax, trying to balance the simplicity and readability needed for live coding music performances.

This syntax is also deeply integrated with the customised audio engine under the hood. And this audio engine can be used as an independent Rust audio library.

You can also use Glicol's DSL in Rust projects.

There are many use cases in this YouTube channel, such as Glicol running on Bela, functioning as a VST, and as a CLI tool:

https://youtube.com/playlist?list=PLT4REhRBWaOOrLQxCg5Uw97gE...

But all in all, I just feel comfortable coding with it for experimenting sound design and improvisation.

cool, thanks.

Something I noticed about all these projects (and they are quite a few) is that they are quite old (some going back ~2 decades or so).

I wonder what is the dynamic behind that longevity. Music hasn't changed ofcourse but on tech side I would think there are significant new possibilities.

Is it something related to the difficulty of implementing low level algorithms (famously a lot of linear algebra stuff goes back decades and rests on C / Fortran libraries). Is it that there isn't enough interest to justify new efforts or are those systems already near "perfection"?

> some going back ~2 decades or so

Some indeed started long ago; e.g. Common Music had its roots in the eighties and became a pretty popular composition environment during the nineties; in 2008 there was even a fundamental redesign and it's still developed. But there was also a certain abundance of new tools; many were released that essentially had the same goal and offered the same features, just implemented a little differently.

> Music hasn't changed ofcourse

Music and the way music is composed, produced and consumed has changed tremendously over the years, and so have the tools. In the past the focus was on algorithmic composition, and tools allowed to extend the possibilities of a composer also to sound design, but it took years until computers were fast enough to render a composition in real-time. Then came the time of the DAW's when eventually everyone could produce music with little investments. In the last ten years live coding became popular which is yet another way of composing and producing music, with new requirements for interactivity and ergonomic efficiency of the tools, and yet a different view of the composer and the composition process.

However, and this is something I wrote about recently in my thesis, we are now experiencing somewhat of a renaissance of older approaches as it is only fairly recently that it has become practical to run the older (lisp-based) algorithmic tools in real-time. I can run Scheme during live playback and have the GC finish it's business fast enough to use it with very acceptable audio latencies within Ableton Live for example. I'm just now embarking on a PhD in this area actually, and its pretty exciting how many previously dusty things can be used in exciting new ways.

I discuss this a bit here: https://iainctduncan.github.io/papers/introduction.html

Thanks for the thesis; looks interesting, will have a close look at it. Actually, I'm not really sure whether "Lisp has always been an elegant and productive way to represent and build music"; from my point of view the optimal way to represent music incorporating all relevant dimensions and relations has yet to be found; actually Dannenberg himself switched to SAL, away from Lisp (see his algorithmic composition book).

What's the topic of your PhD? Who is your supervisor?

Well, Dannenberg's SAL is really a sugar layer over XLisp though right? I remember citing his writing somewhere from the book with Simoni on why Lisp is great for music. My impression was that SAL's raison d'etre was to be more accessible to people for whom lisp is too weird than anything else, but perhaps I am not completely correct.

My PhD is an interdisciplinary between music and CS, working with George Tzanetakis and Andy Schloss at University of Victoria in BC Canada, continuing the same work I did for the Masters. So that is Scheme for Max and other Scheme related music work, targeting algorithmic composition, mainstream production, and live coding contexts. Some of the current initiatives include a browser based Scheme algorithmic music system (not yet published, but using a WASM C++ worker for a sample-based scheduler), further work on s4m, s4pd, and Ableton Live tools, integrations with Csound (I wrote the csound6~ port for Max), likely a standalone host (similar to Grace), an object system and score tool, and some actual music!

(EDIT: I was wrong and thinking Nyquist, not SAL!)

> Dannenberg's SAL is really a sugar layer over XLisp though right?

SAL was designed and published in 2008 by Rick Taube; the present implementations are transpilers to Scheme or XLisp, but SAL is quite different from both Scheme and Lisp (in syntax and semantics).

> My PhD is...

Sounds interesting; but what is the actual research focus (besides the programming work and tool implementation)?

Ah right, typed too soon, I was thinking of Nyquist, which is over Xlisp. YMMV, but for me personally I find Lisp much nicer to represent music than SAL.

My PhD is interdisciplinary, so it is not a pure research CS - it's a combination of CS work, project work, and music composition & performance. The research side will be into how Scheme and recent developments in the Scheme side of PLT can be used in modern machines/environments for exploring algorithimic composition and live-coded composition and improvisation.

> I find Lisp much nicer to represent music than SAL

Lisp and Scheme are indeed very flexible to represent about anything, but on a very fundamental and general purpose level; of course you can do some kind of "DSL" with macros, but it's still "Lispy". SAL has less degrees of freedom and helps users not to get lost or bogged down, but it's still a general purpose programming language, not a specification system covering the essence of musical structures and processes.

> My PhD is interdisciplinary, so it is not a pure research CS..

Here in Switzerland "interdisciplinary" means that the research topics concern more than one research area, not that it's not pure research. Usually the PhD students are more challenged than with a "traditional" PhD, because there are more professors involved, each with his own research focus, that is most important to him (so it happens that the student does actually work for more than one PhD).

Concerning Scheme, depending on how big the "composition" is and whether it does sound generation and has to be controlled in real-time, a traditional byte-code interpreter will likely get to its limits, even on present HW.

Well sure, you can bring any real-time sound system to its limits if you want to - some of my additive synthesis experiments do that very quickly even on pure C++.

But as far as practical use goes, I run 16 algorithmic sequencers implemented completely in s7 in real-time, inside Ableton Live, at an output latency of 8ms, and do so for long enough for compositions. This is while Live does a ton of software synthesis and FX dsp too, and all of the sequencers can be altered on the fly without audio dropouts! This is on the cheapest M1 you can get too. So it's absolutely practical for real time work. This is also without even a ton of attention to real-time GC in s7 - I haven't dug into that yet, but Bill has told me that while he did a lot of work to make it fast, it doesn't use an implementation specifically targeted at lowest possible pause times.

Whether the tradeoffs of Scheme vs other options are worth it for a particular composer/producer/performer varies of course, but it really is time to put to rest the notion that we can't run a Scheme interpreter for real-time music generation.

Blinking cursor. Full stop - can't use. But thanks for building it, anyways.

That's so racist.

Huh? How come?

It just seemed like a funny way to mislabel something that to me is, sincerely, a strange if refreshingly naked form of bigotry. What's wrong with blinking cursors? They're so easy to find.

I see :-)

Well, it's not that I have anything against blinking cursors, nor I'm trying to infringe on their rights. Rather, it is that seeing the cursors blinking kind of freezes my brain. I simply cannot code if the cursor in the editor is blinking. It's a common problem[1][2].

[1] https://jurta.org/en/prog/noblink [2] https://www.justanswer.com/neurology/j0wg1-team-started-issu...

Reply on news.ycombinator.com