headers
rdxesy | 12 Apr 2011 05:25
Picon
Favicon

handling truncated sysex

greetings,

i am thinking the following but i am not sure if this is
a) actually the correct way to detect truncated sysex and if so
b) is always correct:

read event;
for (each byte in the event)
{
...
if (byte == MIDI_SYSEX)
{
	receiving_sysex = true;
	position = 0;
...
}
if (receiving_sysex)
{
	// ignore truncated sysex
	if (position > 0 && byte >= 0xF0 && byte != 0xF7)
	{
		receiving_sysex = false;
		break; 	// assume other bytes to be garbage (correct?)
	}
	...
	++position;
	...
}
...
}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roger Dannenberg | 12 Apr 2011 19:58
Picon
Favicon

Re: handling truncated sysex

Even I had to reread the documentation to remember the rules. You should 
not be checking each byte in each event for status bytes -- status bytes 
(except for End-of-Sysex) will only be in the first byte of any given event.

So, once you see a MIDI_SYSEX in the first byte of an event, you should 
start looking for end-of-sysex in the remaining 3 bytes. In subsequent 
messages, if the first byte is a real-time status byte, process the 
message as a real-time message and resume sysex processing on the next 
message. If the first byte is a non-real-time and non-end-of-sysex 
status byte, the sysex message has been truncated and you will not 
receive any more bytes for it. Otherwise, the message must be more sysex 
data. Process the bytes one-at-a-time and if you find an end-of-sysex 
byte, you've finished processing the sysex message.

I think the mm program (Midi Monitor) has code to fully parse the 
incoming MIDI stream, so you might be able to use that as a reference.

-Roger

On 4/11/11 11:25 PM, rdxesy@... wrote:
> greetings,
>
> i am thinking the following but i am not sure if this is
> a) actually the correct way to detect truncated sysex and if so
> b) is always correct:
>
> ...
Permalink | Reply | 0 comments |
headers
Gregor Richards | 16 Apr 2011 22:24
Favicon

A simpler PortMidi-integrated MIDI file library (or: rocking the boat for fun and profit)

I have a grandiose plan to create a suite of tools for adding human 
tempo and dynamics to a MIDI file, inspired by Tapper[1] but more 
suitable for multitrack works. So I'm writing a series of programs that 
essentially take a MIDI file as input and play it live to a MIDI output 
device, while simultaneously mucking with it based on information from 
another MIDI device (in my case my digital keyboard, Korg NanoKONTROL or 
maybe NanoKEY).

Having had no experience whatsoever with hardware MIDI but a bit of 
experience with MIDI files, I snagged PortMidi and started playing 
around. I was glad to find that it didn't have some complicated 
abstraction layer, just a more-or-less raw connection to the MIDI 
device. Since MIDI isn't very abstract anyway, a couple more #defines 
would make it perfect IMO[2].

Then I started working on MIDI file input. I snagged PortSMF, and ... 
errr, it's C++. OK, I can deal with that. ... uhh, and it abstracts away 
all the MIDI data to these event classes. Then to actually play it you 
have to transform it back. So now I've got input coming in raw form (the 
MIDI input device) and in this highly-baked, abstract form (PortSMF).

Well if you read the subject, you already know the punchline. I gave up 
on PortSMF. I don't want something that abstracts away the MIDI data 
since that just means that I have two different levels of abstraction 
I'm working with. Lucky me, the MIDI file format is really quite simple, 
so I made my own MIDI file library, which I have aptly named 
"midifile".  I threw it into Mercurial: 
http://codu.org/projects/music/midifilehg/ . It's quite simple: It's C, 
its file is just an array of tracks, each of which is just a list of 
events, and the events are just a PortMidi event paired with the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roger Dannenberg | 17 Apr 2011 00:34
Picon
Favicon

Re: A simpler PortMidi-integrated MIDI file library (or: rocking the boat for fun and profit)

Hi Gregor,
     Thanks for your note. I would certainly agree PortSMF is far from 
