MIDI Merger , MIDI Splitter

ansolas · March 20, 2006, 4:39pm

Hallo,

ich ich plane mir einen Midimerger zu bauen.

Allerdings benötige ich einen gröÃŸeren als 2 in 1.

Gibt es eine Möglichkeit einen auf dem MIDImerger Project basierenden gröÃŸeren merger zu bauen?

Wenn ja wie gehe ich hierbei vor.

Neben dem merge benötige ich noch einen MIDISplitter(1 zu n) der das MIDI signal aufteilt.

Gibt es hierfür auch eine Möglichkeit ?

GruÃŸ

ansolas

T.K · March 20, 2006, 5:10pm

Hallo,

so etwas befindet sich gerade in der Mache:

(nicht von dem USB Kabel verwirren lassen, das MIDI Processing laeuft auch ohne USB)

Mehr Details dann nach meinem Urlaub…

Gruss,

Thorsten.

ansolas · March 20, 2006, 8:18pm

Sehr Geil, das freut mich. Wie siehts aus mit dem Splitter ?

GruÃŸ

ansolas

T.K · March 20, 2006, 9:14pm

Der Core laesst sich in MIOS-C programmieren (es wird also keine GUI zum Konfigurieren oder aehnliches geben). Das bedeutet wiederum: alles ist moeglich, selbst die abgefahrenen Sachen

Gruss,

Thorsten.

ansolas · March 20, 2006, 9:21pm

Hallo,

das klingt gut. Die einzigen Programmier Erfaqhrungen die ich habe sind ind JAVA.

Ist die MIOS-C Programmierung schwer zu erlernen?

GruÃŸ

ansolas

ilmenator · March 20, 2006, 9:38pm

Nein, mit den Beispielen, die es auf der http://www.ucapps.de/mios_c.html Seite gibt, ist das wirklich sehr einfach - ich spreche da aus eigener Erfahrung… Auch etwas komplexere Dinge kann man als Neuling problemlos in einer Woche zusammenbauen.

GrüÃŸe, ilmenator

ansolas · March 20, 2006, 9:42pm

FREU !!!

T.K · March 24, 2006, 9:28pm

Mittlerweile hat das Projekt den Status erreicht, in dem ich es mal praxisnah testen kann.

So sieht mein momentanes Routing aus:

Manche Browser schneiden das Bild an der rechten Seite ab - hier die komplette version:

http://www.ucapps.de/midi_router/midi_router_default.gif

Und so der Code in router.c (meiner Meinung nach ist es noch einigermassen ueberschaubar

/////////////////////////////////////////////////////////////////////////////
// These functions are called from the MIDI parser when a new package has been
// received. They can be modified to customize the routing
//
// evnt0, evnt1, evnt2: the bytes of the MIDI event which has been received
//
// ptype: package type
//  - 0x02  two-byte system common message like MTC, Song Select, etc.
//  - 0x03  three-byte system common message like SSP, etc.
//  - 0x04  SysEx starts or continues
//  - 0x05  SysEx ends with following single byte
//  - 0x06  SysEx ends with following two bytes
//  - 0x07  SysEx ends with following three bytes
//  - 0x08  Note Off
//  - 0x09  Note On
//  - 0x0a  Poly-Key Pressure
//  - 0x0b  Control Change
//  - 0x0c  Program Change
//  - 0x0d  Channel Pressure
//  - 0x0e  Pitch Bend
//  - 0x0f  single byte like MIDI Clock/Start/Stop/Continue
/////////////////////////////////////////////////////////////////////////////
void ROUTER_Rx_INT0(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
  // Core MIDI IN, connected to my PC

  // lock/release this routing path on SysEx streams
  ROUTER_LockPathOnSysEx(PORT_INT0, ptype);

  // forward data to the MIDI OUTs of all IIC slaves
  ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2);
  ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2);
  ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2);
  ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2);
}

void ROUTER_Rx_IIC0(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
  // IIC0: connected to my MIDIbox SID

  // lock/release this routing path on SysEx streams
  ROUTER_LockPathOnSysEx(PORT_IIC0, ptype);

  // forward data to the Core MIDI OUT
  ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2);
}

void ROUTER_Rx_IIC1(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
  // IIC1: connected to my MIDIbox FM

  // lock/release this routing path on SysEx streams
  ROUTER_LockPathOnSysEx(PORT_IIC1, ptype);

  // forward data to the Core MIDI OUT
  ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2);
}

void ROUTER_Rx_IIC2(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
  // IIC2: connected to my MIDIbox SEQ

  // lock/release this routing path on SysEx streams
  ROUTER_LockPathOnSysEx(PORT_IIC2, ptype);

  // forward MIDI clock/start/stop/continue to all IIC modules
  if( evnt0 >= 0xf8 && evnt0 <= 0xfc ) {
    ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2);
    ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2);
    ROUTER_Tx_IIC2(ptype, evnt0, evnt1, evnt2);
    ROUTER_Tx_IIC3(ptype, evnt0, evnt1, evnt2);
  }

  if( (ptype >= 0x08 && ptype <= 0x0e) && ((evnt0 & 0x0f) >= MIDI_CHN9) ) {
    // directly forward MIDI channel #9..#16 messages to MIDIbox SID and MIDIbox FM only
    ROUTER_Tx_IIC0(ptype, evnt0, evnt1, evnt2);
    ROUTER_Tx_IIC1(ptype, evnt0, evnt1, evnt2);
  } else {
    // forward all other events to the Core MIDI OUT
    ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2);
  }
}

