[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: New aRts midi interfaces
From:       Pete Goodliffe <pete.goodliffe () pace ! co ! uk>
Date:       2000-12-01 12:44:37
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
>    Hi!
> 
> I wrote some new aRts idl files for midi interfaces. They include
[snip]
> Comments, questions, feedback?

Well, I'll hazard a few comments on the understanding that I don't know
aRts that intimately, so shoot me down if you want!

I was doing a lot of thinking about this kind of thing for the TSE3
library (TSE3.sourceforge.net). I pretty sure that the system I've got
going there is a good approach, perhaps you'd like to have a look.

So my thoughts are:

1) Why does timestamp have sec and usec? Wouldn't it be easier to just
base everything on usecs?

2) I note that you have separate commands for each type of event, a la
libkmid. IMHO this isn't particularly helpful for working in a streamline
manner. The TSE3 approach is more (forgive my probable abuse of IDL syntax)

struct MidiCommand
{
  byte status;
  byte data1;
  byte data2;
};

enum MidiCommandStatusBytes
{
  MidiCommand_NoteOff = 0x08,
  MidiCommand_NoteOn  = 0x90
  // etc
};

struct MidiEvent
{
  TimeStamp time;
  byte      command;

  // if command is a NoteOn then this is used to hold the related note off
  // this is a TSE3ism that may want to be ignored, however, it can be 
  // useful to have such a grouping to help some stream-based operations
  TimeStamp offTime;
  byte      offCommand;
};

interface MidiPort
{
  MidiEvent rx();
  void      tx(MidiCommand); // sends now
  void      tx(MidiEvent);   // queue, can only be txed in time order
};



This is more than a subtle difference, since it allows you to add blocks
that process MidiEvents in a stream. For example, I have an interface
for objects that can generate a stream of events in time order to
facilitate this.

If you want more info I can elaborate.

Now, I'd understand if you choose to ignore this, however the TSE3 approach
is stable and proven to work quite neatly, perhaps it would bear a little
more looking into?

oh, one other thing I's like to check, I /presume/ that the nature of your
design is such that several apps can be multiplexed onto a single
destination? Or there are simple destinations that can do a multiplexing
as a kind of 'stream operation'

Cheers,

Pete

-- 
Pete Goodliffe, Senior Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518579
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.pace.co.uk/
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]