[linux-audio-user] [ANN] Mondrian Project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Atte,
> 1) I managed to get everything installed, but a more detailed 
> installation instruction would be nice.
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?

> 2) How can I get more instances of mondrian running in sync each sending 
> on different midi out ports?
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.

> Can I sync mondrian to other things (or the other way around)?
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.

> 3) I grabed the "scaled.mon" from the documentation, but I get this (the 
> other files work fine):
> atte@aarhus:~/music/mondrian$ mondrian scales.mon
> /usr/lib/python2.3/site-packages/RawOutstreamFile.py:8: 
> DeprecationWarning: Non-ASCII character '\xe1' in file 
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.

> MThd`MTrk?/MTrk?/
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



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux