Jump to content

TK.

Administrators
  • Posts

    15,246
  • Joined

Posts posted by TK.

  1. Hi Jakob,

     

    cloning will only work if the MBSID firmware is already installed on each PIC core.

     

    Did you already check if the third PIC is working by putting it into the socket of the first PIC core?

    If it isn't working: are you able to upload the firmware with MIOS Studio?

     

    Best Regards, Thorsten.

  2. Mute sync issue: go to the option page, check the value of Option 1 ("Steps per Measure")

    Probably you set it to 1, the default value is 16

     

     

    • If I activate "ALL" (pattern mode) it is not possible to delete or activate single steps.

     

    This is intended.

    The ALL button only affects parameter layers and no triggers layers.

     

     

    • Is it possible to have the "STEP VIEW" status display on the LCD by LEDs?
      -> 1-16 -> LED1, 17-32 -> LED2 and so on?
      (Perhaps by additional use of the REW/FWD LEDs)
      from V3: "Step View: either one LED which shows if step view 17-32 selected, or two LEDs which display if step view 1-16 or 17-32 are selected."

     

    On V3 this was easy, because it allowed to play 32 steps maximum, therefore only two LEDs were required.

    But V4 can play up to 256 steps, which means that 16 LEDs would be required.

     

    Best Regards, Thorsten.

  3. This is what I wrote him via mail:

     

    Hi Alexandre,

    in order to use the bootloader, you've to locate the reset vector of your code to 0x0400, and the interrupt vector to 0x0408
    At 0x0404 the value "0x4711" is expected.

    Summary:
           org     0x0400
           goto    Start
           dw      0x4711          ; magic number - if != 0x4711, the bootloader won't branch to 0x0400!
           org     0x0408
           goto    Irq

    I'm not sure how this can be done in C, but I'm sure that you will find a way (google might help)

    The bootloader itself doesn't use the EEPROM
    The device ID is stored in the ID header instead, which is normally not used by an application.
    The ID header should be all-zero (by default it's all-one)
    If your PIC programmer doesn't allow to program the ID directly, you could use the program linked in "TEST SW2" from this page: http://www.ucapps.de/howto_debug_midi.html

    In MIOS Studio you can upload new code the following way:
    - open the .hex file
    - push the "start" button
    - reset (or power-cycle) your core

    The query button won't work while your application is running because it expects a SysEx based communication with the PIC which is only implemented in MIOS.
    However, the upload via power-cycling is already more comfortable than using a PIC programmer...

    Best Regards, Thorsten.

  4. A 14bit map would allocate 32k RAM.

    For STM32F1 and LPC17 it wouldn't be possible to provide such a feature, because memory is already completely used by the application.

    For STM32F4 there would be a possibility, but it contradicts with other planned features, such as the .NGR bytecode interpreter.

    And I got a request to provide individual delay parameters for each key of a keyboard which will consume some memory as well.

     

    Therefore it's very unlikely that I will provide a map with such a high resolution - It's probably better to work on a dedicated application for this usecase.

     

    Best Regards, Thorsten.

  5. The Standard Control Surface has to be connected to J10A

     

    Connection to J8/9 isn't the standard - means: most applications (such as MBCV V2) don't support this.

    In addition, Ilmenator's SCS based PCB has some additional button and encoder functions which are not supported by most apps as well - only by his own app.

     

    The good news: Ilmentator created a new PCB with the actual SCS circuit which can be directly connected to J10A :smile:

     

    Best Regards, Thorsten.

  6. Hi Kai,

     

    this isn't the normal behaviour, actually the usage should be straightforward.

    Especially normal MIDI events (no SysEx data) should work with any MIDI interface - even with the blacklisted ones.

    And with any other MIDI device (such as a MIDI keyboard) of course.

     

    I'm surprised that after an optocoupler replacement and successful firmware upload there are still issues with receiving MIDI data.

    The need for a replacement is already very unusual.

     

    Therefore I think that the replacement didn't solve the actual issue.

    Rowan, if you are reading this posting: did you check if MIDI notes can be received correctly after the repair?

     

    Anyhow, here a link to the troubleshooting guide which helps to identify the problem: http://www.ucapps.de/howto_debug_midi.html

     

    Best Regards, Thorsten.

  7. Hallo Ansgard,

     

    "normale" MIDI Events lassen sich bereits jetzt in SysEx streams uebersetzen (und umgekehrt natuerlich auch).

     

    Man definiert einfach einen EVENT_RECEIVER, der das Event empfaengt, und einen EVENT_SENDER, der ein Event sendet

    Mit EVENT_RECEIVER fwd_id=SENDER:<hw-id> wird der Wert, der vom Receiver empfangen wurde an den Sender weitergeleitet

     

    Gruss, Thorsten.

  8. would be an option to let the midibox listens to itself (without creating a midi-loop of course). This could be useful, if I have one potentiometer for resonance and another one for cutoff and I want to control both values at a time with another encoder f.e.

     

    This is actually possible with the "LearnEvent" meta event (which is not officially released yet, and therefore not documented. But you can read the details in this posting)

     

    Did you try "MidiLearn" (which is matching with your observations) or "LearnEvent" (which is matching with your request)

     

    Best Regards, Thorsten.

×
×
  • Create New...