Jump to content

TK.

Administrators
 View Profile  See their activity

  • Posts

    15,247

  • Joined

 Content Type 

Posts posted by TK.

  3. STM32F4-CORE and LCD-Display

    in Testing/Troubleshooting

    Posted

    Yes, the app_lcd/universal driver is still under construction:

     

    1) I've to change the way how the extra pins are accessed for different boards, because all the #if/#elif options look like a big mess

     

    2) I've to test all LCD types and connection variants and tune the timings for best performance.

     

    However, I've added a temporary solution for you so that you can try out a KS0108 based GLCD - I haven't tested it at my side (crossing fingers!)

    The CS pins should be available at J10B:D8 .. J10B:D11 now

     

    Best Regards, Thorsten.

  5. MIDIbox goes RTP-MIDI...

    in Design Concepts

    Posted

    MIOS32_SPI_MIDI supports up to 16 independent MIDI IO ports (like USB MIDI), which can be used internally in the application, or which could be forwarded to physical interfaces like UART MIDI or IIC_MIDI.

     

    However, Benoit has to answer on the supported maximum number of independent network ports and UART MIDI ports for the alternative firmware.

     

    Best Regards, Thorsten.

  9. MIDIbox goes RTP-MIDI...

    in Design Concepts

    Posted

    Some words from my side: I always found the capabilities of RTP-MIDI very attractive, but refused to implement it natively into MIOS32 because of the high amount of engineering effort for a proper implementation of the RTP and Bonjour protocol. Also the resource requirements (especially RAM and fast response time) are so high, that it was clearly something which can't run in parallel to a typical MIOS32 application like MIDIbox SEQ or MIDIbox NG -> definitely something that has to be offloaded to a second core.

     

    I was highly interested on the KissBox OEM after Benoit contacted me (actually because of a different project, but we quickly changed the topic ;-), he sent me a sample PCB, and in the last days we worked out a high performance communication protocol for MIOS32 based cores, which works stable.

    For those who are interested: the driver is implemented in mios32_spi_midi.c: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_spi_midi.c

     

    The KissBox is connected to the core via J16. It shares the port with a SD Card (almost no disadvantage), and since there is no hardware conflict, it will be available for all MIOS32 applications in future.

     

    Note, that the KissBox OEM also supports an alternative firmware for UART based MIDI ports.

    This means, that you could upgrade other MIDI devices as well (e.g. MBHP_CORE based -> just connect the Rx/Tx lines to J11)

    In this case the connection will be slower (just the common MIDI baudrate), but the network based approach still has advantages.

     

    Main advantages (from my point of view):

    • in distance to UART or USB based MIDI, a device can contact any other device over a single cable, and transmit with an extremely stable timing.
      E.g. after experimenting with KissBox I believe that RTP MIDI is the best way to distribute a MIDI clock to multiple computers (and MIDIboxes of course ;-)
    • Better than OSC, especially on a WiFi connection due to guaranteed transmission in the expected order thanks to TCP/IP (instead of UDP) -> no danger for hanging notes!
    • Seamless integration with MacOS, iOS but also Windows computers thanks to Tobias Erichsen's driver
    • in distance to CopperLAN (we had a discussion on this in another thread), the RTP MIDI protocol isn't a closed source protocol which needs proprietary drivers
    • Benoit hasn't mentioned this, but KissBox is ready for HD MIDI, and MIOS32 based devices will probably be the first ones which support the upcoming standard! :smile:

    Best Regards, Thorsten.

  10. AINSER64 & AOUT_NG

    in MIDIbox NG

    Posted

    Hi Andy,

     

    I can confirm, that J3:RC1 and J3:RC2 are swapped on the V1 AINSER64 PCB due to a layout error.

     

     

    The most logic solution would be to connect the AOUT_NG board to J3 of the AINSER64 board, useing RC2 for the AOUT and configure it's cs to 1.

     

    That's correct, and this is the way it should work.

     

    How long are the cables?

    Each cable shouldn't be longer than ca. 10..20 cm!

     

    Best Regards, Thorsten.

  14. WaveTable Utility

    in MIDIbox FM

    Posted

    Just wanted to troubleshoot the MBFM firmware, but I've the same problem.

     

    I'm getting following error message under MacOS and Linux:

    Exception in thread "main" java.lang.UnsupportedClassVersionError: ui/MainWindow : Unsupported major.minor version 51.0

     

    Version under MacOS:

    java version "1.6.0_65"
