Sep 16
Jim's comments
This is getting closer to reasonable. Here are a few things to consider.
1. The OSC spec (
http://opensoundcontrol.org/spec-1_0) and the python library that you're using allows for a data type (essentially int, float, string, other) for each field in the message. You should specify what yours are explicitly. in your test-input.py (by the way, a dash in a filename isn't a great idea) you are setting (pitch, duration, velocity, mfc1, mfc2, mfc3, mfc4) to (int, int, int, float, float, float, float). If this is part of your spec, say so explicitly. And also in the spec describe the range of allowed values and what the units are (seconds, Hz, midi note number, ...).
2. Right now you are passing around a list of numbers to the routines that create these things. You might consider defining a python class (i.e. an object) instead - as it is, the numbers at the bottom of the file in the definitions require remembering the order and form, rather than having it be obvious i.e. TimsMessage(pitch=_ , duration=_, etc)
3. The phrase uniform(0.1,1.0) shows up at least a dozen times in your code ... put that into a named function. Better yet, collapse the 4 mfc values into a single thing and have something that generates a random set of 4. (Not in the message itself - in the other functions).
4. The name "improv-vox" is a problem - importing into python as a library will treat the dash as a minus sign. Just don't use dashes in file names. Since this thing is going to acting as an agent (i.e. listening to a stream, producing a counterpoint line) a better name might be improviser.py , which would imply that "agent" manner of operation.
5. The description of the osc protocol at the top of improv-vox is misleading - MFC is four numbers, not one. Either repeat the spec here, or refer to it.
6. Does this code work? What does it give as output and what does it do? If I want to run it, what should I do? None of that is obvious without digging in and staring at the code.
Tim says
Recent readings
- Computational Music Analysis: chapters 1, 5, 11
- Music21 docs: chapters 1, 2, 3, 4, 5, 6, 12, 13, 21
Work done this week
I updated the README file to be a bit more professional.
I’m trying to define a standard for my OSC protocol. This first version sends notes as a list of several parameters (in order): fundamental frequency (float), note duration (int), velocity (float), Mel-frequency central coefficient (MFCC) (four separate floats). The first three are the main parameters for MIDI notes, with MFCC functioning as a description of timbre. The first coefficient of a MFCC is notably unreliable, so I am using the second, third, fourth, and fifth coefficients. I will likely expand the number of coefficients used in a subsequent version of this protocol. If I use a density measure, I will calculate it in Python.
I’m including the Max/MSP patch rather than just an image because Cycling ’74 (the developer of Max) allows anyone to download the program for free. The only restriction is that a user without a license can’t edit the patches. I will continue to include the test-input Python file as another demonstration of how the OSC data is being sent.
Possible work for next week
I have included several function place-holders for manipulating phrases, such as shortening their duration or going out of tune. Implementing those will be my next step.
I need to decide on an initial way to derive phrases from series of notes.