void ROUTER_Rx_IIC3(unsigned char ptype, unsigned char evnt0, unsigned char evnt1, unsigned char evnt2) __wparam
{
  unsigned char transposed_note;

  // IIC3: connected to my Yamaha AN1x

  // lock/release this routing path on SysEx streams
  ROUTER_LockPathOnSysEx(PORT_IIC3, ptype);

  // if note on/off at channel #16 has been received, change it in the
  // following way:
  // - send notes <  C-4 to MIDIbox SID (IIC0), Channel #9
  // - send notes <  C-4 to MIDIbox SEQ (IIC2), Channel #1, transposed by 2 octaves
  // - send notes >= C-4 to MIDIbox FM (IIC1),  Channel #13
  if( (ptype >= 0x08 && ptype <= 0x09) && ((evnt0 & 0x0f) == MIDI_CHN16) ) {
    if( evnt1 < 0x3c ) { // evnt1 contains note number, 0x3c is C-4
      ROUTER_Tx_IIC0(ptype, (evnt0 & 0xf0) | MIDI_CHN9, evnt1, evnt2);

      transposed_note = evnt1 + 2*12;
      while( transposed_note > 127 ) // avoid invalid notes,
transposed_note -= 12;      // transpose back until note number <= 127
      ROUTER_Tx_IIC2(ptype, (evnt0 & 0xf0) | MIDI_CHN1, transposed_note, evnt2);
    } else {
      ROUTER_Tx_IIC1(ptype, (evnt0 & 0xf0) | MIDI_CHN13, evnt1, evnt2);
    }
  }

  // forward data (also) to the Core MIDI OUT
  ROUTER_Tx_INT0(ptype, evnt0, evnt1, evnt2);
}
[/code]









Die USB Option kommt hier nicht zum Einsatz, dies wird ein separates Projekt (da MIOS auf



dem PIC18F4550 aufgrund diverser Silicon Bugs nicht sauber laeuft)







Bei USB gibt es dann 8 zusaetzliche Rx/Tx Kanaele, die man ebenfalls beliebig "verdrahten" kann.







Gruss,



&nbsp; &nbsp; &nbsp; &nbsp; Thorsten.

Jack · March 25, 2006, 11:01am

Hallo Thorsten!

Kann ich Dir als USB den FT232RL empfehlen. Man braucht so gut wie gar keine externen Bauteile und es gibt Ihn bei Reichelt. Einzige bekanntes problem, man muss die alten Treiber verwenden zum proggen und es ist in SSOP 28 gehäuse.

mfg

Jack

T.K · March 25, 2006, 11:19am

Hallo Jack,

die ueberarbeitete (assembler basierte) USB Firmware fuer den PIC18F4550 ist bereits fertig und laeuft stabil. Jemand aus dem Forum entwickelt gerade einen neuen Windows Treiber, der wesentlich performanter als der Legacy M$ Treiber sein wird. Linux und Mac User koennen wie bei MBHP_USB den normalen USB MIDI Treiber verwenden.

Gruss,

Thorsten.

Jack · March 25, 2006, 11:40am

Hallo TK!

Dass sind sehr gute Neuigkeiten.

Ich werde dann auch mein Companion Board zur verfügung stellen, wenn ich es getestet habe.

mfg

Jack

Jack · April 3, 2006, 8:20am

Hallo TK!

Wird der IIC Takt auf 1 Mhz erhöht?

Ich frage wegen den 24FC EEPROM, die arbeiten mit 1Mhz.

Das würde vor allem das laden der Presets beim SID beschleunigen.

Wie wäre es anstelle von 8x24LC256 gleich 2x24FC1025 zu nehmen. Die gibts es inzwischen auch als PDIP.

mfg

Jack

T.K · April 3, 2006, 9:20am

Hallo,

Wird der IIC Takt auf 1 Mhz erhöht?

Ich frage wegen den 24FC EEPROM, die arbeiten mit 1Mhz.

nein, den Takt kann man nicht erhoehen, es gibt in der Slave Firmware einen kritischen Pfad, der eingehalten werden muss (Delay zwischen zwei empfangenen Bytes) - wenn der Master also zwei Bytes schneller sendet, als der Slave sie weiterverarbeiten kann, kommt es zu einem Not-Acknowledge, und somit zu einem Retry. Die Performance wuerde darunter leiden.

Wie wäre es anstelle von 8x24LC256 gleich 2x24FC1025 zu nehmen. Die gibts es inzwischen auch als PDIP.

kannst Du doch machen…

Gruss,

Thorsten.