RE: [linux-audio-dev] Attn : Hardware Jockeys : Solution to Midi problem

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] Attn : Hardware Jockeys : Solution to Midi problem
From: Pieter Palmers (pieter.palmers_AT_student.kuleuven.ac.be)
Date: Mon Mar 11 2002 - 14:44:44 EET


Hi Erik,

I am the initiator of the 'hardware' discussion, and I am pleased to see
that it's still in the thoughts of some people.

As a matter of fact, I'm working on a similar MIDI project, as a starter.
I assumed it would be better to address a simpler domain first. So now
I'm playing around with some MIDI equipment. So you got my attention :)

But I made the descision that I want to finish my thing first... I have
too much unfinished designs in my drawer... but nothing really finished.
So I first want to prove for myself that I'm capable of actually finishing
something.

The reason I wrote the preceding is that I want you to understand the
context of the following text. Think of this as an excercise for myself:
easy but must be finished.

So what am I doing?

A simple MIDI device:
        - 4+2 channels MIDI I/O (4 on UART + 2 On µController)
        - Stand-alone possible
        - Some kind of interface to PC (don't know wich... USB? Serial? Ethernet?)
        - A few external controls & indicators.

What I'm trying to build is:
        - Something that can serve as a MIDI interface
        - but is also usefull as a stand-alone / live performance tool
                e.g. > MIDI routing
> MIDI effects (arpeggiator/easy chords/...)
> Instant device configuration of all devices connected by one
                          button (press the button and all devices are ready to go)
        - Is very flexible.

I'm using a PIC17C756 board I already had...
        it has an expansion connector (usefull for extra UART and PC-interface)
        FLASH program memory (ROM firmware that permits uploading programs via
serial port)
        2 serial interfaces
        more µC stuff that could be usefull (user interface etc...)

It has some features not really needed for this purpose, but for prototyping
it's great.

The thing is: The hardware part is nice, but without software it isn't worth
anything...
And software for this kind of thing has multiple 'levels'.
What I have come up with is:
        - Some sort of on-chip API kind of thing (vague, I know) to handle all
hardware
          related functions (i.e. MIDI send)
        - Some kind of PC app that makes it easy to configure the device.

Let me try to explain a little further:
What I want from the user app is to enable non-technical users to use the
device. It should
be easy... e.g. making a complex MIDI router should be nothing more than
drawing some arrows,
or having a 'virtual patchbay'. Adding an arpeggiator should be nothing more
than a menu option
'Add arpegiator module', and drawing some arrows.

So the choices I have to make are: what do I include in the API?
The most flexible option is to let the user app generate PIC assembly for
the µC. That way the
technical users can generate their own 'modules' themselves. The app then
uploads the firmware
to the FLASH and we are ready to go... But that might be a little hard.

On the other extreme we have the uploading of some sort of 'jump table' or
'routing table' that
tells the device what firmware methods to invoke... it would be more like
'configuring' the pre-
defined functions of the device.

I think it would be nice to have some basic API functions, like
MIDISend(port, channel, message)
MIDIRoute(in_port, in_chan, out_port, out_channel)
etc...

and have a user app generate a program that uses those API functions.
Something like:

If a user would wants this routing:
(port,channel) <-> (port, channel)
( A , 1 ) ( B , 1 )
( A , 2 ) ( B , 10 )
( A , 3 ) ( C , 5 )
( A , 4 ) ( D , 16 )

And would like an arpegiator on the notes played on (A, 5)
The program should generate something like this:

/* generated code starts here*/

EntryPointAfterResetAndInit

/* setup routing */
MIDIRoute(A,1,B,1)
MIDIRoute(A,2,B,10)
MIDIRoute(A,3,C,5)
MIDIRoute(A,4,D,16)

while 1
        /* do the arpegiator */
        noteIn=MIDIReadNote(A,5)

        if (noteIn != 0xFF) then /* assume that 0xFF means 'no note' */
                Arpeggiate(A,5,noteIn,arpeggType)

        DoAllOtherStuff /* API function to do all nescessary processing */

loop

/* The arpeggiate function */

function Arpeggiate (port, channel, note, profile) {
        /* User generated code to perform an arpeggio */
}

/* end of example */

I don't know in what extent this is possible... I assume I will need some
sort of
(modified) assembler or so, but in an open-source community that's no
problem, is it?

My biggest problem is that the API and the abstraction levels should be very
well defined,
and very well thought about.

So, what do you guys think?

Pieter

>
> Hi People,
>
> A couple of months ago we had a number of people on this list keen
> on the idea of designing high quality audio I/O hardware. Having
> designed this kind of stuff myself and knowing how hard this is
> without the proper resources I did my best to disuade them.
>
> We have also just recently had an interesting discussion of how hard
> it is to do Midi correctly on modern multi-purpose OSes like Linux.
>
> I have therefore come up with an idea to satisfy these two goups
> simultaneously; a high quality Midi I/O interface which would
> provide 8 or more Midi Ins and Outs and guarantee accurate Midi
> timing.
>
> High Quality Midi I/O Proposal
> ==============================
> This Midi I/O interface uses an external processor to take care of
> all Midi scheduling and routing. All Midi messages sent to and
> receieved from the host are time stamped.
>
> The interface itself is a PCI board containing a CPU with an
> embedded PCI interface. A good example of this is the PLX iop480
> (see link [1] below), a 32 bit PPC core which can connect directly
> to the PCI bus. Connected to this processor are however many serial
> UARTs are required for the Midi I/Os.
>
> Once you have the hardware the software consists of two parts:
>
> - A linux device driver which talks the PPC chip via the PCI
> bus.
> - Software running on the PCC chip handling interrupts and
> communicating with the Linux host.
>
> The software running on the PPC does not really need an OS. It could
> just be an single monolithic application. This software should allow
> the routing of Midi signals between arbitrary inputs and outputs
> without any intervention from the host OS other than the initial
> specification of how signals are routed. Another possibility would
> be the addition of a plugin architecture allowing the programming
> of Midi processing plugins.
>
> [1] http://www.plxtech.com/products/iop480/
>
> ------------------------------------------------------------------
>
> I wish I had the time to fiddle about with this myself but unfortunately
> I don't.
>
> However, if anyone one wants to attempt this project I would suggest
> you start by getting hold of the Rapid Development Kit (ie a prebuilt
> prototype board ready to be plugged into a PC) which costs about
> US$995. The chip itself costs about US$50 each in low volumes.
>
> Erik
> --
> +-----------------------------------------------------------+
> Erik de Castro Lopo nospam_AT_mega-nerd.com (Yes it's valid)
> +-----------------------------------------------------------+
> A sufficiently advanced programming error is
> indistinguishable from the Windows 95 Operating System.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Mar 11 2002 - 14:32:26 EET