>Ableton and Max are totally separate codebases, and "Max for Live" is just a ~VST interface between them.
This is not strictly true, and Max for Live (M4L) is much more than a pseudo-VST. In the context of Live, the Max runtime is controlled by the DAW, which itself then exposes part of its interface to Max. So there's realtime bi-directional communication going on, more akin to how Propellerhead Software's (now deprecated) ReWire protocol used to work, the host passing control information (transport position, note data, etc.) and audio buffers into the client software and vice-versa. There is some superficial similarity with VST in this sense, but with M4L it's much more deeply integrated into the DAW as a whole. The Live Object Model[1], while not complete, is extensive, and there is very little that is off-limits to a M4L device to manipulate, with the caveat that care must be taken to avoid overflow of the control stream coming back from Max into Live (certain operations must be placed in the low-priority scheduler thread).
This new API gives much of the same control that M4L already did, but without having to have Max involved.
>In Max, you have to build everything from scratch, every time.
Again, not strictly true. Editing a M4L device opens the full Max environment, which has a snippets[2] feature much like any other good IDE. You can easily build a large library of boilerplate code for your own specific purposes with it. There are also many basic examples included out of the box.
The visual patching part of Max makes sense when you know the history of the program. It was built for musicians working at the forefront of interfacing MIDI with the power of the more compact mainframe computers of the day (PDP-11 IIRC). The 'programming' was done through a GUI running on the first Macintosh. At first there was no audio processing in Max itself, it was purely for generating and manipulating MIDI data.
You can see this 'bare-bones' style of Max with Miller Puckette's continuation of his original work in Pure Data[1] (aka Pd). The nice thing about Pd is that it's open source, so all the scheduling and signal flow logic can be examined and understood. As I understand it, the basics of Pd are comparable to how Max still works under the hood, though no doubt there has been some deviation over the years.
As it is now, Max offers a very smooth interface to the basic paradigm that was established 40 years ago, with many modern advances, but the fundamental idea hasn't changed all that much since it first came out.
If you really hate having to work through a GUI for computer music there's always SuperCollider[2] and its many derivatives (Sonic Pi, TidalCycles, etc.). It's nice to have options!
Max itself can be manipulated through JavaScript. You can dynamically create and connect objects in it, set scheduler tasks, etc. Max goes a lot deeper than wiring some GUI boxes together.
There's a big caveat there though that is widely misunderstood. Max has separate scheduler and UI threads. JS only runs in the UI thread, and thus cannot be used for reliable timing tasks - timing will seem to be ok until there is load and than the UI thread timing is out the window.
One of the main reasons I wrote Scheme for Max (S4M) was to enable tightly timed scripting. You can pick which thread an S4M instance runs in, and each instance is totally isolated, which is very different model from the Max js objects (including the new V8) one. Those are global and only in the UI thread. S4M works very well for this, I use it in Max for Live and can get it synchronized perfectly underload with other sequencers.
I started scripting max with JS and built Scheme for Max after banging into its limitations. My typical workflow is a mix of Max, Csound in Max, Gen and Scheme, with the fast majority of the work happening in Scheme.
Well, it's obviously not intended for realtime 'live coding', but as an answer to the problem of dealing with the GUI and manually cabling a patch up it suffices, though it does help to be fairly conversant with the basics of Max to begin with. For instance I've used JS to auto-populate a patch where the number of abstractions isn't known in advance and may need to change, with each abstraction then getting its own settings passed as generated arguments. It could be a nightmare cable spaghetti patch but JS made it end up very neat and tidy.
IMO there are far better options for realtime code-generated music. Max does what it does well, and shoehorning in interrupt level scheduling for scripting on top is out of scope for its remit.
Doing interrupt level scripting in it works just fine - lots of people have done it in C, C++, Scheme, and other extensions. I take it on stages and have produced music with it extensively. Scheme for Max is written using all the same C primitives from the Max SDK that the other Max sequencing options use and has been load and timing testing exhaustively.
I'm currently a PhD candidate in it, have previously used Csound, SuperCollider, Max, Pd, Common Music, and others, and have published/presented at conference on this topic. Of everything I've tried, I prefer working in Scheme in Max over other options. It is definitely practical and accurate. (Though in Scheme in Pd has soe nice features too!)
Can your external place objects and route cables around on the patch? That's the main thrust of my original comment, which is that JS scripting can help avoid having to patch lots of objects together in the GUI. Live scripting music is beyond the scope of my advice.
You specifically brought up "scheduling tasks". There is a JS task scheduler, but it comes with a caveat - the scheduled timing is accurate but the time of executing is not accurate because it runs in the UI thread. Hence my comment.
If you want to schedule tasks in Max accurately with code, you can either use Max, C extensions, or my extension.
yes, you can do patcher scripting from S4M as well as you can easily send messages to named objects, which is all you need in order to be able to do that. That is how max patching works - whether you do it in the GUI, JS, or messages to the patcher, the whole thing is just objects sending messages to other objects, and the patch is just a connected graph of references of instantiated objects. If you send message to a thispatcher object, you achieve the same thing under the hood as manipulating the GUI or going through JS. You can read about it if interested in the Max SDK documentation and in the Cipriani & Giri books on thispatching.
This blog post is highlighting their specific contribution to the UK government's open consultation[1], not a general call for sanity. There's a link to their open letter at the end of the piece. No doubt they will write other authorities when the need arises.
FWIW I absolutely love how 'no-frills' PG is compared to so much of the bloated, over-engineered, script-riddled web these days. Please don't ever change that!
For me, the point of making music is making it myself. If want to have something done for me I could just play someone else's record and pretend like I made it.
When we recently added MCP to Ardour (a cross-platform FLOSS DAW), the goal wasn't to get the machine to make the music for you, it was to provide alternate ways of interacting with the DAW (particularly for those with visual impairments that make voice control preferable).
The is the age-old music parochial thing. "Oh, he's just in a cover band, he doesn't write anything" / "Oh, she's just a composer, she can't even play the stuff she writes" / "Oh, he writes and plays his own stuff but knows fuck all about theory so it's not real music" / etc.
Me, I'm having a blast with claude code, MCP, and Ableton. I'm directing harmony and asking for arrangements and variations in rhythm, mixing, and production. Don't know if that counts as "making it myself", but then I was writing music before I could actually play any instrument at all, so :shrug:
I think there's a way to define it without it either side feeling personally attacked. One of the things I like about using agents for programming is that if the spec is detailed enough, I can implement it in a number of different languages and still get the thing I intended. That means that the "art" is in the spec, not the implementation.
I think the question with AI in music is when it gets to that point. What's the musical spec? What's the implementation? If the spec is supposed to be the pure distillation of my intent, then shouldn't that mean each time I engage AI to "implement" the spec, the musical output of the AI should be the same?
At that point I'm all in favor of using AI for music. But when AI is used to replace a specific intent with vague intent, that's where I feel like something is lost in the human experience of human-created music.
Previous generations might have said the same thing about Ableton itself, vs playing a physical instrument. In that regard, AI might become just another power tool for creative expression.
I’ve always said that the more divergent the input is from the resulting output, then the less personal expression you have. For me, in order of moving away from meaningful control in generative models, it goes: “text → code,” “text → picture,” and, at the very bottom, “text → music.”
For me personally, music composition begins and ends with the motif - the melody itself. It’s the part I enjoy the most, and it’s also the part I have the most individual control over since I can sing.
Everybody makes music differently, but if you lack the ability to play an instrument and you also can’t whistle or sing, it’s hard for me to imagine how you’d have any meaningful control over the melody.
How would a non‑musician express an actual melody that they came up with (beyond simple things like instrumentation and general “feelings”) in text? RED RED RED BLUE. (Sorry couldn't resist a Mission Hill reference here.)
With all that out of the way, there's still lots of room for using AI in music. I’ve used it to take some of my existing songs, mostly pianistic in nature, and swap out instrumentation and arrangements just to play around with different soundscapes. It's like BIAB on steroids.
Agree to some extent. At some point though we jump the thin line between creative expression and… magic?
Like if at some point I can just say “Generate a song similar to Smooth Criminal, different enough to not trigger copyright claims” and it just works, and everyone loves it… well is that creative thinking?
I think you can quantify the amount of creative expression you engage in by looking at all the decision points in the creative process where you are directly involved in making the decision. For an LLM prompt, that is going to be fairly limited by definition. I suppose the quality can be measured then by how novel and effective the output/approach of each decision is then, how much impact is made.
The amount of creative expression does not necessarily correlate with impact. Something can be created with nearly zero creative expression, that ends up making a significant impact. In that case you are more of a director than an artist I suppose, in that you direct the high-level process and only make decisions there. You can call it creative thinking in the same way a good businessman makes smart high-level decisions and then delegates what is downstream to others, with decisions being optimized for impact.
I think you can be creative "within a frame" in that sense, e.g. creative in the way you wield an LLM for instance, which is on a different scale compared to being creative on the piano roll with how you organize and brainstorm your melodies. It's just a different skill set at a different granularity altogether. But the one thing that I think holds, is that higher level methods have less creative expression by definition, because you are delegating more decisions to other faculties; you are seeing less of the "creator" in the work.
I think there is something to it. First, it would still need to be different enough from Smooth Criminal to avoid listeners just going back to the original. Then, if anyone could just type a simple prompt like that and get a hit, wouldn't we be flooded with 'sounds like' singles, which would turn the audience off of those, and now, you're not making hits...
I think there will always be more to it then just a simple prompt, but having the vision to make a song that sounds pleasing, and unique enough is certainly creative to me.
Of course, there's also a huge demand for generic, inoffensive music (think theme/intro songs, waiting room and elevator music). If we could make that more enjoyable to listen to, would anyone care if that's not creative thinking?
You could make (and many do) the same arguments over covers of songs, even when the covers end up eclipsing the original. Where was the creative thinking in that?
> AI might become just another power tool for creative expression
It is NOT a digital tool to create art. Yes, people used to be snobbish about digital art. Some still are. This doesn't say anything about generative AI because that isn't a tool.
The closest equivalent is hiring someone on fiverr to create music for you and claiming you created the music because you wrote the "prompt".
There is nothing creative about using generative AI. Is is a form of management. The difference is that instead of extracting labor directly your are extracting dead labor from the million of artists whose work was stolen to train the AI.
I don't disagree if its building the whole song, but given that this is tooling within the DAW, if an artist went in and said 'give me 5 alternative reverb sounds on this track', is that not using AI as a tool? Yes, the AI is creating the sound profile, but is that any different then using presets, or samples?
I used to play around for days just making sounds on my synth. The process of creating them was often just turning random knobs and dials. If the AI is turning those for me, thats not a tool?
> I could just play someone else's record and pretend like I made it
How many "DJs" today could even find two records that they could key and beat match? Then physically mix them on the turntables with no software or sync buttons? AI is just going to make this worse...
A lot of them. The barriers to entry have been lowered, which also means there are way more DJs around. And some of them will start to expand their horizon.
I don't know, but I would not be surprised if the total amount of people who can mix without sync increased. Though the percentage of DJs who need sync is probably higher.
I started DJing with 'rona and now somestimes mix vinyl. And I also hosted open deck nights with CDJs where a lot of beginners did not use sync, unless they where only a few month into the game.
I get why people make gut statements like this, and to me something does feel different about AI.
But I realize I have not seen any criticisms of AI generated music that are meaningfully different from criticisms I've heard of other advances/changes in music technology, whether performance or recording.
Sampling, scratching, drum machines, autotune, electric guitars even.
The main unconsidered criticism that used to come from old-school musos was that 'you press a button and the synthesizer/drum machine/whatever does it all for you'... Only now is that perhaps coming to be true.
There's a difference between technology/technique that adds a new sonic palette to the canon, and one that takes away the necessity to have any direct input in the process of production. I guess we'll find out which this is if there's a wave of novel AI assisted genres that emerge, or not, as may be the case.
Well in "traditional" music production every individual component of a song has the creative intent of the artist in it. With AI you have no idea if there is any intent or if its just something an LLM spat out.
If all you care about is the raw sound file created and you don't care about the connection you might feel with the artist behind it then maybe intent isn't relevant to you.
Each genre has a fairly tight envelope within which to operate. Regardless 90% of tracks never make it to the finish line because hobbyists haven't learnt them well enough to groove them out. If with a little help these tracks were all finished then bedroom producers will over time learn what works and be able to explore more.
I think the parent comment was saying that the problem is not quantity, but quality.
Warping my mind back into a hobby-enthusiast music producer mindset:
an MCP that generates presets for a limited pipeline with many sweet spots sounds... interesting?
To me, the idea of being able to have, say, a chain of a simple VA synth + delay + compressor and a very simple step sequencer, combined with prompting and a genAI model that spits out patches, sounds very endearing and interesting.
Much more interesting than Gemini or Suno for example.
Depends on the training and input space of course.
I deliberately described a limited setup, the controls of which could be described in less than a kilobyte.
Many dance music synth patterns could be described by simple means (tracker/step sequencer, looping, a few knobs).
That's what makes a lot of music interesting.
I can easily imagine a producer creating very individual and interesting output by unleashing the right models.
I think, just like with human producers, constraints liberate.
An AI controlling a very limited synthesis chain is more interesting than a very complex synthesis chain controlled by a human with no musical "vibe".
I agree! I made this mostly so I could stay in the flow more in Ableton without getting lost spinning knobs and pressing buttons. Although I do enjoy spinning knobs and pressing buttons.
With this I can keep my hands on my keyboard or guitar and direct Codex to make a quick backing track.
I will caveat my first comment by also noting that I am well versed in computer music history, and read many many papers in CMJ[1] and elsewhere about generative and automatic composition tools such as Emily Howell[2]. I do NOT have a problem with generative, algorithmic and automatic composition in this sense, as an extension of the creative intentions of the human composer, in the right context. See also Autechre[3] for what can be done with Markov chains and good taste. What we are discussing here is the musical equivalent of a dishwasher.
Addendum: I would highly recommend the Margaret Boden book referenced in the wiki on David Cope/Emily Howell, which is an absolutely fascinating read and was incredibly far-sighted in its enquiries on this topic.
It'd broadly sad how folks so broadly slight and disregard novelty, are so quick to judge assume & discredit.
I have such respect for those who can do the good work of comments like your, trying to pry the closed mind open just a little more. This is such an essential outlook basis that needs to be taught, reinforced: a sense of exploring potential progress rather than sinking merely to conserving or out grouping or denying.
It's really cool that the human agency loop is improving. Ableton & DAWs should be so much better with expanded more language native interfacing!
Can I ask what the specific markers / qualifiers are for you to consider (let's call them) 'classical' generative and algorithmic techniques fair game in creative composition, but LLM agent based techniques not so?
To me, it seems like the "do it for me" aspect is similar, just at different levels of abstraction.
Firstly, they all came to the use of those techniques after having been through years of work the 'hard way', often being able to play to a conservatoire standard, and had a very extensive grounding in the tradition that came with that. Then they owned* or designed the thing they were asking to 'do it for me' and could modify it at their discretion, effectively making it an integral element of the composition. The prior training was crucial in getting anything good out of any of it IMO (high level reflection based on canon knowledge and deeply considered personal sensibility, etc.)
* I suppose in the early days, running on an mainframe would belie the definition of ownership per se, as it required access and was limited to that specific machine/institution, but then we are talking about a time where personal computing wasn't available.
Thanks for your well considered response. I disagree with the notion that extensive classical training is required in order to make beautiful, noteworthy music. There are innumerable counterproofs of this in every era of music. I also disagree that fully and deeply owning/designing one's tools is required - though I understand that we are more specifically talking about generative tools, I personally argue there's not enough meaningful distinction. One chooses to exercise intent, whether the tool is acoustic or digital, general or hyper-focused. And fully understanding the workings of every tool is a fool's errand in this modern age.
Whether these then extend to AI and LLMs I still can't fully say. There is, obviously, some kind of qualitative leap here. I'm not fully settled.
But I guess I lean more towards - it is a tool, let people use it to make their own beauty.
I didn't specify that the training had to be a classical, conservatory, background. It was only mentioned with regard to the background many of the original computer musicians came from, and which is understandable considering the era and situation of computing back then. Autechre are a good counter-example of that, which I have noted above. Two hip hop heads from the north of England, who have made some of the best contributions to electronic/computer music in recent decades. As you point out, there are loads more, not worth making a list here. Though I will still assert that I am yet to hear any good music come from someone who has anything less than a developed knowledge and passion (obsession?) for their area of interest, be that classical repertoire or drum and bass.
I wonder how one is supposed to exercise intent when the tool in question is specifically designed with the purpose of removing your ability to have direct influence on the result it produces. At best we get curation/collage, which in itself is no big change from the way things have been for decades (sample packs, premade loops, and going back further, sample CDs, for instance), but what goes away is the human touch.
The main difference is tweakability: With classical generative and algorithmic composition, the human can change parameters in real time and more closely guide the shape of the piece.
This is not strictly true, and Max for Live (M4L) is much more than a pseudo-VST. In the context of Live, the Max runtime is controlled by the DAW, which itself then exposes part of its interface to Max. So there's realtime bi-directional communication going on, more akin to how Propellerhead Software's (now deprecated) ReWire protocol used to work, the host passing control information (transport position, note data, etc.) and audio buffers into the client software and vice-versa. There is some superficial similarity with VST in this sense, but with M4L it's much more deeply integrated into the DAW as a whole. The Live Object Model[1], while not complete, is extensive, and there is very little that is off-limits to a M4L device to manipulate, with the caveat that care must be taken to avoid overflow of the control stream coming back from Max into Live (certain operations must be placed in the low-priority scheduler thread).
This new API gives much of the same control that M4L already did, but without having to have Max involved.
>In Max, you have to build everything from scratch, every time.
Again, not strictly true. Editing a M4L device opens the full Max environment, which has a snippets[2] feature much like any other good IDE. You can easily build a large library of boilerplate code for your own specific purposes with it. There are also many basic examples included out of the box.
[1] https://docs.cycling74.com/apiref/lom/
[2] https://docs.cycling74.com/userguide/snippets/
reply