Discussion:
Research and training materials for live coding
ddw_music
2014-06-18 12:41:10 UTC
Permalink
Hi -- I'm inching my way back into the SC online communities, for now as more
of an asker than answerer. It's been very helpful to relieve myself of the
(self-imposed) pressure to answer questions just because they're there.

Now I have a question. I started playing with JITLib while preparing for a
workshop, and that led to some experiments with live coding. I ran into some
challenges with that pretty quickly, and I think they're the sorts of
challenges that more experienced live coders have already dealt with. The
main one is expressing control routines (sequencing) efficiently. I'm good
with patterns, but... they're a lot of typing when an audience is waiting
for you to do something cool. And that was even using Pbindef to build up
the complexity item by item.

I'm wondering about research and training materials. Like, my conservatory
department also houses the jazz major, and the students learn improvisation
from teachers and from established workbooks. But if I want to learn to
improvise in code, I feel like I have to be an auto-didact, figuring
everything out for myself even though other people figured it out before me.
I'm fully aware that nobody gets good at live coding without individual
practice, but continuing the jazz analogy - the teachers at my school give
the students skills to practice, and practice methodologies.

I had a quick look at the toplap wiki, but didn't see much in the way of
research papers explaining solutions to the (thorny) problems of expressive
but compact code. I did see the page for practice exercises, but it seemed
to me these are intermediate-level, and when it comes to live coding, I'm
very much a beginner.

Thanks,
hjh



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Cole Ingraham
2014-06-18 13:30:41 UTC
Permalink
Hi James and welcome back =).

While I don't know about specific educational resources for learning live
coding, I have been exploring it myself quite a lot: especially over the
past year-ish. I certainly echo your concerns about feeling not wanting the
audience to sit and wait while you figure out how to make something happen.
Here are some of my thoughts and approaches (whether anyone finds them
useful or not). I'm also hoping this spawns a larger discussion on the
topic since it's something that seems to have growing interest.

"All out live coding" is really hard. Yes there are some insanely talented
ninjas with 9000+ wpm that can make some amazing things happen from an
empty file, but for the rest of us I recommend having a handful of starting
code. This could be skeletons of things, complete code that you intend to
extend/tweak, infrastructure for effects, whatever is appropriate. If
anyone complains about that, tell them to go live code in Assembly.

Since you brought up jazz and conservatory training, regular practice
helps. Also having some general idea, goal, form, timbres, etc. in mind is
quite helpful, as with all music.

One big issue is the amount of typing needed to make something happen (as
mentioned before). Even if you have some prefab code ready, navigating and
editing it can be rough. I switched to vim for my live coding work (emacs
is just as suitable to *hopefully* prevent a flame war from bringing up
vim) because I found it far easier to get around, and really like some of
the customization that the IDE just doesn't have (yet).

That still doesn't change how much typing you need though. SC, which
totally awesome and crazy powerful, is rather verbose when it comes to live
coding. If you look at other live coding languages (ixi, tidal, lich) they
are built from the ground up to be the shortest distance between thought
and compile (with the trade off of plenty of flexibility but that's part of
the deal). I've been hacking on an utility to make Pdef feel a little more
like these languages if you are interested:

https://github.com/coleingraham/sc_utils/blob/master/algorave/SymbolToPdef.sc

This is still very rough but I have performed with it. The idea is that I
add methods to Symbol to replace a lot of the extra typing of Pdef and
Pbindef. Here's an example

// the following both produce the same Pdef
(
Pdef(\example,
Pbind(
\instrument, "default",
\dur, Pseq([1,0.5,0.5],inf),
\degree, Pseq([0,2,4],inf),
\amp, Prand([0.25,0.25],inf)
)
);
);

Pdef(\example).play;
Pbindef(\example,\dur,Prand([0.25,0.5],inf));
Pdef(\example).stop;

(
\example +> (
inst: "default",
dur: [1,0.5,0.5],
degree: [0,2,4],
amp: Prand([0.25,0.25],inf)
);
)

\example.play;
\example.set(\dur,Prand([0.25,0.5],inf));
\example.stop;


It's a small difference but ends up being on average 30% less typing. This
somewhat assumes you will be using lots of Pseq but that's not a
requirement. Things just start looking much more like a normal Pdef if you
want to do other things.

That's all I've got for now.