simple and minimal. PortSMF underlies Audacity Note Tracks, so it has a 
lot of code for editing at the track level, e.g. select, cut, copy, 
paste, insert, serialize, unserialize; plus there are functions for 
working in terms of both beats and seconds. Writing something that will, 
say, cut from A to B, preserving the tempo track information, is 
non-trivial. PortSMF also supports events as attribute/value property 
lists, so it is not restricted to MIDI data. (I wouldn't want to do all 
that work just for MIDI.)
     In the end, however, I think you are right that the abstraction is 
complicated and confusing, especially if you don't really need the 
functionality or you really want the functionality and data model to be 
different.
     I would not object to another MIDI representation in PortMedia. In 
fact, PortSMF has a sub-layer which is a simple SMF parser based on one 
by Tim Thompson. Outside of Audacity and me, I'm not sure if PortSMF has 
users, and I'm not getting bug reports or fixes as contributions.
     Is anyone on the list interested in Gregor's simpler midi file code 
or in PortSMF?

     -Roger
Permalink | Reply | 0 comments |
headers
Johannes Neumann | 19 Apr 2011 15:25
Picon

Problem opening Inputs and outputs with Portmidi

Hallo  <at>  all

This is my first post here, and i have no idea how this whole thing here 
works. So I hope it's not rude, just to ask questions.

I have problems opening a portmidi input or output on windows. 
Information is very rare and I found no examples on the web. I use 
lazarus and i can sucessfully compile my application. I can start 
porttime and get information about MIDI devices. However, when I try to 
open a device, I get a SIGSEGV and my program terminates, giving me no 
chance to read out information about the error that occured. This is how 
I call PM_OpenOutput:

error := Pm_OpenOutput(MIDIOutputStream, devNumber, Nil, 1024, Nil, Nil, 0);
if (error <> pmNoError) then showmessage('Error: ' + 
Pm_GetErrorText(error));

As I said, the error message never appears.
I found this in doxygen:

outputDriverInfo is a pointer to an optional driver specific data 
structure containing additional information for device setup or handle 
processing. outputDriverInfo is never required for correct operation. If 
not used outputDriverInfo should be NULL.

so i assume its safe to pass a "nil" as "outputDriverInfo". The same 
applies to time_proc and time_info:

time_proc is a pointer to a procedure that returns time in milliseconds. 
It may be NULL, in which case a default millisecond timebase (PortTime)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roger Dannenberg | 19 Apr 2011 16:07
Picon
Favicon

Re: Problem opening Inputs and outputs with Portmidi

I'm running to teach class, but here are some general suggestions:
look for readme files at the top-level and in system-specific directories.
I use Visual C++ for testing PortMidi on Windows. It's not a 
requirement, but you might have to do some work to compile sources in 
other environments. If you prepare anything new or fix something old, 
contributions/updates are welcome.
There is example code in pm_test. You might try compiling these in your 
environment to see if they work. They do work when compiled with Visual 
C++ using the existing project  ("solution") files.

-Roger

On 4/19/2011 9:25 AM, Johannes Neumann wrote:
> Hallo  <at>  all
>
> This is my first post here, and i have no idea how this whole thing here
> works. So I hope it's not rude, just to ask questions.
>
> I have problems opening a portmidi input or output on windows.
> Information is very rare and I found no examples on the web. I use
> lazarus and i can sucessfully compile my application. I can start
> porttime and get information about MIDI devices. However, when I try to
> open a device, I get a SIGSEGV and my program terminates, giving me no
> chance to read out information about the error that occured. This is how
> I call PM_OpenOutput:
>
> error := Pm_OpenOutput(MIDIOutputStream, devNumber, Nil, 1024, Nil, Nil, 0);
> if (error<>  pmNoError) then showmessage('Error: ' +
> Pm_GetErrorText(error));
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Neumann | 19 Apr 2011 21:07
Picon

Wrong output when sending sysex using portmidi

Hello!

I have trouble sending sysex via portmidi on a windows platform. When I 
send the following: 0xF0A4A310F7. I receive this one here: 
0xA4000000A310F7. When I send this: 0xF0A4A31010305032F7 i get 
0xA4000000A3101000A3305000A332F7.
I checked the output by plugging a cable from MIDI Out to MIDI In and 
running a midi monitor. Whats wrong?

