12-tone row generator

[Noisewreck]

^^^ Sounds very cool actually

[Isjtar]

Originally posted by Noisewreck Sorry to be a party pooper, but this is the kind of thinking that killed dodecaphonic music. Too many "composers" in 20th century picked up the 12-tone formula, and turned it into a mere academic curiosity, sucking all the humanity out of it. Sure, it might be possible to do something that on the surface might sound alright, but what about the human soul? There are very few pieces that would come close to Webern's Piano Variations, or Berg's Violin Concerto that are written by humans that is, much less some computer generated collection of sounds. Even with Webern's Piano Variations, it takes a genius like Glenn Gould to bring out the beauty and musicality of the piece. Flame if you want, but I stand firmly by my convictions. rachMiel, this reminds me of your "Soundings" articles in CM August '04, where you write about being slave to forms and CM November '04 issue, where you write about "groove faschism" (great articles btw, like all the others. I always look forward to them). While you challenge the readers to push their boundaries and expand their musical language, isn't at the heart of both articles really the complaint that so much of today's music sounds soulless, formulaic and unimaginative? And this is what, I believe, generated all the negative attitudes towards dodecaphonic and other serial music. Not because it sounded "ugly" or "difficult to follow", as many complained, but because it had become unimaginative and soulless. Just listen to aforementioned Berg's Violin Concerto, or Shoenberg's Pierrot Lunaire or Colors, and tell me if they sound ugly, and while they might be "difficult to follow" to some that are used to just listening to pop or rock songs, they really aren't much more "difficult" than Tristan und Isolde or Elektra.

spot on, my friend : )

however, i don't think that would prohibit making an ensemble like this.
it makes building the ensemble more difficult and the user would have to put soul in it himself. random tone rows aren't suitable, you'd have to be able to select them. some other user interventions should be possible too. the subtlety you lose by having a computer do it, you can regain by shaping the sounds it generates.

i can't build it in R (i might in max), but it's very interesting.

[ashwaganda]

okay, i'll bite: i'll create 12-Toner. :-)

if anyone has objections, let's discuss.

if anyone has suggestions for features, please send.

my initial thought is to make it a controller type of instrument, rather than a sound-producing one. the user would specify a 12-tone row and a sequence of transformations for it (inverse, retrograde, etc.). 12-Toner would then output a set of 1-8 parameter streams. the sound-producing instrument would receive these streams and use them to control key musical parameters: pitch, duration, timbre, dynamics, space, etc. in this approach, it would be up to the user to decide how the incoming 12-tone data streams actually sculpted the sound. it would really be fun for me to see what builders did with this. :-)

rick

[tubaman]

So this would be sending midi? Could it have multiple channels so the row could send note, etc. data to mutiple devices for a poitillistic[sp?] effect?


Or would it load samples? In which case each of the 12 modules could send data to play different samples for different notes.

So isn'tit just a sequencer? To be specifically a 12-tone controller, you'd want it to keep cycling through the row, changing from a original to retrograde to inverted, etc in a random or pre-determined order.

[ashwaganda]

> So this would be sending midi?

not sure yet ... midi is convenient, but also potentially cpu-hoggy. it might be better to go with normal wire outputs/inputs. comments?

> Could it have multiple channels so the row could send note, etc. data to mutiple devices for a poitillistic[sp?] effect?

perhaps ... i still haven't figured out, to my satisfaction, how to send midi messages to different channels. would this be good?

> Or would it load samples? In which case each of the 12 modules could send data to play different samples for different notes.

if the sound-producing instrument contained a sampler, it would be very easy to get the incoming 12-tone data to trigger different samples. is this what you mean?

> So isn't it just a sequencer?

with some 12-tone-specific features, yes.

> To be specifically a 12-tone controller, you'd want it to keep cycling through the row, changing from a original to retrograde to inverted, etc in a random or pre-determined order.

yes ... i'd have to think this out: what choices to give the user for ongoing flow through the 12-tone row.

rick

[Rameau]

rachMiel,
It's great that you're doing this. It seems like just the thing you'd be good at--was playing with crawldaddy and grannysmoother again and liking them very much, very organic. I haven't tried doing generative stuff before--just support for live play--and methinks I am lousy at it.

But I have an ingredient, which I've been trying to put in the library, which is still not working.

Basically it's a tone row generator macro that lets you initialize an event table to a row with sequential values 1-12, and then permute these values to reorder, or retrograde order them (the code for exchaning table values could also be used to do a sort).

Client tone row readers have buffers that get updated each time there is an init, permute, or retrograde, and the buffer goes live on a refresh signal, so you can update to the latest permutation at will. The readers have settings for non-destructively changing the phase of reading, reading retrograde, or inverting the output values. I've hooked this up to a DTMF tone dialer just for fun; I'm starting to see what you can do. Click the play button in Reaktor and select the Passing Nights or CrystalBell snapshot in the SpectralMorphatorium.

