11–20 of 30 posts
For a long long time I have wanted to do a language for programming music. I like how easy this is to get started with it almost feels like the old tracker days.
Not bad. Reminds me of Hackety Hack. Bret Victor's criticism of KhanAcademy is just as relevant here http://worrydream.com/LearnableProgramming/
really cool. nested with_synth and with_fx calls seem less intuitive than an object oriented approach, which mirror traditional circuits. (synth.connect(fx1) fx1.connect(output)). what was the reasoning behind this? i only ask because i could see it making a difference in terms of education. and, what makes this more suitable for schools than ChucK, Supercollider, etc.? that aside, i really wish someone would make a…
It's just a pity it's not cheap (around $700 to $800 for Live Studio with Max). I can see this hampering it's potential as an education tool outside of anything but specialist audio training organizations.
EDIT: I completely forgot about SynthEdit (http://www.synthedit.com/). It can export VSTs.
For a long long time I have wanted to do a language for programming music. I like how easy this is to get started with it almost feels like the old tracker days.
How is your conception of what is involved in 'do[ing] a language for programming music' different to super-colider or ChucK or puredata? Not being aggressive just interested in how you see the problem.
It feels like the PHP of music programming environments.
I am a former musician so approach music more like Sonic Pi
I mean it's this
Sonic Pi
with_fx :reverb, mix: 0.2 do loop do play scale(:Eb2, :major_pentatonic, num_octaves: 3).choose, release: 0.1, amp: rand sleep 0.1 end end
vs. super collider
// Simple synth definition using the Atari2600 UGen: ( SynthDef(\atari2600, {|out= 0, gate= 1, tone0= 5, tone1= 8, freq0= 10, freq1= 20, amp= 1, pan= 0| var e, z; e= EnvGen.kr(Env.asr(0.01, amp, 0.05), gate, doneAction:2); z= Atari2600.ar(tone0, tone1, freq0, freq1, 15, 15); Out.ar(out, Pan2.ar(z*e, pan)); }).store )
// And a pattern to play it: ( Pbind( \instrument, \atari2600, \dur, Pseq([0.25, 0.25, 0.25, 0.45], inf), \amp, 0.8, \tone0, Pseq([Pseq([2, 5], 32), Pseq([3, 5], 32)], inf), \tone1, 14, \freq0, Pseq([Pbrown(28, 31, 1, 32), Pbrown(23, 26, 3, 32)], inf), \freq1, Pseq([Pn(10, 16), Pn(11, 16)], inf) ).play )
When playing music the ability to quickly get up and running is more important than the flexibility of the system. I.e. you wanna quickly get to the point when you have fun and then you optimize later.
But don't get me wrong supercollider is a fantastic tool and was a real innovation.
Not bad. Reminds me of Hackety Hack. Bret Victor's criticism of KhanAcademy is just as relevant here http://worrydream.com/LearnableProgramming/
Sonic Pi is just that the Turtle of music programming environments. It doesn't start with abstraction but with a ground in playability.
Also have a look at http://earsketch.gatech.edu Python + music
Earlier quoted context omitted.
How is your conception of what is involved in 'do[ing] a language for programming music' different to super-colider or ChucK or puredata? Not being aggressive just interested in how you see the problem.
Getting started to begin with :) It feels like the PHP of music programming environments. I am a former musician so approach music more like Sonic Pi I mean it's this Sonic Pi with_fx :reverb, mix: 0.2 do loop do play scale(:Eb2, :major_pentatonic, num_octaves: 3).choose, release: 0.1, amp: rand sleep 0.1 end end vs. super collider // Simple synth definition using the Atari2600 UGen: ( SynthDef(\atari2600, {|out= 0,…
Would it be possible to run this under Windows? :o
really cool. nested with_synth and with_fx calls seem less intuitive than an object oriented approach, which mirror traditional circuits. (synth.connect(fx1) fx1.connect(output)). what was the reasoning behind this? i only ask because i could see it making a difference in terms of education. and, what makes this more suitable for schools than ChucK, Supercollider, etc.? that aside, i really wish someone would make a…
Live coding systems are only really good for building teeny tiny little toy automata, which usually do simple stuff with note lists, and maybe apply a bit of randomness or some simple repeating functions to a parameter or five.
Weapons-grade commercial music is much more complicated. The sounds are richer, the arrangements and mixes are immensely complex (even for simple songs), and generally there's a ridiculous amount of care and detail.
But... if you start building in machine learning, database searches, and super-complex DSP patches, and the stuff you really need to make non-trivial music, you're not really live coding any more - you're plugging pre-existing modules and data together by typing.
Also, watching people typing is kind of dull.
I think there are solutions to both problems, but REPL-music systems are only ever going to be a step on the way to them.
I'd be surprised if live coding ever makes it into the mainstream in the way that (say) eSports almost have.
really cool. nested with_synth and with_fx calls seem less intuitive than an object oriented approach, which mirror traditional circuits. (synth.connect(fx1) fx1.connect(output)). what was the reasoning behind this? i only ask because i could see it making a difference in terms of education. and, what makes this more suitable for schools than ChucK, Supercollider, etc.? that aside, i really wish someone would make a…
There's a basic problem with live coding, which is defining the problem domain. Live coding systems are only really good for building teeny tiny little toy automata, which usually do simple stuff with note lists, and maybe apply a bit of randomness or some simple repeating functions to a parameter or five. Weapons-grade commercial music is much more complicated. The sounds are richer, the arrangements and mixes are i…