Re: [linux-audio-dev] Basic MIDI question

[Pedro Lopez-Cabanillas]

On Monday, 24 July 2006 16:38, Lee Revell wrote:
> Take the sequence "80 3D 35  31 80 3A 39  0E 80 37 31  03 80 31 1F" in
> the first line for example.  I know that 0x80 is note-off, and 0x3D are
> note number and 0x35 the velocity of the note-off.  But what the heck is
> the next byte, 0x31?  

Delta time of the next event, in variable length representation.

> The MIDI standard says note-off is one status byte 
> followed by 2 data bytes!

SMF (Standard MIDI File) format must store timestamped events, which the MIDI 
protocol (over the wire) doesn't care. There is a good reference of SMF 
format here: http://borg.com/~jglatt/tech/midifile.htm

You may want to try some SMF-to-text conversion utility:
http://alsa.opensrc.org/MidiComp

Regards,
Pedro

Re: [linux-audio-dev] Re: How to use the alsa sequencer?

[Pedro Lopez-Cabanillas]

On Monday, 19 June 2006, Stephen Cameron wrote:
> > http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html
>
> Thanks, I'd found that already... it's slightly better than no
> documentation. :-)  But I'll take what I can get.  It's a little
> rough going at first when it kind of assumes you're aware of a big
> picture that, in my case, I was almost totally unaware of.  As you
> slowly figure it out, and the bigger picture of how all the pieces
> fit together -- sequencer ports, clients, channels, and how they're
> named and accessed and what's what, the docs become a little clearer.
>
> Helps to understand it before you read it, heh.

This document is the original proposal, by the ALSA sequencer author:
http://www.alsa-project.org/~frank/alsa-sequencer/index.html

A bit outdated, but a very intersting reading, if you want to get the big 
picture.

Regards,
Pedro

Re: [linux-audio-dev] Re: How to use the alsa sequencer?

[Pedro Lopez-Cabanillas]

