[range] is one of those objects I don't strictly need, but use for screen real-estate and speedy coding. It is cheating a little, mind. All the generated notes are kept, so they do have to be stored somewhere, I do realize that this could be a single, expanding array. And yes, I did mostly share this because I felt it was quite an interesting bit of generative work... Now I just need somewhere to exhibit it.
> Date: Mon, 27 Jun 2011 07:50:43 +0100 > From: padawa...@obiwannabe.co.uk > To: pd-list@iem.at > Subject: Re: [PD] Pd "monosymphonia" > > > > Hi Andrew, > > That was very interesting to listen to to. Thanks > for sharing it. > > A couple of thoughts, though I may be missing > some important point; since you only keep a scope > of the last 3 notes you could use float boxes > instead of creating tables on the fly. Also, > the concept seems to be a base N counter, so > approaching this starting with an up-down counter > might simplify it. > > Also [range] seems to be missing for me but easily > fixed with a multiply and an add. > > best > andy. > > On Sun, 26 Jun 2011 00:32:27 +0100 > Andrew Faraday <jbtur...@hotmail.com> wrote: > > > > > Hey Pders > > I've been messing with the idea of combining dynamic patching and > > generative music. And after a few hours of work I've come up with a patch > > (attached) which uses some rules to build a randomly generated piece of > > music who's result I'm rather fond of. > > On opening the patch, a 4-number array is generated, with a choice of 1 > > single note to choose from. It's played by a simple sine oscillator, then a > > second iteration generates a second array, choosing from 2 notes (adding > > one a semitone above), plays the two arrays in order, then generates a > > third, with 3 notes to choose from, and so on. > > As the piece progresses, the choice of notes playing through a sequence > > that's always a low drone, expanding out to a more tangible mid-range, > > usually coming up with melodic fragments, and then starting to use some > > higher-pitched sounds. And all the time the feedback on a delay unit on the > > output, of the system. > > When the range of notes reaches 127, the feedback jumps from 60% to 90%, > > changing the mood of the piece significantly, building to a harsh climax, > > each frequency range of notes lasting into the next and gains more > > significance. Like the perceived voices vying for position. > > Eventually, when a note above midi 127 is played, the synth stops, and the > > delay tail gradually fades out. > > I've found this to be an unusually structured and dramatic piece of > > generative patching. Initially a low drone, which pushes out and explores > > into melodies, building ideas, and being repeatedly pushed back to it's > > initial form. Then building into a repeating and expanding set of phases. > > getting louder and busier. Then a change brings this to a head, and > > signifies to the audience that the piece could end on any phase, building > > excitment to an inevitable but always unexpected end. > > > > > > Sorry, I've written quite a lot about this, but I thought the PD list might > > be interested... If anyone could spare about 15 minutes to listen to the > > patch in action, I'd love to hear what you think of the artistic result. > > > > Thanks in advance. > > Andrew > > P.S. I do realize that I could clean this up a great deal. The addition of > > [table] objects could just as easily be a single expanding array, I could > > hide modules away in sub patches and the sliders used for visualization > > could be more efficiently done with gem. > > > > -- > Andy Farnell <padawa...@obiwannabe.co.uk> > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
