Jump to content

TK.

Administrators
  • Posts

    15,246
  • Joined

Posts posted by TK.

  1. Yes, they should not flip back.

    No pull-up resistors are required.

     

    I added to my TODO list that I check this at my side, but I've to open my MB6582 for this, so I can't do this immediately...

     

    Or maybe somebody else could help to doublecheck this?

     

    Btw.: does this happen with any patch, or only with certain ones?

    And does this happen if you take the init patch (press SHIFT and then the 4th Soft button under "Ini. Pt.")

     

    Best Regards, Thorsten.

  2. Open the Tools->MIOS32 File Browser in MIOS Studio, connect to your SD Card, upload the hwcfg/standard_v4l/MBSEQ_HW.V4L file.

     

    It has already the right configuration to enable the DIN sync output (J5_ENABLED set to 1)

     

    Best Regards, Thorsten.

  3. Unfortunately it isn't possible to control all parameters with MBNG, because this application doesn't allow you to change individual bits of a SysEx parameters (e.g. for waveform control).

     

    Programming the logic in a dedicated C based application is the only way for a perfect solution for this synth beast ;)

     

    Best Regards, Thorsten.

  4. You can't upload a program in USB Host mode, because the upload takes place in the bootloader!

     

    Upload process:

    - MIOS Studio requests a reset, so that the bootloader will be started

    - Once the bootloader replied (which again can't work in host mode), MIOS Studio starts to upload the code

     

    Hope that this clarifies the reason why it doesn't make much sense to continue on this topic...

     

    While I developed the USB host mode, I always uploaded the application via USB MIDI in Device mode.

     

    It wasn't a big deal to:

    - remove the USB host cable

    - plug-in the USB device cable

    - press the black reset button so that MIOS32 reboots in device mode

    - press the upload button in MIOS Studio.

     

    Of course, under MacOS I've the big advantage that I don't need to restart MIOS Studio when the USB MIDI Device was temporary not available.

    If you are working under Windows, it might be required to restart MIOS Studio...

    Alternatively you could initiate the upload from the command line (see "mios_studio --help") to automate this.

     

    Or consider to develop your application without a USB Host connection, find another way to connect your MIDI device during the implementation phase, and use it only when you are not working with a computer (e.g. while making music... ;-)

     

    Best Regards, Thorsten.

  5. Good new is now I can say only one hard coded(fixed) table for all fader is need, fader tolerance are good, no need for individual correction, and I'm using cheap ALPS, will be better with P&G or TKD

     

    These are good news indeed! It means that the two 10bit based calibration tables could be stored into the embedded flash memory of the PIC, so that no additional SW or HW is required.

     

    What I also could provide is a small perl script which generates a look-up table based on given points:

    fader_cali.png

     

    Build process would be:

    - adapt and generate the table in/with the perl script -> this will generate an include file

    - rebuild the mbhp_mf_ng firmware with a PIC assember

    - upload the new firmware (.hex file) with MIOS Studio

     

    The whole update process will take ca. 30 seconds... fast enough to try out various settings.

     

    Required tools: perl (scripting language), gputils (PIC assembler), text editor

    And if you would install "gnuplot" on your computer as well, the perl script would spit out a diagram with the calibration curve as shown above

     

    What kind of signal is use for touchsensor? just DC? do you think I can filter this with some LPF to avoid HF leaking here?

     

    It's a pulse of n*1 uS (n = touch sensor sensitivity value) which is triggered each mS

     

    I'm unsure if/how this could be filtered. You could start with caps against ground at pin #27 (RD4) of the PIC (this is the pulse output)

     

    Best Regards, Thorsten.

  6. It's definitely not possible to feedback the CS parameters to an external device or to LED rings, regardless if they are driven by MBSID itself or values are output via MIDI. Too much code would be required, I'm not really interested to implement this, and I'm even not sure if there would be enough code memory free for such a feature...

     

    Best Regards, Thorsten.

  7. As mentioned before, USB host mode doesn't fit into the 16k bootloader range, there is no need to try this out - it won't work.

    Accordingly, code upload via USB host won't work as well.

     

    Bootloader update application != bootloader.

     

    So: whenever you want to upload code via MIDI, you've to connect the STM32F4 USB port directly to your PC

     

    Best Regards, Thorsten.

     

    P.S.: I just have improved the MIOS32_DONT_USE_USB_HOST switch, so that it excludes parts of the STM32F4 driver - bootloader should fit into memory again (with support for USB MIDI Device mode only...)

     
  8. Before installing the PIC/ICs, while measuring voltages on the PCBs i accidently shorted pins 5V and GND (on the LCD) with one of the multimeter's test leads. The display went dark and comes back to "life" immediatly after releasing the short. Could i have damaged some kind of controller unit of the LCD?

     

    That's very unlikely, because this caused a short circuit for the complete unit.

    It's possible to damage a LCD if it's plugged in the wrong direction into the socket, but I guess that you haven't done this.

     

    Which LCD are you using exactly?

    (I remember that Wilba provided two different types)

     

    Best Regards, Thorsten.

×
×
  • Create New...