Comments on: Bytes, Nibbles & Bits for CoreMidi

By: Bruce

Bruce — Fri, 21 May 2010 06:02:03 +0000

Thanks, that’s a help. When I wrote pattern based, I meant parts actually, a la the Alesis MMT-8. It will alos be a live recorder (packetlists) Don’t know if that changes things. I work best that way, assembling chunks of different and similar sounding parts into songs. Thanks again for your time and thoughts.

[WORDPRESS HASHCASH] The poster sent us ’0 which is not a hashcash value.

By: Robert

Robert — Sun, 09 May 2010 05:03:44 +0000

By: admin

admin — Sat, 08 May 2010 06:20:46 +0000

@Robert
I’m posting this without having had much time to think it through.

I think timing shouldn’t be a big problem. Maybe you could deliver timestamped midi data in 2 measure chunks. Or you could make the chunk size dependent on the tempo of the pattern. The faster the tempo, the higher the chunk size.

As far as how to structure it all, I would probably approach it like below. Mind you, I haven’t spent much time thinking about this.

Song
attributes: name, tempo, followSongOrPatternTempo?
has a playlist

Playlist
has a list of slots.

Slot
attributes: length
has one pattern

Pattern
attributes: name, tempo, length, swing
has 16 tracks
belongs to Song

Track
attributes: name, length, resolution, output, loop
has many steps but resolution determines which steps are active
belongs to a pattern

Step
attributes: active?, accent, index
has one note or controller message
belongs to a track

Note
attributes: pitch, velocity
belongs to a step. time_stamp can be derived from the step.

By: Robert

Robert — Sat, 08 May 2010 05:14:56 +0000

Thanks for the post, and congrats on the paying gig. One of the challenges with my own project is figuring out how to handle the data I will be recording and outputting. It’s a pattern based beast, so will have a minimum 99 patterns of variable lengths, each with 16 tracks…and each track will have all the packet/packetlists and other data associated with that. Not sure how best to ‘struct’ all that. Then my other technical wonderment is going to be how to time all that on the way back out and still deal with interface updates, etc.? There’s not much roadmap for all this. Blogs likes yours and others are helpful, since googling on CoreMIDI provides not much information.

By: admin

admin — Fri, 07 May 2010 14:45:55 +0000

Lol. Shame on me. That weekend never came. I’ll return to the project sometime this month when I’m done with a paying gig

I created a virtual receive port and I went as far as logging the received messages and updating my midi activity monitor. I’ll post what I have done so far and hope you find in useful. If not, I’ll post my complete parser soon.

This is the midiReadProc from my virtual receive port.
static void midiReadProc(const MIDIPacketList *midiPacketList, void *readProcRefCon, void *srcConnRefCon) { [[JXMidiSystem sharedInstance] updateReceiveActivityMonitor];


	int i, j;

	MIDIPacket *nextPacket = (MIDIPacket *)midiPacketList->packet;

	for (j=0 ; j < midiPacketList->numPackets; ++j)

	{

		for (i = 0; i < nextPacket->length; ++i)

		{

			NSLog(@"--%02X", nextPacket->data[i]);
		}

		nextPacket = MIDIPacketNext(nextPacket);

		NSLog(@"MIDIPacketNext");

	}
	//left nibble is 0x9A >> 4

	// right nibble  0x9A % 16

	// status bit >> 127

	//y = ((x >> 4) & 0x0f) | ((x < < 4) & 0xf0); swap nibbles

}

By: Robert

Robert — Fri, 07 May 2010 09:35:45 +0000

Did you get your parser done before you bailed on the project? If so, please do post or email it still. I am working on a 16 track sequencer and I need all the help I can get. Thanks for your other CoreMIDI posts. (All two of them).