One thing I'd thought of: have two readers of one row be out of phase, with their outputs specifying a randomization range; I'd actually thought of splicing something likes this into a rachMiel instrument.

Anyway, I think the work I've done mught be useful. To get it now while the library isn't working, you can download it at www.jambient.com/SchoenbergPhoneHomev05.zip

[ashwaganda]

aha: so Rameau = jambient ... who knew? :-)

> It's great that you're doing this. It seems like just the thing you'd be good at --

thanks for the support. :-)

> But I have an ingredient, ... a tone row generator macro that lets you initialize an event table to a row with sequential values 1-12, and then permute these values to reorder, or retrograde order them (the code for exchaning table values could also be used to do a sort).

sounds like a great starting point.

> Client tone row readers have buffers that get updated each time there is an init, permute, or retrograde, and the buffer goes live on a refresh signal, so you can update to the latest permutation at will. The readers have settings for non-destructively changing the phase of reading, reading retrograde, or inverting the output values. I've hooked this up to a DTMF tone dialer just for fun; I'm starting to see what you can do. Click the play button in Reaktor and select the Passing Nights or CrystalBell snapshot in the SpectralMorphatorium.

i just had a quick look: seems very cool. i need to explore more.

> One thing I'd thought of: have two readers of one row be out of phase, with their outputs specifying a randomization range; I'd actually thought of splicing something likes this into a rachMiel instrument.

good idea. i'll have to figure out how to use one row to generate several data streams (the foundation of 12-Toner). particularly: how should the data streams sync or not sync with one another?

so what do you think, jamb: should the data be sent via midi modules or via wires or via wireless terminals? or ... ?

great work. thanks!

rick

[Rameau]

Originally posted by rachmiel aha: so Rameau = jambient ... who knew? :-) > It's great that you're doing this. It seems like just the thing you'd be good at -- thanks for the support. :-)

Mon plaisir..and thanks for the enthusiasm for the start of the tone row. Yes Rameau = jambient, my little secret, or it became one when the user library started using our real names...

> One thing I'd thought of: have two readers of one row be out of phase, with their outputs specifying a randomization range; I'd actually thought of splicing something likes this into a rachMiel instrument. good idea. i'll have to figure out how to use one row to generate several data streams (the foundation of 12-Toner). particularly: how should the data streams sync or not sync with one another?

Don't know if the following helps...
Technically, the way to use one row to generate several data streams in the model I've been working with: generate each data stream from a separate tone row reader client, with each wired to a single tone row generator. The idea here is you can have separate reading rates for each stream, or have them synced to one read clock, and let them be desynchronized through the Phase and Retro settings in the reader macros. So that's one sort of syncing issue.

The other syncing issue I pondered in building the basic macros is how to have different streams sync with changes to the tone row. That's where I came up with the Refresh input, so you can sync client streams with the server at whatever period you want. NB, you need to wire the value, wx, and cpy inputs of client readers to the tone row generator; the generator sends a copy signal whenever the master tone row changes, and this opens a latch that lets a refresh signal in the reader switch to the updated buffer (really: alternate between reading from rows 0 and 1 in the even table). This system prevents a refresh signal from switching to outdated garbage in the buffer. Also note that when you've been working on your ensemble, you'll have to do an init in the tonerow generator to clear things out of garbage introduced when Reaktor recomiples the circuit.

so what do you think, jamb: should the data be sent via midi modules or via wires or via wireless terminals? or ... ?

Well, in your previous posts you gave good performance reasons for using wires over midi. But in digging through your instruments it's pretty clear you are the maestro of midi control, and have a logic for compounding random midi madness (randomizers of randomizers) into sveltly articulate sound organisms, so wouldn't going with midi might fit into that, and Neuralis.

On the other hand, I always find midi stuff in reaktor a pain because there is no way of just having an input specify what cc or note you want at runtime, you have to use properties at design time...the amount of work you put into setting these properties in your ensembles .... And I've gotten tanked by weird rounding errors in translating from min-max properties to 0-127 values, etc.

Send modules could be cool because of ability to specify what you are receiving from. But if I remember right this forces a recompile, like changing a switch module, so would only be good for runtime, not playtime.

What do you think?

(Another possibility is a single wire internal bus with values and signal types multiplexed--fast as wires, more flexible than midi at run time, but can be a pain to program. Used this idea in jambient TapeWorm. )

[Rameau]

(You could also have the multiplexed bus go wireless: everything that wants to contribute to the signal goes through an event merge to a single send; everything that wants to use the signal has a receive that picks up on this send and filters what it needs; copying such a unit hooks it up to the send without wires. Would be nicer to do this with midi, since then you don't need a wired event merge to have multiple senders go to one send line; but 0 to 127 won't do for multiplexing, and you can't use the 16384 range of pitchbend because of rounding errors; and I can't figure out how to coordinate multiple bits of midi data.)

[Rameau]

Finally, library is working. Skeleton elements for tonerow are up in ensemble Schoenberg Phone Home, pardon the offense, this is meant to be the start of some experiementing.