-Cole
Post by ddw_music
Hi -- I'm inching my way back into the SC online communities, for now as more
of an asker than answerer. It's been very helpful to relieve myself of the
(self-imposed) pressure to answer questions just because they're there.
Now I have a question. I started playing with JITLib while preparing for a
workshop, and that led to some experiments with live coding. I ran into some
challenges with that pretty quickly, and I think they're the sorts of
challenges that more experienced live coders have already dealt with. The
main one is expressing control routines (sequencing) efficiently. I'm good
with patterns, but... they're a lot of typing when an audience is waiting
for you to do something cool. And that was even using Pbindef to build up
the complexity item by item.
I'm wondering about research and training materials. Like, my conservatory
department also houses the jazz major, and the students learn improvisation
from teachers and from established workbooks. But if I want to learn to
improvise in code, I feel like I have to be an auto-didact, figuring
everything out for myself even though other people figured it out before me.
I'm fully aware that nobody gets good at live coding without individual
practice, but continuing the jazz analogy - the teachers at my school give
the students skills to practice, and practice methodologies.
I had a quick look at the toplap wiki, but didn't see much in the way of
research papers explaining solutions to the (thorny) problems of expressive
but compact code. I did see the page for practice exercises, but it seemed
to me these are intermediate-level, and when it comes to live coding, I'm
very much a beginner.
Thanks,
hjh
--
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.
_______________________________________________
sc-users mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
--
DMA Music Composition - University of Colorado at Boulder
MFA Electronic Music and Recording Media - Mills College
BM Music Composition - University of the Pacific

