[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SIGMusic] Meeting notes
- To: Alex Hendrix <amhendr2@xxxxxxxxxxxx>
- Subject: Re: [SIGMusic] Meeting notes
- From: RJ Marsan <rjmarsan@xxxxxxxxx>
- Date: Mon, 13 Feb 2012 00:40:22 -0600
- Cc: sigmusic-l <sigmusic-l@xxxxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A/qFLAAget5F106MIGWnsZaXTJ9oOJbgec2+TGPDXp4=; b=A7CXgqB6IBYlPH3zGO8gi81BgBMky34FJ1YByR/TwBvDVMiv3qRWMagSlk0k7dky/q AqSadzlpTk1x7wy29TZMeIN0jmgdCWBFHWBeB9oWB3IEtOe8SdkmEM/BwLYRHhXywzsO UA4zr1NQdLqF2/c8fc/2wz2B6PsUoxCKedbUg=
I think those 3 parameters work well, I'm CCing the mailing list so that they can chime in.
Using 16th notes would be fine. It's virtually impossible to hit the limit of a udp packet going across localhost, especially for our circumstances.
If you want, we can change the code so that the puredata patch does None of the note conversion at all (aside from MIDI to frequency). That's no big deal.
We'll need to think of a system so that we can continuously feed puredata with new notes, while not clobbering the current measure being played. I'm thinking of doing a double-buffering situation, where puredata reads from one array, and the java app will write to another array, and every measure/phrase/whatever it 'switches off'. We could even implement a 'future measures' system where we can write n measures in advance.
On Sat, Feb 11, 2012 at 12:44 PM, Alex Hendrix <amhendr2@xxxxxxxxxxxx>
my github id is amhendr2
I've been thinking about how the melody generator is going to work, I've already got the repo cloned, and have done minimal work because I want to pass things by you to see what you think. I don't know if we've decided on any parameters, but heres what I'm thinking to get started..
Happiness vs. Sadness
Excited vs. Relaxed
Random vs. Logical
We can use these parameters to create different moods while leaving simple bounds for defining the key, chord progression (maybe), and what notes are actually going to be played. For example, Sadness + Excited = Angry, and the random/logical parameter can help us define how far we are willing to stay within a certain key when a melody is generated. I'm thinking each value will be an int between 0 and 100, or a float between 0 and 1.
As far as puredata, I know that we're sending packets containing 16 notes per each instrument (except I see there are 32 notes sending for the hi-hat, I'm not sure why that is?). What I'm wondering is if we can treat those notes as 16th notes by default instead of quarter notes. I'm not sure what all the problems this could cause except that we'd have to send 4x the amount of packets to define a song, but we'd have 4x the freedom with the rhythm, which I think is paramount for keeping a song fresh while being able to keep it simple with chord and key changes.
As far as melody generation goes, I think that we should do all the key definition and chord changes in the melody generator and automatically transpose the 8 notes in the scale to whatever we need. For example, lets say the key we're in is F5, we can define that as 3, and add 3 to all the base values of the major scale (0,2,4,5,7,9,11,12) to transpose to that, and send those transposed notes off to puredata, which means that puredata will hopefully be able to recognize the notes as is and play them. For example, let's say it wants to play 3, it would recognize that that's F5 and not have to do any conversion, or receive 15 and recognize it's F6. (All of the values are arbitrary) Maybe this is a bad way to go about things, but I don't see any other way if we want to be able to play multiple keys, chords, octaves, etc. It would be much easier to handle all of the melody generation in Java, so puredata has to do almost no work but play what's been sent to it.
I'm still working on the rhythm, I'm thinking I'm going to have to predefine some measures and have the hi hat chose a line, while mostly keeping the snare on 2 and 4 while accenting a few high notes of the melody, the bass drum can have a more random algorithm. Just some thoughts, though.
One other quick note, if we're generating all of this based on parameters, how is the generator going to receive the parameters?
Excuse this huge wall of text, I hope this all make sense.
Please let me know what you think, thanks!
Web stuff: UI has been mocked up. awesome. let's look at Twitter Bootstrap for UI
Twitter stuff: dunno. ask jake.