On Sunday, 18 June 2006, Stephen Cameron wrote:
> > Hi,
> >
> > I'm trying to figure out how to use the ALSA sequencer
> > with my app.  (to date, I've been just using raw midi).
[..]
> But if I take out this line
>
>         snd_seq_ev_set_dest(&ev, 128, 0);
>
> And replace it with:
>
>          snd_seq_ev_set_dest(&ev, SND_SEQ_EVENT_PORT_SUBSCRIBED, 0);
>
> And try to use aconnect to connect things together, it doesn't
> seem to work.
>
> So, there's some piece of the puzzle regarding how aconnect
> works that I'm missing.

snd_seq_ev_set_subs(&ev);

I guess you may want to generate the ALSA library documentation from the 
sources with doxygen. It is also available online:
http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html

Regards,
Pedro

Re: [linux-audio-dev] Re: [ANN] No More Specimen

[Pedro Lopez-Cabanillas]

On Thursday, 20 de April de 2006 13:49:19 -0400, Paul Winkler wrote:
>
> Sorry to disturb your eternal slumber, RIP.

You are burying the wrong guy. It was Pete Bessman who lived fast, died young, 
and left a good-looking corpse behind. 

Regards,
Pedro

Re: [linux-audio-dev] Re: [ANN] No More Specimen

[Pedro Lopez-Cabanillas]

On Thursday, 20 de April de 2006 09:57:14 -0400, Paul Winkler wrote:
>
> I can understand not wanting to maintain it any more,
> but where'd the download go??
> http://gazuga.net/files  --> 404

Here are the last files:
http://gazuga.net/specimen/files/

And here some old ones:
http://gazuga.net/specimen/oldfiles/

There is a pointer from the 'downloads' page:
http://gazuga.net/specimen/downloads.php

Or I'm not understanding your question?

Regards,
Pedro

Re: [linux-audio-dev] Juce now has ALSA support!

[Pedro Lopez-Cabanillas]

On Wednesday 01 March 2006 12:51, Julian Storer wrote:
> James Courtier-Dutton wrote:
> > "default" means just that. use the name "default" instead of
> > plughw: or hw:0,0
[...]
>
> Ok, at the risk of "spreading the myth" that the ALSA documentation is
> bad... is this stuff actually explained anywhere?? It took me a day of
> googling just to find out what the two numbers after "hw" meant! I never
> saw anything mention "default" or "plug:front", etc.

http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_dev_names

Regards,
Pedro

Re: [linux-audio-dev] Audio/Midi system - RT prios..

[Pedro Lopez-Cabanillas]

On Saturday 31 December 2005 17:10, Paul Davis wrote:
> On Fri, 2005-12-30 at 22:27 +0100, Pedro Lopez-Cabanillas wrote:
> > On Friday 30 December 2005 17:37, Werner Schweer wrote:
> > > The ALSA seq api is from ancient time were no realtime threads were
> > > available in linux. Only a kernel driver could provide usable
> > > midi timing. But with the introduction of RT threads the
> > > ALSA seq api is obsolete IMHO.
> >
> > I don't agree with this statement. IMHO, a design based on raw MIDI ports
> > used   like simple Unix file descriptors, and every user application
> > implementing its own event schedule mechanism is the ancient and
> > traditional way, and it should be considered obsolete now in Linux since
> > we have the advanced queueing capabilities provided by the ALSA
> > sequencer.
>
> low latency apps don't want queuing they just want routing. this is why
> the ALSA sequencer is obsolete for such apps. frank (v.d.p) had the
> right idea back when he started this, but i agree with werner's
> perspective that the queuing facilities are no longer relevant, at least
> not for "music" or "pro-audio" applications.

Many professional musicians want MIDI capabilities on their PCs because they  
already own (or want to have) electronic musical instruments communicating  
via MIDI. This means that the computer is another piece of musical equipment 
in the musician's studio/network.

The kind of scenario you are painting about low latency applications seems  
limited to soft synths listening to sequencing applications. Using MIDI to 
this kind of communication between two processes running in the same machine 
looks a bit overkill to me. MusE has synth plugins, and Rosegarden has DSSI 
synth plugins, without ALSA sequencer being involved here.

> > It could be the absolute winner if problems like the audio
> > synchronization   and slave MTC synchronization were solved likewise.
>
> what problems? JACK demonstrates perfect audio sync in the only sensible
> way there is (the same way every other system does it); several JACK
> clients have MTC slave capabilities, including ardour, and it has
> nothing whatsoever to do with the ALSA sequencer.

Exactly. Please, excuse me my poor English. I mean functionality instead of 
problem. Let me reword the sentence: ALSA could be even better if there were 
another universal mechanism available for every ALSA application, providing 
an easy and consistent way to synchronize a queue with an external MTC 
master, without needing to recode the whole process for each application.

I know that Ardour provides slave MTC synchronization, and also does 
Rosegarden. Each one uses a different approach, and in the future there will 
be many more better or worse implementations.

I like the way Rosegarden solves it, using the ALSA sequencer queue skew 
parameter. I guess that we can build another ALSA sequencer client, either a 
kernel module or a userspace one, accepting MTC input and translating the MTC 
sysex messages received to skew in some queues used also by any other ALSA  
clients. Comments?

Regards,
Pedro

Re: [linux-audio-dev] Audio/Midi system - RT prios..

[Pedro Lopez-Cabanillas]

On Saturday 31 December 2005 00:52, Florian Schmidt wrote:
> All of this depends on whether physical port midi activity is really
> handled by IRQ's too. Anyone know more?

I don't know every MIDI interface details, but there are many different  
variations. Please, somebody with better knowledge could provide additional 
info and correct my very probable mistakes.

USB MIDI interfaces don't generate interrupts. Instead, this is done by the 
USB host controller (EHCI/OHCI/UHCI). The driver for these devices provide an 
interrupt handler not directly, but indirectly (the in/out URB completion 
handlers). So yes, this device type may be considered interrupt-driven.

The oldest MIDI interface for PCs was the Roland MPU-401. It had two  
operational modes: Intelligent and UART mode. Intelligent mode was necessary 
because the low power of early personal computers CPUs. This intelligent mode 
required IRQ handlers for both MIDI input and output operations, and to 
control the internal timer used for hardware scheduling and event 
timestamping, and also for external MTC/SMPTE synchronization. It was a 
rather sofisticated piece of hardware, but there is not an ALSA driver for 
these devices (and I don't know a single manufacturer selling it nowadays). 

The MPU-401 UART mode doesn't provide an interrupt signal to finish the  
output completion, so you must use polling for output (it provides an 
interrupt only for incoming events). There is an ALSA driver for this mode, 
that is used also by many consumer sound cards emulating the MPU-401. I 
wouldn't recommend to use these MIDI interfaces.

Other chips, as the Ensoniq 1370/1371 used in some cheap SoundBlaster 
products, included a better UART mode, providing interrupts for both 
reception and transmission. There is also an ALSA driver for the 16550 UART, 
that can be used with a few external devices like the Roland Canvas and the 
Midiator devices.

Regards,
Pedro

Re: [linux-audio-dev] Audio/Midi system - RT prios..

[Pedro Lopez-Cabanillas]

On Friday 30 December 2005 17:37, Werner Schweer wrote:

> The ALSA seq api is from ancient time were no realtime threads were
> available in linux. Only a kernel driver could provide usable
> midi timing. But with the introduction of RT threads the
> ALSA seq api is obsolete IMHO.

I don't agree with this statement. IMHO, a design based on raw MIDI ports used  
like simple Unix file descriptors, and every user application implementing  
its own event schedule mechanism is the ancient and traditional way, and it 
should be considered obsolete now in Linux since we have the advanced 
queueing capabilities provided by the ALSA sequencer.

You guys are talking here about MIDI timing, considering only the event 
scheduling point of view, as if Rosegarden or MusE were simple MIDI players. 
Of course, playing beats on time is a required feature. But my bigger concern 
about MIDI timing issues is when you are *recording* events. Here is where 
ALSA queues, providing accurate timestamps for incoming events, are so good.  
It could be the absolute winner if problems like the audio synchronization  
and slave MTC synchronization were solved likewise.

Regards,
Pedro

[linux-audio-dev] [ANN] ALSA MIDI Kommander

[Pedro Lopez-Cabanillas]

ALSA MIDI Kommander is a DCOP [1] interface exposing many ALSA Sequencer [2] 
features for shell scripts, Kommander scripts [3], or KDE programs requiring 
MIDI Sequencer services. A few MIDI utilities have been developed with this 
tool, which can be  used both as programming examples and as real work tools.

The main program, "kaseq" is a single executable, used as a DCOP service 
program. It runs as a daemon, allowing only a single running instance, and 
providing a system tray icon to give visual feedback for MIDI activity, and a 
way to control the program execution itself. It depends on KDE 3.x and the Qt 
library.

More information at this provisional project site:
http://kmetronome.sourceforge.net/kaseq/

Downloads
http://sourceforge.net/project/showfiles.php?group_id=134956&package_id=164501

Source packages
http://prdownloads.sourceforge.net/kmetronome/kaseq-0.2.3.tar.bz2?download
http://prdownloads.sourceforge.net/kmetronome/kaseq-0.2.3.tar.gz?download

Copyright (C) 2005, Pedro Lopez-Cabanillas 
Released under the terms of the GNU General Public License (GPL)

References

[1] DCOP
http://developer.kde.org/documentation/other/dcop.html

[2] ALSA Sequencer API
http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html

[3] Kommander
http://kommander.kdewebdev.org/

Re: [linux-audio-dev] Behringer firmware update

[Pedro Lopez-Cabanillas]

> Now, what would an amidi command look like that guarantees to update
> each and every midi-device found with said sysex file?

amidiall.sh

CUT
#!/bin/bash
CMD=$(which amidi)
PORTLIST=$($CMD -l|awk '/^hw:/ { print $1 }')
for P in $PORTLIST; do
echo "$CMD --port=$P $*"
$CMD --port=$P $*
done
CUT

Usage:

$ amidiall -s myfile.syx

Regards,
Pedro

Re: [linux-audio-dev] Libs for reading/writing midis

[Pedro Lopez-Cabanillas]

> > rosegarden and muse's source it seems there's always app specifics
> > intertwined.
>
> Sure, *because* there wasn't a standard midifile library around in the
> first place, they all hacked it into the program directly, therefore it is
> intertwined :-).

No. The first release date of Thompson's library is unknown, but at some  
places in the sources there is a notice saying: "June, 1989 - Added code to 
write midi files...". 

The old Xaw-based Rosegarden was born in 1994. The new Rosegarden4 development 
started in 2001, and Muse did in 1999.

Why nobody uses this library is unknown for me. There is a copy of it in  
alsa-lib package [1], added in 1999 according with the CVS history. It is 
used for tests, but the MIDI player and recorder programs in alsa-utils don't 
use it.

[1] 
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/test/midifile.c?rev=1.3&view=markup

Regards,
Pedro

Re: [linux-audio-dev] Libs for reading/writing midis

[Pedro Lopez-Cabanillas]

> > libmidifile would be cute, is any of the existing codebases flexible
> > enough so that it could be massaged into a nice lib?
>
> vote++ to everything you said. dunno about any existing midi code though
> flexible enough to be put into a lib.. After taking a glance at
> rosegarden and muse's source it seems there's always app specifics
> intertwined.
>
> Wasn't a midi file pretty much a simple dump of midi events anyways?

SMF (Standard MIDI Files) are structured data files, derived from IFF 
(Interchange Format Files), close but not fully compliant with the RIFF 
format. There is also a RMID format developed by Microsoft which is a true  
RIFF format and only prepends a 12 bytes header to the classic MIDs.

I agree with you on the topic of SMF import/export code in most open source  
programs. My problem is that they usually mix policy and mechanism, making 
hard to reuse only the mechanism (read and write MIDI files), because each 
program has its own internal format (policy) to represent the music. 

I like Tim Thomson's midifile library because it only provides a clean  
mechanism that you can reuse together with your own policy. It's plain C code 
and free: http://thompsonresidence.com/tjt/software.html#midifile

Based on that code I wrote a SMF component for Kylix/Free Pascal, included in 
this package: http://perso.wanadoo.es/plcl/alsapas/midiobjects-0.2.tar.gz

Regards,
Pedro

Re: [linux-audio-dev] HOw to create an ALSA out port

[Pedro Lopez-Cabanillas]

On Monday 25 July 2005, Jens M Andreasen wrote:
> On Mon, 2005-07-25 at 00:50 +0200, Christoph Eckert wrote:
> > I only need to write sysex data which are kept in a character
> > array. Is there a possibility to easily
> > * connect to a certain port of a device (the Midisport control
> > port)
> > * send the contents of the array to this port
[...]
> Let's see if not someone will post the alsa version ... soon.

I hope the attached program to be simple enough to be useful in your context.

Compile it with:
$ gcc -o amsgsysex -l asound amsgsysex.c

Use it with;
$ amsgsysex 64:1

Regards,
Pedro

/*
 *  Copyright (C) 2005 Pedro Lopez-Cabanillas <[EMAIL PROTECTED]>
 *
 *  This program sends a sysex MIDI message to an ALSA sequencer port
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License version 2 as
 *  published by the Free Software Foundation.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 */

#include 

unsigned char msg_gmreset[] =
{ 0xf0, 0x7e, 0x7f, 0x09, 0x01, 0xf7 };

char *port_address = NULL;
int port_out_id;
snd_seq_t *seq_handle;

void send_event(snd_seq_event_t *ev)
{
	int err;
	snd_seq_ev_set_source(ev, port_out_id);
	snd_seq_ev_set_subs(ev);
	snd_seq_ev_set_direct(ev);
	if ((err = snd_seq_event_output_direct(seq_handle, ev)) < 0) {
		fprintf(stderr, "error %i at send_event (%s)\n", err, snd_strerror(err));
		exit(EXIT_FAILURE);
	}
	snd_seq_drain_output(seq_handle);
}

void send_syx_event(unsigned char *data, int len)
{
	snd_seq_event_t ev;
	snd_seq_ev_clear(&ev);
	snd_seq_ev_set_sysex(&ev, len, data);
	send_event(&ev);
}

int main(int argc, char *argv[])
{
	snd_seq_addr_t dest;

	if (argc > 1) {
		port_address = argv[1];
	} else {
		fprintf(stderr, "Usage: amsgsysex SEQUENCER_PORT\n");
		return EXIT_FAILURE;
	}

	if (snd_seq_open(&seq_handle, "default", SND_SEQ_OPEN_OUTPUT, 0) < 0) {
		fprintf(stderr, "Error opening ALSA sequencer.\n");
		exit(EXIT_FAILURE);
	}
	snd_seq_set_client_name(seq_handle, "client name");
	if ((port_out_id = snd_seq_create_simple_port(seq_handle, "output port name",
		SND_SEQ_PORT_CAP_READ|SND_SEQ_PORT_CAP_SUBS_READ,
		SND_SEQ_PORT_TYPE_APPLICATION)) < 0) {
			fprintf(stderr, "Error creating sequencer port.\n");
 			exit(EXIT_FAILURE);
	}
	if (snd_seq_parse_address(seq_handle, &dest, port_address) < 0) {
		fprintf(stderr, "invalid destination address %s\n", port_address);
		return EXIT_FAILURE;
	}
	if (snd_seq_connect_to(seq_handle, port_out_id, dest.client, dest.port) < 0) {
		fprintf(stderr, "invalid connection to %d:%d (%s)\n", dest.client, dest.port, port_address);
		return EXIT_FAILURE;
	}
	send_syx_event(&msg_gmreset[0], sizeof(msg_gmreset));
	snd_seq_close(seq_handle);
	return EXIT_SUCCESS;
}

[linux-audio-dev] [ANN] KMidimon 0.1 (new) & KMetronome 0.5 (updated)

[Pedro Lopez-Cabanillas]

KMidimon 0.1


KMidimon is a MIDI monitor for Linux using ALSA sequencer, with KDE user
interface.

Quoting Dave Phillips in a three parts article for Linux Journal: "At some
point, almost every serious MIDI musician needs to monitor a MIDI data stream,
perhaps to diagnose a malfunctioning piece of equipment or to examine the
contents of a MIDI sequence during playback".

Features:
* Easy to use KDE graphic user interface
* Based on ALSA sequencer
  Provides one input port to be connected to other programs and devices
  using the usual external tools (aconnect, kaconnect, QJackCtl...)
* Customizable event filters and sequencer parameters
* Supports all MIDI messages, including System Exclusive, and ALSA messages
* Saves to a text file (CSV format) the recorded event list
* GPL licensed

Provisional home page:
http://kmetronome.sourceforge.net/kmidimon/

Download:
http://prdownloads.sourceforge.net/kmetronome/kmidimon-0.1.tar.gz?download




KMetronome 0.5
==

KMetronome is a MIDI based metronome using the ALSA sequencer.
This is a maintenance release fixing some compilation and runtime bugs.
Please upgrade.

Home page:
http://kmetronome.sourceforge.net/

Download:
http://prdownloads.sourceforge.net/kmetronome/kmetronome-0.5.tar.gz?download

Changes
---
release 0.5
* autosave window settings (size...)
* apply tempo/resolution when accept changes in configuration dialog
* fixed bug in sequencerthread: set_program event must be direct.
* other minor changes

release 0.4
added features
* Internal connection management now remembers the input port connection.
* new setTempo and setTimeSignature functions added to the DCOP interface.
fixed bugs
* fixed compilation problem under Fedora Core 3
* fixed some automake problems

Re: [linux-audio-dev] Rosegarden: All Notes OFF

[Pedro Lopez-Cabanillas]

On Thursday 25 November 2004 18:02, Chris Cannam wrote:
> On Wednesday 24 Nov 2004 22:06, Jens M Andreasen wrote:
> > According to my oldish midi-spec, controller (decimal) 120 is
> > undefined, so I was somewhat confused at first when I got it from
> > Rosegarden.
> >
> > A bit of digging shows that it belongs to the (newish?) GS-spec, and
> > means All-Sound-Off (as in 'killall -9')
>
> Ah, that controller.
>
> This is what happens when you rely on public interpretations of a
> proprietary spec.  Quite a few sources claim this controller _is_ in
> MIDI 1.0, and since most contemporary synths interpret it as expected
> (silencing all notes even if sustain is active), the matter wasn't ever
> really questioned.

Well. Here is an official source that claims that control change 120 is in 
MIDI 1.0 (1995 revision). It is not the whole MIDI 1.0 spec, only a summary.

http://www.midi.org/about-midi/table1.shtml

Channel Mode Messages  (See also Control Change, above)
-
1011 0ccc Channel Mode Messages.
 0vvv This the same code as the Control
  Change (above), but implements Mode
  control and special message by using
  reserved controller numbers 120-127.
  The commands are:

  All Sound Off.
  When All Sound Off is received
  all oscillators will turn off, and
  their volume envelopes are set to
  zero as soon as possible.
  c = 120, v =   0: All Sound Off

[...]

The book "MIDI programmer's handbook", (C) 1989 by DeFuria & Scacciaferro, 
does not mention this controller. I guess that ancient MIDI instruments  
manufactured before the 1995 revision can't be blamed if they aren't fully 
compliant.

Regards,
Pedro

Re: [linux-audio-dev] cli midi

[Pedro Lopez-Cabanillas]

On Monday 22 November 2004 18:07, Hans Fugal  wrote:
> Is there an app that will dump midi events in human-readable format to
> stdout (or a file, or gui window, whatever)? Preferably it would work on
> SMF as well as realtime (ALSA), and have filters to filter out
> undesirables (e.g. active sensing or perhaps sysex).

The following utilities are included on newest alsa-utils packages. Both can 
print the incoming MIDI events as human readable text in realtime.

amidi (using ALSA raw MIDI interface)
   amidi  is a command-line utility which allows to receive and send SysEx
   (system exclusive) data from/to external MIDI  devices.   It  can  also
   send any other MIDI commands.

  -d, --dump
  Prints data received from the MIDI port  as  hexadecimal  bytes.
  Active  Sensing  bytes  (FEh)  will  not be shown, unless the -a
  option has been given.

arecordmidi (using ALSA sequencer)
   arecordmidi is a command-line utility that records a Standard MIDI File
   from one or more ALSA sequencer ports. 

   -d,--dump
  Shows the events received as text on standard output.

For SMF files, both Fluidsynth and Timidity can do so. 
$ timidity -idvvv music.mid
$ fluidsynth -v music.mid

You can also try my little utilities in C and Pascal, including a midi monitor 
utility with GUI interface for Kylix that you can find here: 
http://perso.wanadoo.es/plcl/

Regards,
Pedro

Re: [linux-audio-dev] a question re: the MIDI spec

[Pedro Lopez-Cabanillas]

On Friday 10 September 2004 Martijn Sipkema wrote:
> The problem here is that class compliant devices suffer bad timing
> because they use bulk transfers for MIDI data. The standard for
> MIDI over FireWire is much better.

I don't agree on the subject that USB bulk transfers cause bad MIDI timing.  
Of course, you can't use the same USB host controller at a time with a MIDI 
interface and some other device like a CD writer and expect both good MIDI  
timing and fast CD burning. If you can reserve a host controller exclusively 
for your USB MIDI device, you will get pretty good results, most of the time.

There are four USB data flow types, Control transfers and:
- Bulk transfers are used to request or send reliable data packets up to the 
full bus bandwidth. Devices like scanners or scsi adapters use this transfer 
type. 
- Interrupt transfers are similar to bulk transfers which are polled 
periodically. If an interrupt transfer was submitted the host controller 
driver will automatically repeat this request in a specified interval (1ms - 
255ms). 
- Isochronous transfers send or receive data streams in realtime with 
guaranteed bus bandwidth but without any reliability. In general these 
transfer types are used for audio and video devices.
(quoted from http://wwwbode.cs.tum.edu/Par/arch/usb/usbdoc/node8.html)

MIDI streams need to be reliable (a single byte lost isn't acceptable), so 
Isochronous is not an option. Interrupt or Bulk transfers are very similar: 
they use only the available bandwidth at each moment, so there can be 
unwanted delays and timing problems. Some manufacturers' proprietary 
protocols include a timestamp with each USB MIDI packet to enhance the time 
accuracy, but this can be done either in bulk or interrupt transfers.

Regards,
Pedro

 

Re: [linux-audio-dev] a question re: the MIDI spec

[Pedro Lopez-Cabanillas]

On Friday 10 September 2004 Eric Dantan Rzewnicki wrote:
> On Thu, Sep 09, 2004 at 07:18:57PM +0200, Pedro Lopez-Cabanillas wrote:
> > And now Avid (the company owning Digidesign) bought M-Audio. 
[...]
> Really!?! when did that happen? 

http://www.avid.com/company/releases/2004/040820_acquisition.html
http://www.m-audio.com/index.php?do=media.new&ID=503e85ec37f1003524a4455fcfb32b1f
http://www.m-audio.com/images/en/press_releases/Avid-M-Audio_PR.doc

Regards,
Pedro

Re: [linux-audio-dev] a question re: the MIDI spec

[Pedro Lopez-Cabanillas]

On Thursday 09 September 2004, Clemens Ladisch wrote:
> M-Audio started following suit only after they hung their engineers
> with a USB cable and bought Evolution who had always made
> class-compliant devices.

And now Avid (the company owning Digidesign) bought M-Audio. I hope to see the 
engineers that made the MBox hanging in the end of an USB cable.

Regards,
Pedro

[linux-audio-dev] Cakewalk file format

[Pedro Lopez-Cabanillas]

Hi,

I've posted the following message in Rosegarden-devel mailing list, and  
Michael pointed me to an old thread from you about the same subject:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03322

Attached is a little program summarizing what I have found about the file 
format at this moment. I would like to know if you have more information, 
ideas or want to collaborate in this task.

Regards,
Pedro

On Sunday 29 August 2004 01:50, Pedro Lopez-Cabanillas wrote:
> Hi,
>
> I have many old songs, stored as Cakewalk "WRK" files, and I don't use
> Cakewalk or Sonar anymore. I'm not planning to do so in the future, 'cause
> I'm sure I will use Rosegarden. Of course.
>
> So, I need to convert my old WRK files to Rosegarden. But the WRK file is a
> closed format, and not publicly documented. It will be necessary to reverse
> engineer it, to rescue my old loved melodies along with the pile of shit.
>
> My plan is to first write a 'cake2rg' standalone utility, to start learning
> the file format and meanwhile to produce some practical results. After
> that, I hope to be able to import the files directly into Rosegarden. This
> won't happen before 1.0-final.
>
> If somebody had the same idea and has the work almost finished, please let
> me know ;-). Let's avoid duplicated work.
>
> Comments, please.
>
> Regards,
> Pedro
/*
* Cakewalk (WRK) file format test
*
* Copyright (c) 2004 Pedro Lopez-Cabanillas  All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/


#include 
#include 
#include 

FILE *file;
char *buffer;
char *HEADER = "CAKEWALK";
int vma, vme;

#define BUFSIZE 	1024

#define TRACK_CHUNK	1
#define STREAM_CHUNK	2
#define VARS_CHUNK	3
#define METER_CHUNK	4
#define TEMPO_CHUNK	5
#define SYSEX_CHUNK	6
#define MEMRGN_CHUNK	7	// ???
#define TIMEBASE_CHUNK	0x0A	// if present should be the first chunk in the file.
#define END_CHUNK	0xff

void readBuffer(long count)
{
	if (count > BUFSIZE)
		fseek(file, count, SEEK_CUR);
	else
		fread(buffer, count, 1, file);
}

void readFileVersion()
{
	fgetc(file);
	vme = fgetc(file);
	vma = fgetc(file);
}

int readChunk()
{
	int len;
	int ck = fgetc(file);
	if (ck != END_CHUNK) {
		fread(&len, sizeof(len), 1, file); // not portable
		readBuffer(len);
	}
	printf(" %02x", ck);
	return ck;
}

void cakeTest(char *fileName)
{
	int ck_id;
	printf("File: %s\n", fileName);
	file = fopen(fileName, "r");
	if (!file) {
		printf(" Error reading the file\n");
	} else {
		readBuffer(strlen(HEADER));
		if (strcmp(buffer, HEADER)) {
			printf(" Bad file format\n");
		} else {
			readFileVersion();
			printf(" file version: %d.%d\n", vma, vme);
			printf(" file chunks:");
			do
ck_id = readChunk();
			while (ck_id != END_CHUNK);
			fgetc(file);
			printf("\n");
			if (!feof(file)) {
printf(" Corrupted file\n");
			}
		}
		fclose(file);
	}
}

int main(int argc, char *argv[])
{
	int i;
	buffer = malloc(BUFSIZE);
	for (i = 1; i < argc; i++)
		cakeTest(argv[i]);
	return EXIT_SUCCESS;
}

Re: [linux-audio-dev] MIDI files contain strange byte sequences ?

[Pedro Lopez-Cabanillas]

El Sábado, 9 de Agosto de 2003 18:00, Benno Senoner escribió:
> Basically I read the  MTrk shown below and after the
> ff 01 TEXT meta event which contains the text 'Reset Volume'
> there are sequences of 00 07 7f till the next ff 01 text event
> 'Reset Pan'.
> But the midi file spec says that after each event (the Reset Volume text)
> you need to read the deltatime (0 in this case) and then read the status
> byte in that case 7 means running status active thus another
> text event should follow.
> so you interpret ff 7 as META_CUE event of length 127.
> But this does not make sense since there are no 127 bytes following.
> That way the midi reader gets lost and aborts.

IIRC, sysex events and meta-events cancel any running status which was in 
effect. Running status does not apply to and may not be used for these 
messages. 

If the above rule was applied, you can't assume 0xff as a running status byte  
and use it for the next messages after the text meta-event, but in this case 
there is not a status byte for them. If the rule was half-applied, then may 
be a running status of 0xb1 from the message preceding the meta-event, which 
makes sense because the text says 'Reset Volume' and 07 is the volume 
controller number.

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com

Re: [linux-audio-dev] Please test my MidiSport firmware loader

[Pedro Lopez-Cabanillas]

Good hack, Clemens!

> I've created a package which extracts the firmware for MidiSport devices
> from the Windows driver files and installs the hotplug script to download
> the firmware. You can get it at
> >.
>
> There are some differences to Lars Doelle's GPL firmware:
> - it supports MidiSport 4x4/8x8/Keystation/Oxygen
> - no configuration file editing, just 'make install'
> - it requires ALSA because the Midiman firmware doesn't conform to the USB
>   MIDI specification
>
> I don't have a MidiSport device, so this is completely untested.

As Fernando said, it works. I have a Midisport2x2, but I don't need the 
Midiman's firmware, because my Midisport2x2 works very well with ezusbmidi 
firmware by Lars Doelle, but this can be useful for 4x4 and 8x8 owners... 
while there is not a better GPL solution.

BTW, the latest midisport GPL firmwares and sources are available at 
linux-hotplug project CVS repository:
http://sourceforge.net/cvs/?group_id=17679
(modulename "firmware")

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com