http://www.coleingraham.com
http://www.glitchlich.com
https://soundcloud.com/coledingraham
http://www.facebook.com/coleingrahammusic
joesh
2014-06-18 14:53:07 UTC
Permalink
Interesting remark. I'm coming at this from the other side as a 'jazz
musician' who interested to integrate live coding into my work. I've also
started looking into the idea of building a syllabus which takles this and
can be taught in a conservatory. There are, as I'm sure you're aware,
several conservatories teaching coding (or sonology as it's called over here
- I'm in the Benelux), but often it's taught as a harmonically static
process, which as you well know jazz isn't.

I'll be interested to see/read what others have come up with, but at the
moment I'm only learning SC, so i can't really make any solid remarks as
yet. Unfortunately as with other programs - PD, Csound, Usine or the like -
there isn't any scope for moving quickly through harmonic space, beats are
easy, syncing tempos with a live drummer surely a slight problem.

Lastly as you point out your not sure what methodologies to use as jazzers
have now a complete 'workbook' technique they can build from. I guess that
until more coders work in shifting harmonic areas and less in ostinato based
riffs there will be little progress in that area - meaning development of
code/programs to tackle those specific problems.




--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611659.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Scott Carver
2014-06-18 17:37:22 UTC
Permalink
Though I've done minimal live coding in an actual performance context, I've
had occasional times when I'm working on music AS IF I were live coding,
i.e. the code I'm using is simple and expressive enough that I can
improvise with no down-time and achieve interesting results.

Easily the most powerful concept I've run into w/r/t that is the
composability of events and event streams via Pchain. I've had very good
results building out a piece by constructing a library of Pdef's containing
different gestural components -- separately, i.e. Pdef's for note / pitch
data, separate Pdefs encapsulating time gestures, Pdef's for different
instruments, etc. At that point, playing and modifying can look like:


Pdef(\main).play;
Pdef(\main, Pchain(

Pdef(\humInstrA),

Pdef(\fastShortC),

Pdef(\varyNotes).set(\vAmount, 0.2),

Pdef(\notesD)

));

...which is much closer to the kind of gestural thinking that's interesting
when performing (as opposed to, e.g., fiddling with decimal points inside
patterns) (and -- nothing about the above precludes also fiddling with
decimal points...).
- Scott
Post by joesh
Interesting remark. I'm coming at this from the other side as a 'jazz
musician' who interested to integrate live coding into my work. I've also
started looking into the idea of building a syllabus which takles this and
can be taught in a conservatory. There are, as I'm sure you're aware,
several conservatories teaching coding (or sonology as it's called over here
- I'm in the Benelux), but often it's taught as a harmonically static
process, which as you well know jazz isn't.
I'll be interested to see/read what others have come up with, but at the
moment I'm only learning SC, so i can't really make any solid remarks as
yet. Unfortunately as with other programs - PD, Csound, Usine or the like -
there isn't any scope for moving quickly through harmonic space, beats are
easy, syncing tempos with a live drummer surely a slight problem.
Lastly as you point out your not sure what methodologies to use as jazzers
have now a complete 'workbook' technique they can build from. I guess that
until more coders work in shifting harmonic areas and less in ostinato based
riffs there will be little progress in that area - meaning development of
code/programs to tackle those specific problems.
--
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611659.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.
_______________________________________________
sc-users mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Iannis Zannos
2014-06-18 18:11:08 UTC
Permalink
Perhaps relevant:

https://github.com/iani/tiny-sc/blob/master/Classes/SynthTree/Patterns/Edef/EventPatternTries.scd

Cheers,

IZ
Post by Scott Carver
Though I've done minimal live coding in an actual performance context,
I've had occasional times when I'm working on music AS IF I were live
coding, i.e. the code I'm using is simple and expressive enough that I can
improvise with no down-time and achieve interesting results.
Easily the most powerful concept I've run into w/r/t that is the
composability of events and event streams via Pchain. I've had very good
results building out a piece by constructing a library of Pdef's containing
different gestural components -- separately, i.e. Pdef's for note / pitch
data, separate Pdefs encapsulating time gestures, Pdef's for different
Pdef(\main).play;
Pdef(\main, Pchain(
Pdef(\humInstrA),
Pdef(\fastShortC),
Pdef(\varyNotes).set(\vAmount, 0.2),
Pdef(\notesD)
));
...which is much closer to the kind of gestural thinking that's
interesting when performing (as opposed to, e.g., fiddling with decimal
points inside patterns) (and -- nothing about the above precludes also
fiddling with decimal points...).
- Scott
Post by joesh
Interesting remark. I'm coming at this from the other side as a 'jazz
musician' who interested to integrate live coding into my work. I've also
started looking into the idea of building a syllabus which takles this and
can be taught in a conservatory. There are, as I'm sure you're aware,
several conservatories teaching coding (or sonology as it's called over here
- I'm in the Benelux), but often it's taught as a harmonically static
process, which as you well know jazz isn't.
I'll be interested to see/read what others have come up with, but at the
moment I'm only learning SC, so i can't really make any solid remarks as
yet. Unfortunately as with other programs - PD, Csound, Usine or the like -
there isn't any scope for moving quickly through harmonic space, beats are
easy, syncing tempos with a live drummer surely a slight problem.
Lastly as you point out your not sure what methodologies to use as jazzers
have now a complete 'workbook' technique they can build from. I guess that
until more coders work in shifting harmonic areas and less in ostinato based
riffs there will be little progress in that area - meaning development of
code/programs to tackle those specific problems.
--
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611659.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.
_______________________________________________
sc-users mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
ddw_music
2014-06-19 09:43:27 UTC
Permalink
Post by joesh
Interesting remark. I'm coming at this from the other side as a 'jazz
musician' who interested to integrate live coding into my work. I've also
started looking into the idea of building a syllabus which tackles this
and can be taught in a conservatory. There are, as I'm sure you're aware,
several conservatories teaching coding (or sonology as it's called over
here - I'm in the Benelux), but often it's taught as a harmonically static
process, which as you well know jazz isn't.
I'll be interested to see/read what others have come up with, but at the
moment I'm only learning SC, so i can't really make any solid remarks as
yet. Unfortunately as with other programs - PD, Csound, Usine or the like
- there isn't any scope for moving quickly through harmonic space.
Generative harmony is a matter of data representation and algorithm design.
SC has sophisticated data structures and it's (AFAIK) a "Turing-complete"
language, meaning it can express any algorithm that standard languages can.
There is definitely scope for generative harmony! You're correct that few
people have done it, but that reflects the complexity of the task, not any
lack of scope for it. (Probably one reason why it isn't done very much is,
if you're going to figure it out all by yourself, it takes both music-theory
knowledge and insight into algorithm design from computer science. It's a
lot to expect of one person. I think there are some books out there, but
free training materials would help... perhaps a future TODO for me...)

It's less likely to be done in Pd or Max, because their data structures are
weaker and complex algorithms are *much* more cumbersome to express in
graphical data flows than in code. That doesn't rule out writing externals,
or embedding JavaScript in a Max patch; still, SC's native paradigm is much,
much, MUCH better suited to harmony processing.

A quick, off-the-cuff list of the requirements might include:

- Diatonic representation of pitch (SC has that, including accidentals)

- Ways to measure the consonance or dissonance of a collection of pitches
(not built in, but if you decide what the measurement is, you can certainly
implement it. For instance, in ddwChucklib, I have functions that measure a
chord's "fit" above a given root pitch. The fifth, third, seventh and ninth
above the root get positive scores, in descending order, while the sixth
gets a negative score because it pushes the sonority more toward a root
that's a third lower. In this formulation, chromatic notes get punished
pretty harshly, but you can handle jazz chords with chromatic alterations by
testing the chord notes against several scales -- e.g., a major mode with #4
and b7 would match a dominant #13 chord. So you could choose a V root, the
#4b7 mode, and voice a chord based on that.)

- I also noticed, in some pieces where I wrote the harmony by hand, that I
was using more-or-less melodic motion in the top voice for continuity
between chords. So I built that into my algorithms: Choose a top note, and
adjust the chord notes to it (checking the "fitness" of the voicing against
the root note, as above).

That ended up being less of a list format than I expected, but I think it
makes the point: If you analyze your approach to harmony, you can model some
aspects of it in SC code.

See also, for instance, Paul Lansky's "Heavy Set" (on the **really
flippingly excellent** /Ride/ album which I cannot recommend highly enough
-- IMO, a must-hear), which models "the right hand of an imaginary (and very
large) improvising pianist."

hjh



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611692.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
ddw_music
2014-06-19 09:58:30 UTC
Permalink
e.g., a major mode with #4 and b7 would match a dominant #13 chord.
#11 chord (oops).

hjh




--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611694.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Julian Rohrhuber
2014-06-19 19:03:33 UTC
Permalink
Post by ddw_music
- Ways to measure the consonance or dissonance of a collection of pitches
one source would be the Dissonance quark, and Juan's thesis on the topic ...

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
henrique matias
2014-06-19 20:46:38 UTC
Permalink
I believe if you want to make something cool live, you must be able to
perform your code, and not only type.

IMHO, many people expect to see you writing down loads of stuff in order to
look "hax0r" but that generally results in not very musical or interesting
results from a listener perspective, or from a "musical point of view".

I believe you should create some musical content whatever way you manage to
do it, and then wrap it into an API ( for instance making your own class,
or Proto ), then have special messages and properties which you will use in
your live show.


If i was a teacher and i had pupils, the skill i would teach them is to
create simple musical content first then find simple ways of modulating it
that yields musical results.

Then building a few of those little modular musical things and eventually
working out a way of making them talk to each other, somehow like a jazz
like a band.


good luck!
Post by Julian Rohrhuber
Post by ddw_music
- Ways to measure the consonance or dissonance of a collection of pitches
one source would be the Dissonance quark, and Juan's thesis on the topic ...
_______________________________________________
sc-users mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Daniel Mayer
2014-06-19 21:41:40 UTC
Permalink
Post by joesh
there isn't any scope for moving quickly through harmonic space, beats are
easy, syncing tempos with a live drummer surely a slight problem.
The Pattern system is very well suited to
accomplish harmonic sequencing.
Patterns have an enormous flexibility,
it takes some time though to get through possibilities.

First there is built in stuff concerning scales, transposing, temperature etc.
Refering to harmonic states can be done in a number of ways,
especially data sharing is relevant:

http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_06g_Data_Sharing.html

Here an example with on-the-fly changes - you could
also use determined timing for scales etc. and use data sharing.

Not to say that this example is musically very elaborated,
but might give a taste where you can start experimenting


(
// some defaults, also default instrument

~steps = 12; // 12 steps per octave (equal temperature)
~scale = Scale([0,1,3,5,7,9,11]);
~shift = 0; // chromatic shift
~chords = [[0, 2]]; // pool of chords

p = Pbind(
\degree, Pseq((0..5), inf) + Pfunc { ~chords.choose },
\octave, Prand((4..6), inf),
\scale, Pfunc { ~scale },
\ctranspose, Pfunc { ~shift },
\dur, 0.2,
\amp, 0.05,
\legato, 2.5
).trace.play;
)

// change scale

~scale = Scale([0,2,4,5,7,10]);

// chromatic shift

~shift = 4;

// microtonal shift

~shift = 2.5;


// change chord pool (steps in scale)

~chords = [[0, -2], [0, 4, 7]];

~chords = [[0, 3]];


// scale within equal division of octave into 7 steps

~scale = Scale([0,1,3,4,5], 7)

~chords = [[-3, 0, 3]];


p.stop;


And still this is quite conventional thinking in strict sequencing of pitch pools,
but anything can be sequenced and harmonic relations might grow out from
data other than fixed pools of pitch classes.

Greetings

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------




_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Cole Ingraham
2014-06-19 22:48:40 UTC
Permalink
I'd also like to add that live coding with a group is often more varied and
intricate than solo, as obvious as that may sound. Continuing with the jazz
analogy: not everyone needs to be a solo pianist.

-Cole
Post by Daniel Mayer
Post by joesh
there isn't any scope for moving quickly through harmonic space, beats
are
Post by joesh
easy, syncing tempos with a live drummer surely a slight problem.
The Pattern system is very well suited to
accomplish harmonic sequencing.
Patterns have an enormous flexibility,
it takes some time though to get through possibilities.
First there is built in stuff concerning scales, transposing, temperature etc.
Refering to harmonic states can be done in a number of ways,
http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_06g_Data_Sharing.html
Here an example with on-the-fly changes - you could
also use determined timing for scales etc. and use data sharing.
Not to say that this example is musically very elaborated,
but might give a taste where you can start experimenting
(
// some defaults, also default instrument
~steps = 12; // 12 steps per octave (equal temperature)
~scale = Scale([0,1,3,5,7,9,11]);
~shift = 0; // chromatic shift
~chords = [[0, 2]]; // pool of chords
p = Pbind(
\degree, Pseq((0..5), inf) + Pfunc { ~chords.choose },
\octave, Prand((4..6), inf),
\scale, Pfunc { ~scale },
\ctranspose, Pfunc { ~shift },
\dur, 0.2,
\amp, 0.05,
\legato, 2.5
).trace.play;
)
// change scale
~scale = Scale([0,2,4,5,7,10]);
// chromatic shift
~shift = 4;
// microtonal shift
~shift = 2.5;
// change chord pool (steps in scale)
~chords = [[0, -2], [0, 4, 7]];
~chords = [[0, 3]];
// scale within equal division of octave into 7 steps
~scale = Scale([0,1,3,4,5], 7)
~chords = [[-3, 0, 3]];
p.stop;
And still this is quite conventional thinking in strict sequencing of pitch pools,
but anything can be sequenced and harmonic relations might grow out from
data other than fixed pools of pitch classes.
Greetings
Daniel
-----------------------------
www.daniel-mayer.at
-----------------------------
_______________________________________________
sc-users mailing list
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
--
DMA Music Composition - University of Colorado at Boulder
MFA Electronic Music and Recording Media - Mills College
BM Music Composition - University of the Pacific

http://www.coleingraham.com
http://www.glitchlich.com
https://soundcloud.com/coledingraham
http://www.facebook.com/coleingrahammusic
ddw_music
2014-06-19 09:26:04 UTC
Permalink
Post by Cole Ingraham
"All out live coding" is really hard. Yes there are some insanely talented
ninjas with 9000+ wpm that can make some amazing things happen from an
empty file, but for the rest of us I recommend having a handful of
starting code. This could be skeletons of things, complete code that you
intend to extend/tweak, infrastructure for effects, whatever is
appropriate. If anyone complains about that, tell them to go live code in
Assembly.
Actually, this was one of the intended uses of ddwChucklib. I ended up using
it more for modeling complex musical behaviors, but there's no reason why
chucklib objects couldn't be components of improvisation. I may have been
dissuaded from that by editorial comments from Nick Collins on my SC book
chapter, where I had proposed chucklib objects could be part of a live
coding framework, but he seemed adamant that this was Simply Not Live
Coding. More precisely (IIRC -- this was a few years ago), the objection was
that the code displayed to the audience should, in live coding, not merely
use algorithms, but communicate something about the nature of the
algorithms. "Code should be seen as well as heard, *underlying algorithms
viewed* as well as their visual outcome"[1] (emphasis mine).

A process prototype could, for instance, accept a string to define a drum
rhythm - hypothetically (I haven't written this prototype... yet):

PR(\strRhy).chuck(BP(\snr), nil, (sample: \snare, rhy: ".x.x"));
BP(\snr).play;

BP(\snr).rhy = "..x. ....x..x";

PR(\strRhy).chuck(BP(\k), nil, (sample: \kick, rhy: "xxxx"));
BP(\k).play;

BP(\k).rhy = "x x..x .x .";

... which is less convenient but not radically different from ixilang's "ac
-> hat |H Hhh hhh H h|"[2].

Hm... it's probably worth my while to revive that line of thinking.

~~

sc-tiny also looks very interesting. I like the way NodeProxies can
modularize synthesis -- assuming a ProxySpace is pushed:

~src = { ... };
~out = { \in.ar(0!2) };
~out.vol = 0.2;
~out.play;
~src <>> ~out;

~fx = { ... do something to \in.ar(0!2) ... };
~src <>> ~fx <>> ~out;

When I discovered that last technique... oh wow... mind blown.

But, starting from an empty code file and not using pattern helpers will
tend to push stylistically toward drones. sc-tiny seems like it would (once
it stabilizes) give you the benefits of Ndefs with tighter syntax and easier
pattern specification.

Really interesting topic -- thanks for all the suggestions!
hjh

[1] http://toplap.org/wiki/ManifestoDraft
[2] http://onewolftechblog.wordpress.com/2014/03/15/ixilang/



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611691.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
thor
2014-06-19 09:53:32 UTC
Permalink
Hi James

Just read this thread and I'd like to add a few notes. Firstly, that the field of live coding is
still so young that there is no 'canon' as you'd find in jazz. Many people design their own
systems and it's all very experimental at this stage. That's why it's such a fun field.
But there is certainly theory of various kind, well exemplified by a recent issue of Computer
Music Journal, edited by Julian, Nick and Alex.

http://www.mitpressjournals.org/toc/comj/38/1

You mention Nick's definition of live coding, and coincidentally in my paper I argue that this
is a "strong definition" of live coding, as opposed to more weaker definitions by practically
everyone else. But we should all aspire to Nick's : )

There is a guy called Click Nilson, who's written a paper on practice:

http://composerprogrammer.com/research/livecodingpractice.pdf

As to training materials, I'd say observe performances, but mostly that DIY is the best approach.

thor
Post by ddw_music
Post by Cole Ingraham
"All out live coding" is really hard. Yes there are some insanely talented
ninjas with 9000+ wpm that can make some amazing things happen from an
empty file, but for the rest of us I recommend having a handful of
starting code. This could be skeletons of things, complete code that you
intend to extend/tweak, infrastructure for effects, whatever is
appropriate. If anyone complains about that, tell them to go live code in
Assembly.
Actually, this was one of the intended uses of ddwChucklib. I ended up using
it more for modeling complex musical behaviors, but there's no reason why
chucklib objects couldn't be components of improvisation. I may have been
dissuaded from that by editorial comments from Nick Collins on my SC book
chapter, where I had proposed chucklib objects could be part of a live
coding framework, but he seemed adamant that this was Simply Not Live
Coding. More precisely (IIRC -- this was a few years ago), the objection was
that the code displayed to the audience should, in live coding, not merely
use algorithms, but communicate something about the nature of the
algorithms. "Code should be seen as well as heard, *underlying algorithms
viewed* as well as their visual outcome"[1] (emphasis mine).
A process prototype could, for instance, accept a string to define a drum
PR(\strRhy).chuck(BP(\snr), nil, (sample: \snare, rhy: ".x.x"));
BP(\snr).play;
BP(\snr).rhy = "..x. ....x..x";
PR(\strRhy).chuck(BP(\k), nil, (sample: \kick, rhy: "xxxx"));
BP(\k).play;
BP(\k).rhy = "x x..x .x .";
... which is less convenient but not radically different from ixilang's "ac
-> hat |H Hhh hhh H h|"[2].
Hm... it's probably worth my while to revive that line of thinking.
~~
sc-tiny also looks very interesting. I like the way NodeProxies can
~src = { ... };
~out = { \in.ar(0!2) };
~out.vol = 0.2;
~out.play;
~src <>> ~out;
~fx = { ... do something to \in.ar(0!2) ... };
~src <>> ~fx <>> ~out;
When I discovered that last technique... oh wow... mind blown.
But, starting from an empty code file and not using pattern helpers will
tend to push stylistically toward drones. sc-tiny seems like it would (once
it stabilizes) give you the benefits of Ndefs with tighter syntax and easier
pattern specification.
Really interesting topic -- thanks for all the suggestions!
hjh
[1] http://toplap.org/wiki/ManifestoDraft
[2] http://onewolftechblog.wordpress.com/2014/03/15/ixilang/
--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Research-and-training-materials-for-live-coding-tp7611656p7611691.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Edward Nixon
2014-06-19 13:53:53 UTC