Skip to content

Releases: ravelox/pimidi

Sync fix

14 Feb 18:18
Compare
Choose a tag to compare

Discovered by @pierz, the code responding to a SYNC (CK) message was getting into a loop. This code fixes that.

Minor fixes

05 Jan 06:08
Compare
Choose a tag to compare

This release contains a couple of fixes identified by @pierz.

  1. Incorrect parsing of the remote connection host name in the configuration file.
  2. Unnecessary free of socket information when socket information can't be obtained.

Inbound RTP MIDI fixes

28 Sep 14:50
Compare
Choose a tag to compare

This release addresses issue #86 where inbound MIDI over RTP was not being correctly parsed if there were multiple MIDI events in the payload.

Performance improvements

24 Sep 04:37
Compare
Choose a tag to compare

This release has a number of changes under the hood to make raveloxmidi more performant. Thanks go to karnevil9 for sticking with this one.

Firstly, there are is a new thread responsible for sending MIDI events out to listeners. Previously, data from ALSA devices was read into a buffer and then parsed down to each MIDI event. Once that data was parsed, the events were sent out. With this new thread, as each MIDI event is discovered, it will be written to a queue for the new thread to send immediately.

I've also rationalised the amount of thread locking to avoid contention.

Additionally, there are a couple of new configuration options:

journal.write
If set to yes it will enable the MIDI recovery journal. The default is no.

logging.hex_dump
If set to yes, data buffers are dumped out to the debug log. This can slow performance for large data buffers. The default is no.

Finally, for debugging, additional logging can be generated for each memory allocation and release. An environment variable RAVELOXMIDI_MEM_FILE can be set to the name of a file to log the extra information into. This should only be enabled on request.

Fix double free

03 Jul 02:37
Compare
Choose a tag to compare

Thanks to karnevil9 for stumbling across this in issue #81 . If the alsa.input_buffer_size is set to anything other than 4096, there is a segmentation violation when running as root.

This release fixes that.

Fix compilation errors

28 May 04:30
Compare
Choose a tag to compare

This fixes a build problem on ArchLinux that's not seen on CentOS, Ubuntu or Raspbian.
It also fixes a build problem on CentOS that's not seen on the other platforms. Go figure :)

V0.9.0 - Big changes

16 May 18:39
Compare
Choose a tag to compare

V0.9.0

There are some big changes under the hood that fix a lot of problems that people were having.
Specifically, I've refactored the MIDI parsing so that each connection has its own state machine to handle data coming in multiple directions.

Many thanks go to a number of users who raised issues:

mganss who did some intense code inspection.
qzic
alpho-gav
vldp2000
mrsstaceyseigle
TheTechnobear

If I missed out your name, don’t think I didn’t appreciate that you took time out of your life to help improve the software.

Specific differences in this version

Some specific changes that might affect you, if you have been running the code from the master branch in the past and haven’t been testing the experimental code.

Changes to data on the local port

If you are sending data to the local port ( default is 5006 ) and are prefixing that data with the 0xAA byte, you need to stop adding that prefix.

There was an original design reason for needing that byte but all the refactoring has removed the need for that. All the example scripts in the python/ directory have been corrected for that.

remote.use_control has been renamed

The setting remote.use_control has changed to remote.use_control_for_ck
The functionality remains the same but I wanted the setting name to be more descriptive.

New features

Multiple ALSA input or output devices

You can specify multiple ALSA input or output devices in the configuration file.

For example, if there is a parameter called alsa.output_device you can use either:

alsa.output_device = device_name

or

alsa.output_device.0 = first_device
alsa.output_device.1 = second_device

A multi-value configuration option must start at index 0 and parsing will stop when there is a break in the sequence. That is, if the values are 0,1,3,4,5 then only 0 and 1 will be detected.

Command set for local port

The code has been in for a long while but raveloxmidi provides a simple set of commands for shutdown, heartbeat and connection status.

The commands can only be received on the local listening port ( default is 5006 ). The commands are:

STAT
This is the heartbeat command. The response will always be OK if raveloxmidi is running. The script python/send_stat.py is available for this command.

QUIT
This will shut down raveloxmidi. The response will always be QT to indicate that the command has been received. The script python/send_quit.py is available for this command.

LIST
This requests a lists of current connections into raveloxmidi. The response will be a JSON blob of information. The script python/send_list.py is available for this command.

The JSON data looks like this:

~/pimidi/python$ ./send_list.py | python -m json.tool

{
    "connections": [
        {       
            "control": 5004,
            "ctx": "0x556d380bac30",
            "data": 5005,
            "host": "192.168.1.145",
            "id": 0,
            "initiator": "0x19495cff",
            "send_ssrc": "0x2dfec3cc",
            "seq": 1,
            "ssrc": "0x4181a596",
            "start": 15861082588188,
            "status": "idle"
        }       
    ],
    "count": 1
}

I'll be working on also including the ALSA devices in a future update.

To parse the data, the count field will be the number of connections in the list. The connections array holds each connection. The id field in the connections array is an internal id for the array. The value of that field may change. It is recommended that you use the ssrc field as the uniq identifier for the connection.

New setting alsa.writeback

If a MIDI command is received from an inbound ALSA device, this option controls whether that event is written to an ALSA output device if it has the same card number.
This is a yes/no option. Default is no.

There is also an associated setting alsa.writeback.level which can be either "card" (hw:X,,) or "device" (hw:X,Y,*) ( default is "card" ). This determines the level that the writeback prevention operates.

New setting "read.ring_buffer_size"

This is more of an internal setting but it controls the space available for reading data from input connections or devices. The default ( and minimum ) is 10K ( 10240 bytes ).

Log entries now include microseconds (usecs)

As I've added threads for extra functionality, I needed microsecond resolution in the debug logs so I can see when specific events are occurring,

Segviol fix

15 Mar 20:21
Compare
Choose a tag to compare

This release addresses a segmentation violation reported in issue #68 when receiving an AppleMIDI CK message for a ssrc that hasn't connected.

Remote connection to rtpMIDI

31 Dec 20:10
Compare
Choose a tag to compare

This release addresses issue #47 when making a remote connection to rtpMIDI.

rtpMIDI doesn't hear CK (AppleMIDI Feedback) messages when they are sent over the control port.

To correct this, a new config item is available:

remote.use_control = no

which will ensure that rtpMIDI will respond.

Local socket data handling

30 Dec 17:26
Compare
Choose a tag to compare

The major change to this release could break implementations using the local data socket on (default) port 5006.

This was Identified in issue #43 by TheTechnobear where data is being read in chunks. The original implementation was expecting a full MIDI command in each read and so was coded so that the local socket data was always prefixed by a 0xaa identifier byte.

I was sharing code to parse local data socket data and also ALSA rawmidi data. In the case of rawmidi, I was faking the 0xaa prefix.

Where the data is in chunks, that 0xaa byte was injected in the middle of a MIDI command and that caused infernal loops and memory exhaustion.

To fix this, I had to remove the need for the 0xaa identifier byte.

This means if you have code which is sending the 0xaa byte, you will need to remove it. I apologise for the incovenience but there wasn't a way around it.

Addtionally in this release, big thanks go to Michael Ganss for spending some time to investigate and address some code analysis items. The first few of his suggestions have been incorporated into this release.