Dave Griffiths wrote: I tried building your "system", and things seems to have gone well. But: atte@aarhus:~/tmp/live_noise_tools/livenoisetools/noiseweapon$ noisepattern Traceback (most recent call last): File "/usr/local/bin/noisepattern", line 23, in ? import osc ImportError: No module named osc What am I missing (I'm running debian)? aarhus:~# apt-get install liblo0-dev liblo-dev liblo0 Reading Package Lists... Done Building Dependency Tree... Done liblo0-dev is already the newest version. Note, selecting liblo0-dev instead of liblo-dev liblo0-dev is already the newest version. liblo0 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 16 not upgraded. -- peace, love & harmony Atte http://www.atte.dk

On Fri, Aug 19, 2005 at 02:14:25AM +0200, Peter Brinkmann wrote: More to the point, the web server was fine, but the file server that has my home directory on it was down, causing the error that some of you have encountered. Either way, things should be working now. Peter

Atte, You're right, the README file is a bit terse at this point. Do you have any suggestions as to where specifically I need to flesh it out? That's definitely a part that I need to document more fully since the handling of ports and connections differs from the usual model. Here's what's going on: Early versions of MondrianLive managed ports and connections the usual way: Create ports, connect ports to clients, assign ports to tracks. I was rather unhappy with this approach because I felt the user had to spend too much time thinking about administrative details like port numbers and such, and there was also a certain lack of orthogonality since tracks and associated ports showed up as separate entities although they really belong together. I finally got rid of the old approach when I implemented latency correction. Here's how my latency correction works: An output port p is associated with a device whose latency is t_p milliseconds. Let t_max be the largest latency across all ports. Now, when an event is sent through port p, it is held back for (t_max-t_p) milliseconds, so that all output devices are in sync. In other words, this mechanism renders all devices as slow as the slowest one. (In case you're interested in using this sort of latency correction in another context, there's a stand-alone module in the latest version of the PySeq distribution that you can splice into connections of other MIDI devices.) Once I had implemented this behavior, managing ports and connections separately didn't make sense any more since each port has an associated latency that's only good for one specific output device. Moreover, since one typically connects an output device to a port for the purpose of sending it events from a specific track, the ports themselves aren't really all that significant, and it suffices to just think of device connections as maps that assign output devices to tracks. The upshot is, you connect MondrianLive to the outside world by telling it which track is supposed to target which output device. The actual ports are created and connected implicitly, so that you don't have to worry about them. Here's an example: One common setup on my side is to send the lead track (say, track 1) to my digital piano that's attached via an Edirol PCR-30 USB keyboard, and the remaining tracks are sent to timidity. In order to set this up, I issue the following commands to MondrianLive: ## map pcr pcr_midi 30 1 ## map timidity 0 400 Explanation: The first two parameters identify the target device and port, either by name or by number. For instance, the PCR-30 shows up as client 'PCR', and the digital piano is connected to a port called 'PCR MIDI'. (The names don't have to match exactly; case doesn't matter, an unambiguous substring is enough, and spaces and underscores are treated the same.) The third parameter gives its latency (about 30ms; I made that number up), and the fourth parameter is the track to be mapped to it. The second line targets port 0 of timidity (which seems to have a latency of about 400ms unless I call it with options like -B2,8). There's no fourth parameter for the track, which makes timidity the default output device for all tracks that have not been mapped to something else. Is this making sense at all? Sorry about the verbiage... I suppose it looks a bit arcane at first sight, but I like it better than the traditional approach because it does all the book-keeping (latencies, port numbers, connections, etc.) implicitly, and users only have to enter the bits of information that really matter, at the cost of having to get their mind around the map command. That's definitely on my to-do list. I haven't done this yet because I'm not currently using any programs that might act as MIDI masters or slaves. Is there any specific software that you'd like to drive from within MondrianLive, or vice versa? If so, that would help me figure out this feature since I'd have something concrete to work and test with. This warning is caused by special characters in the python midi package. It's harmless, but if it bothers you, you can fix this by deleting the main routine (which is just a collection of simple test cases) of the file /usr/lib/python2.3/site-packages/DataTypeConverters.py. You called Mondrian without giving an output file, so that it just printed MIDI to stdout. This particular MIDI file actually wouldn't produce any sounds since scales.mon doesn't contain any note events; it's intended for inclusion in other files and just defines a bunch of macros that define commonly used scales. Please let me know if you have further questions or comments. Hope this helps, Peter