Java? SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot? 64-Bit Server VM (build 20.65-b04-462, mixed mode)

    And under Linux (Ubuntu):

    java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.12.04.2)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)

    Best Regards, Thorsten.

  15. Step sequencer project / A live set killer.

    in Design Concepts

    Posted

    I agree with Hawkeye, that such a control surface unfortunately doesn't fit with the MBSEQ V4 concept.

    A new application has to be developed for this, e.g. based on this tutorial: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F017_sequencer%2F

     

    My sparetime is too limited for such side-projects (which I'm not used myself), but maybe somebody else with programming skills is interested?

     

     Best Regards, Thorsten.

  17. DINX4 communication fails, no LD signal

    in Testing/Troubleshooting

    Posted

    I think, the LD pulsewidth is similar to CLK pulsewidth on J9 SC (pin22), what I can detect with my scope.

     

    yes, you are right.

     

     

    Maybe the PIC is damaged?

     

    yes, very likely!

    What did you do with the PIC so that this happened?

    Actually PICs are very robust chips. E.g. if you would clamp the RC output to ground or +5V, nothing dangerous would happen...

    So, something else has caused this defect!

     

    Best Regards, Thorsten.

  18. MIDIbox NG Release + Feedback

    in MIDIbox NG

    Posted

    In order to get 32 dim levels, you've to:

     

    1) change the NUM_MATRIX_DIM_LEVELS to 32 in mbng_matrix.c:

     

    2) change the rgb type in mbng_event.h from:

    typedef union {
  u16 ALL;

  struct {
    u16 r:4;
    u16 g:4;
    u16 b:4;
  };
} mbng_event_rgb_t;

    to:

    typedef union {
  u16 ALL;

  struct {
    u16 r:5;
    u16 g:5;
    u16 b:5;
  };
} mbng_event_rgb_t;

     

    change some checks in mbng_file_c.c which complain about values >= 16 (search for rgb)

     

     

    64 dim levels: possible in theory, but much more changes are required, because the mbng_event_rgb_t type is only a 16bit variable, which can't store 3*6 bits.

    If you don't plan to use a RGB LED, you could write:

     

    typedef union {
  u16 ALL;

  struct {
    u16 r:6;
    u16 g:6;
    u16 b:4; // not used...
  };
} mbng_event_rgb_t;

     

    otherwise you would have to change it to a 32bit type, and this would require a lot of changes in the memory management and compression related functions in mbng_event.c

    It would also increase the memory consumption for each event!

     

    In addition, you've to set MIOS32_SRIO_NUM_DOUT_PAGES to 64 in the mios32_config.h file, and you should reduce the number of SRIOs (e.g. to 16) to avoid flickering.

     

    Best Regards, Thorsten.

  19. Ghost notes

    in MIDIfication

    Posted

    Thanks for posting the pictures, this makes it much easier to get an impression about possible problems! :)

    I think that the cable length between the first and the second MBHP_DIO_MATRIX module is too long, this could cause such effects.

    It shouldn't be longer than 10 cm

     

    Best Regards, Thorsten.

  24. Digital Lyric/Chord Cheet Sheet

    in Design Concepts

    Posted

    The LCD cable should be as short as possible, I wouldn't use lengths > 30 cm

     

    Sending to an iPad/phone via OSC sounds like a good plan! It shouldn't be so difficult to integrate this into MIDIO128.

    But I'm unsure about a suitable application to display the text (at least OSC doesn't prevent you from sending strings)

     

    Best Regards, Thorsten.

×
×
  • Create New...