iainctduncan

I'm curious how many people have actually taken the time to compare AI summaries with sources they summarize. I did for a few and ... it was really bad. In my experience, they don't summarize at all, they do a random condensation.. not the same thing at all. In one instance I looked at the result was a key takeaway being the opposite of what it should have been. I don't trust them at all now.

Absolutely. I'm in diligence and we are hearing about attackers even laying the ground work and then waiting for company sales. The sophisticated ones are for sure smart enough to take advantage of this kind of thing and to even be prepping in advance and waiting for golden opportunities.

For a much more open ended (but advanced) option, one can run Csound live in the browser too now over WASM.

For some music ed stuff I work on, I actually have s7 Scheme in WASM controlling csound in WASM, both were surprisingly easy to get going!

Well, that's LLMs. I'm doing a PhD in computer science and music right now, focused on programming languages for music and algorithmic composition. There are other (IMHO) more interesting techniques that can be used in music and that used to be called AI, with which you do have control over and understanding of exactly what's happening, such as constraint satisfaction programming and dynamic search.

Ge Wang (professor in my field) wrote a great article on why LLMs are so uninteresting from a musical perspective. https://hai.stanford.edu/news/ge-wang-genai-art-is-the-least...

These things are the composition equivalent of Guitar Hero...

They give users (players?) a sense of agency, making it satisfying. But in reality, you're no more composing than a guitar-hero player is playing the guitar, and nor will you learn how to from doing so. No matter how sophisticated the transformations in an LLM, you're ultimately using other people's music in a sophisticated mashup game.

However, in guitar hero, the people's who's music was being used at least got royalties. :-/

Every year another famous pop star teams up with some huckster startup to tell us the same story... and every year it doesn't pan out.

my understanding from game dev friends is that's precisely what they do, no?

This reminds me of something... I'm a jazz musician when not being a coder, and have studied and taught from/to a lot of players. One thing advanced improvisors notice is that the student is very frequently not a good judge – in the moment – of what is making them better. Doing long term analytics tests (as the author did) works, but knowing how well something is working while you're doing it? not so much. Very, very frequently that which feels productive isn't, and that which feels painful and slow is.

Just spit balling here, but it sure feels similar.

HN votes say otherwise, lol

Well .... investors are funding it. Take those away and nowhere near enough people want the price on the tin.

As someone who loves Scheme (author of a Scheme exenstion for computer music, Scheme for Max), and who has done lots of Python and little Ruby, I find this odd. To me, Ruby is a much further departure from Scheme. At least in Python I can do something close to functional programming with primitives, though I don't get symbols. Ruby's "everything is an object" has always seemed to me to be even a further departure.

But then I really don't know Ruby, so happy to be told why this is wrong...

Well if you transcribed to notation, then pitch clases is trivially easy. And not really useful?

I will definitely look at this in detail. I'm doing something similar with S7 Scheme (a scheme that is heavily Common Lisp influenced), and it's working really well. Getting the plumbing going was a fair bit of work, but it's a huge win to be able to reuse my domain-code engine across the browser, C++ apps, and in Max/MSP (through my OSS Scheme for Max extension). Writing music theory related domain code is much nicer in a symbolic lisp family language than in JS.

This is a great idea. I have (deliberately) been working between 50-75% time for most of my 20 years in development. Finding places that are ok with part time is a pain in the ass on normal job boards. While I'm not looking now, I would absolutely have used this.

Did you read the article? I'm guessing not. It's a guest collaboration with a security researcher.

Why do you think this? the general state of security has gotten significantly worse over time. More attacks succeed, more attacks happen, ransoms are bigger, damage is bigger.

The historical evidence should give us zero confidence that new tech will get more secure.

Williams Syndrome is discussed in the (fantastic!) book by Oliver Sacks, "Musicophelia". It is often associated with hypermusicality, and the chapter on it is super interesting.

I work in the technical diligence space, assessing startups and (in the process) getting privileged information about companies.

This is complete and utter bullshit. What it takes to separate your company from the herd may change, but asserting that the model of selling software as a subscription service is dead is delusional.

Oh come on, it was waaay easier for beginners to set up than Java, Python, Ruby,or Perl at the time. Not even comparable.

PHP did well for ONE reason: it was really, really, really easy to deploy. This was, of course, underestimated by programmers in the know, but I remember first getting into web dev, and I could start putting real programs (!!!) on the web, in minutes!

I would say it was more like the bicycle. Cheap, no license, even a kid could be suddenly zooming around town with no ceremony, no red tape, minimal investment.

I haven't used it in well over a decade, but still remember fondly how great it was as a gateway drug to bigger and better things.

I think you mean s7, correct? it is a tiny embeddable scheme.

I do technical diligence on companies getting purchased or invested in, largely by private equity. Previous to that I was a developer for 15 years (still am, but open source now). One big one not touched on in the article is the cost of security updates. I see this all the time... companies that are in a bad position because they have too many dependencies and have wound up unable (for business reasons) to dedicate adequate resources to keeping them all current, and then end up with past EOL deps with published vulnerabilities. This – literally – costs them a lot at acquisition time. The purchaser (who is typically very risk averse) factors in all the cost to get things up to date and takes it off the price. This can be very significant. (looking at you, React et. al!)

On the other hand, I've seen companies where they used as little in deps as they could get away with, and they wind up in very strong positions. There really is a big labour cost in chasing the latest versions of underlying frameworks when those move too fast.

I believe the important and interesting take away of the paper of the paper is that so many developers thought they were going faster when they were actually going slower. This is especially striking when you consider that the study was not broad enought to capture long-term tech debt.

You are, of course, right. But my experience with comments in response to environmental impacts of LLMs here has been so negative that it feels appropriate nonetheless.

I personally do not use LLMs (knowingly) at all, largely for environmental reasons. The improvements are, to me, not worth the attrocious energy use. I will happily pay 20% or whatever more in both money and time.

I also have no interest in technology that impedes my skill development. I do not want to use anything that makes me a worse writer over time.

YMMV, I am answering the OP not evangelizing. Counter arguments will be ignored.

Check the rest of his writing, I'd be surprised if it's not covered somewhere!

The Julius Smith books are some of the most respected resources in the audio world. Here is a page linking to way more.

https://ccrma.stanford.edu/~jos/

Pure Data's UI works identically on all platforms. The others I mentioned are text languages.

If you've never used anything other than SC, it's well worth learning some others. Different paradigms make different things easier, and thus affect what you are most likely to do with them.

Personally, my axe of choice these days is running text languages from within the patchers, such as Csound in Max or PD.

Supercollider, faust, chuck, csound, pure data, common music, common lisp music, and nyquist all work on Linux. Most of the open source music programming languages make Linux a high priority!

I talk about doing this in an audio context and get met with raised eyebrows, I'd love some references on others doing it, if anyone can share!