Thanks for any help,
Johannes Neumann
Permalink | Reply | 3 comments |
headers
Roger Dannenberg | 19 Apr 2011 23:13
Picon
Favicon

Re: Wrong output when sending sysex using portmidi

Johannes,
     Interesting. Is this a Win32 or Win64 platform? and can you say 
more about compilers, OS, midi drivers up-to-date, MIDI interface? I've 
tested on Win32 using the sysex program in pm_test, which has a feature 
to do a loop-back test: it generates random messages of random length, 
sends them, and check the result. You might try this too for another 
data point if you haven't tried it yet. Please let me know what you find.
     -Roger

On 4/19/11 3:07 PM, Johannes Neumann wrote:
> Hello!
>
> I have trouble sending sysex via portmidi on a windows platform. When I
> send the following: 0xF0A4A310F7. I receive this one here:
> 0xA4000000A310F7. When I send this: 0xF0A4A31010305032F7 i get
> 0xA4000000A3101000A3305000A332F7.
> I checked the output by plugging a cable from MIDI Out to MIDI In and
> running a midi monitor. Whats wrong?
>
> Thanks for any help,
> Johannes Neumann
> _______________________________________________
> media_api mailing list
> media_api@...
> http://lists.create.ucsb.edu/mailman/listinfo/media_api
Permalink | Reply | 2 comments |
headers
Andrej Mitrovic | 19 Apr 2011 23:13
Picon

Any interest in D bindings and sample code ports?

I've ported the following files from the pmtest directory to D:
latency.c
midithread.c
mm.c

I haven't ported these yet:
test.c -- I can port this soon.
sysex.c -- Unfortunately I don't have a sysex-enabled device. Perhaps
I could use a virtual midi device for this though.
qtest.c -- Porting is not required. D has a built-in thread messaging system.
midithru.c -- Will do.
midiclock.c -- Will try with a virtual midi device.

And of course the bindings themselves:
portmidi.d -- function prototypes, type definitions, automatically
translated from the C header.
exception.d -- Prints the string retrieved from Pm_GetErrorText() for
any thrown exceptions.
porttime.d -- Currently a little rough translation due to having to
use globals, while D uses thread-local storage by default. So
basically I've used some global variables without any locks which
might introduce data races in unusual circumstances. I'll try fixing
this soon.

I've also included a small "Interact" module (boost-licensed) from
Jesse Phillips, which really simplifies user-input and is used with
some code examples in pt_test. I'll have to ask him for his permission
to include the module, although I don't think there will be any issues
since we're friendly & the module is boost-licensed.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roger Dannenberg | 20 Apr 2011 00:27
Picon
Favicon

Re: Any interest in D bindings and sample code ports?

On 4/19/11 5:13 PM, Andrej Mitrovic wrote:
> I've ported the following files from the pmtest directory to D:
> latency.c
> midithread.c
> mm.c
>
> I haven't ported these yet:
> test.c -- I can port this soon.
> sysex.c -- Unfortunately I don't have a sysex-enabled device. Perhaps
> I could use a virtual midi device for this though.
> qtest.c -- Porting is not required. D has a built-in thread messaging system.
> midithru.c -- Will do.
> midiclock.c -- Will try with a virtual midi device.
>
> And of course the bindings themselves:
> portmidi.d -- function prototypes, type definitions, automatically
> translated from the C header.
> exception.d -- Prints the string retrieved from Pm_GetErrorText() for
> any thrown exceptions.
> porttime.d -- Currently a little rough translation due to having to
> use globals, while D uses thread-local storage by default. So
> basically I've used some global variables without any locks which
> might introduce data races in unusual circumstances. I'll try fixing
> this soon.
>
> I've also included a small "Interact" module (boost-licensed) from
> Jesse Phillips, which really simplifies user-input and is used with
> some code examples in pt_test. I'll have to ask him for his permission
> to include the module, although I don't think there will be any issues
> since we're friendly&  the module is boost-licensed.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane