Jump to content

TK.

Administrators
  • Posts

    15,247
  • Joined

Everything posted by TK.

  1. TK.

    MIDIbox SEQ V4Lite

    The brightness depends on R8-R16 - you could try if lower values help by adding a second 100 Ohm resistor in parallel (-> results into 50 Ohm) Btw.: for "cross-readers": such a low resistor value is only allowed if LEDs are driven time multiplexed from microcontroller pins which are limited to ca. 20 mA. Never use such a configuration when LEDs are directly connected to a PSU! I'm unsure if the buttons are still working with such a low value, your feedback is welcome! Best Regards, Thorsten.
  2. Unfortunately I can't tell you the exact configuration steps, since I neither use the software, nor this hardware. I only remember that a german guy got this running with a Behringer Controller, but I can't find the posting anymore. It could either be in the german, or in the "MIDIbox of the Week" forum section. Somebody else did something similar: but he enhanced Tascam controllers instead of Behringers... the approach could be different. However, it should work this way: your DAW sends the display content to the virtual Mackie Control (BCFView) in a SysEx stream. The same stream has to be sent to the core module, the MBLC firmware decodes the SysEx data and updates the LCDs. There is no special configuration required to get this working, just upload the MBLC app, connect two 2x40 LCDs, forward the stream to the core module -> done Btw.: does the BCF2000 controller receive the complete Mackie Control stream directly, or does it get filtered/converted commands from BCFView? Best Regards, Thorsten.
  3. TK.

    MIDIbox SEQ V4Lite

    Bug report: MIDI slave mode doesn't work if the clock is received via MIDI IN1 or IN2 A fix is in place (-> SVN repository) and will be released with the next version. If somebody needs this earlier, just let me know. Best Regards, Thorsten.
  4. A Logic Control emulation with character LCD support for MIOS32 isn't available yet, but will be available as part of "MIDIbox NG" in some weeks... On the other hand: I remember that somebody did the same like you (upgrading a BCF2000) with the old PIC based MBHP_CORE module + two 2x40 LCDs by using the MIDIbox LC firmware. This solution should be sufficient, there is no advantage of you would use the MBHP_CORE_LPC17 module Best Regards, Thorsten.
  5. Thanks for writing! :) The ADSR bug can sporadically happen whenever attack, decay and/or sustain of the VCA envelope is set to a value > 0. If the ENV gate is retriggered (turned off/on) within ca. 20 mS, the envelope will stop immediately and especially won't be restarted. So, it matches with your observations. Sometimes it helps to adjust ENV parameters (attack/decay/sustain) slightly so that the bug doesn't occur. Alternatively you could enable the ABW (ADSR Bug Workaround) option which fixes this issue by reseting the ENV before setting the gate, but it will delay the sound output by ca. 20 mS - this delay has to be compensated in a DAW after recording (so: it's only a "studio option") Your retrigger-sequence request is currently not supported, but I just have added this to the TODO list. Best Regards, Thorsten.
  6. yes, thats allowed Best Regards, Thorsten.
  7. It seems that there is a problem with the SD Card connection AND with the frontpanel PCB connections. First try to fix the frontpanel - here some pictures: The "knight rider" effect should be visible over the complete 16 LED line for all 4 LED rows. If it's only visible for a single line of 8 LEDs, the issue is very likely related to the J15 connection. Btw.: it's important that jumper J15_S is mounted on the MBHP_CORE_LPC17 module! It has to select the 5V option. SD Card: in MIOS Studio terminal, type "sdcard". This command gives you some debugging informations. If the card hasn't been detected, check the cables again... thats all what I can recommend with the given input ;) Best Regards, Thorsten.
  8. These are two different issue, and since CIT already explained his case in another posting, I will only answer Jan's question here. It seems that your PC can't supply the MBSEQV4L, you will need a USB hub with external power supply to get it working properly. Even if programming worked in BSL hold mode, it can't be excluded that the firmware execution during runtime will be unpredictable. E.g. it could crash once you are trying to store a pattern on SD Card - just as one of many possible "strange effects". If you don't own a USB hub (yet), you could also power the MBHP_CORE_LPC17 module from a PSU via J1 Don't forget to remove jumper J17 ("USB Power") in this configuration! Another important hint: once you've uploaded the MIOS32 bootloader, you've to remove the LPC Link, or for the case it hasn't been separated from the "target board", you've to cut the 3.3V line like shown here: And another hint (for the case it isn't obvious): as long as the 3.3v line is disconnected, the LPC Link won't be able to program he target board - but you won't need this anymore... instead you will upload the application via MIOS Studio. Best Regards, Thorsten.
  9. Indeed an interesting progress, thanks for the news! Best Regards, Thorsten.
  10. release/STM32 doesn't work, please use following settings: export MIOS32_FAMILY=STM32F10x export MIOS32_PROCESSOR=STM32F103RE export MIOS32_BOARD=MBHP_CORE_STM32 export MIOS32_LCD=universal [/code] It's also important to execute "make clean" after environment variables have been changed, because there is no dependency check (means: files won't be recompiled) Or better: create a release script for automated releases (automation is gold! :)) An example can be found here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Frelease.sh (for your case: remove the check that breaks if the release directory already exists) Concerning FILE_ReadLine(): I thought that it's already working for DOS style newlines... I won't have the time to check this before christmas Best Regards, Thorsten.
  11. You're welcome! :) Please rename the file so that it won't be overwritten when somebody else compiles the project inside the repository, because the danger is too high that a new (undefined) version will be uploaded on a "svn commit" Proposal: create a "release/LPC1769" directory, and store the last tested project.hex file there (-> release/LPC1769/project.hex) Best Regards, Thorsten.
  12. It took some minutes to debug this, but with some changes it's working now on the good old MBHP_CORE_STM32 module! :) In mios32_config.h the SRIO port was re-assigned to J16 (for STM32 only), because J8/9 is used for I2S output. Since J16 is allocated for SD Card, and since there is no other alternative available, SRIO is now disabled for STM32. If you will ever create a control surface for this nice little synth, it would not work for STM32. But I think that this is acceptable... Another issue was located in APP_Init(): The "SDCARD_PowerOn" sequence was only executed once, but the STM32 core needs some retries. I don't want to spend too much effort into this (could be related to initial pin values after power-on), but it works after I added a "MIOS32_SDCARD_CheckAvailable()" loop, which internally calls SDCARD_PowerOn as well... This is the intended power-up sequence anyhow (polling for SD Card), therefore we should let it like it is. The changes are in the repository now. I deleted the precompiled project.hex from the server, because the danger is too high that we are playing ping-pong with different binaries... Btw.: max. polyphony on STM32 is 4 instead of 8 samples (sometimes 5 can be played in parallel...) Best Regards, Thorsten.
  13. TK.

    MBHP_AINSER64

    Thanks for the important tip! The headers are too close together, I will fix this after christmas. Best Regards, Thorsten.
  14. TK.

    MIDIbox SEQ V4Lite

    Except for the higher costs there is no reason - it will work! :) Just only keep in mind, that duo-colour LEDs can't be used because of the way how LEDs are multiplexed. Best Regards, Thorsten.
  15. TK.

    MIDIbox SEQ V4Lite

    I added some more informations to the MBSEQV4L frontpanel to http://www.ucapps.de/midibox_seq_lite.html New pictures with the recommended spacer sizes (5mm + 2x18mm): Best Regards, Thorsten.
  16. TK.

    MBHP_AINSER64

    Schematic: http://www.ucapps.de/mbhp/mbhp_ainser64.pdf Layout (preliminary, because headers are too close together, this has to be fixed!) /edit: removed old layout, new snapshot below This was my first selfmade layout after more than 5 years, but it seems that I haven't lost the skills. ;) First I tried it with Kicad, but quickly changed back to Eagle since I don't like the schematic entry - it slows down the process too much. Using the freeware version of Eagle forced me to limit the size to 100x80, but the circuit still fits into this area! :) Best Regards, Thorsten.
  17. Great that you solved this! :) Best Regards, Thorsten.
  18. TK.

    TK: MBHP_AINSER64

  19. TK.

    mbhp ainser64 proto

    From the album: TK: MBHP_AINSER64

    See also
  20. TK.

    MBHP_AINSER64

    As a workaround for the noisy 3.3V ADC of STM32 and LPC17, I developed a new solution with an external ADC. I selected the MCP3208, since it's available for only 2.75 EUR at Reichelt. It offers a resolution of 12bit. The driver development was straightforward, and I must say that I'm very satisfied with the results! :) The ADC is accessed via SPI (e.g. J19 of the MBHP_CORE_LPC17 module). A 74HC595 has been added and is accessed via SPI as well, so that no additional IO pins of the microcontroller have to be sacrificed for the MUX control. By using a nice trick, only a single chip select line is required to access both serial devices. This makes the solution scalable: multiple MBHP_AINSER64 modules can be accessed from a single core. The driver is prepared for 2 modules (= 128 pots), but scanning even more pots is no problem as long as dedicated uC outputs for chip selects are available. Alternatively, a 3-to-8 MUX could be used for accessing 8 modules via 3 output pins! -> for scanning 512 pots/faders ;-) Also the accuracy is quite nice: if directly powered from the MBHP_CORE_LPC17 module, values are jittering by only ca. +/-1..3 LSBs For comparison: the ADCs of STM32 and LPC17 are jittering by +/- 16, which means that even if the conversion result is converted to 7bit resolution there is a risk for unstable values. If the module is externally powered, the jitter is +/- 1 LSB! Means: 64 pots can be sampled with ca. 11bit accuracy - with a DIY friendly design! :) Here the first applications: Tutorial (self-explaining): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F012b_ainser_muxed%2F Jitter Monitor (for testing purposes): http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftroubleshooting%2Fainser_jitter_mon%2F Driver: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fainser%2F Schematic: http://www.ucapps.de/mbhp/mbhp_ainser64.pdf PCB: this time I will create the layout by myself, because I need some practice ;) Update: PCB up & running -> new website http://www.ucapps.de/mbhp_ainser64.html Best Regards, Thorsten.
  21. Ok, this explains why I haven't noticed this issue by myself so far. The linker error message "undefined reference to `<function-name>'" usually appears if a function is correctly declared in a .h file, but the related .cpp file hasn't been compiled. The linker can't find it in the object files, and therefore can't build the complete binary. The issue is related to the Linux build flow which generates a Makefile for all .cpp sources via "premake". If this command isn't available on your machine, or if you are using an unsupported version, the <application>.make file won't be generated and then you are probably trying to build the application based on an outdated Makefile which doesn't reference all .cpp sources. This was the issue that Davo had. Meanwhile I committed a new pre-generated MiosStudio.make file to the repository which includes all new sources, therefore the build flow is working even without "premake" Best Regards, Thorsten.
  22. I don't want to change the original header files for such a purpose, because the modification would get lost if I (or somebody else) would update to a newer version, and the next guy who would try to compile your application would get confusing compile errors. You could just wrap the #include statements in your .cpp file instead: extern "C" { #include <ff.h> #include <diskio.h> } [/code] This has the same effect. Best Regards, Thorsten.
  23. TK.

    GATE OUT

    This configuration works at my side, I checked all engines. Could you please check this prebuilt binary: http://www.ucapps.de/tmp/mbsidv2_rc38_for_igi.zip Best Regards, Thorsten.
  24. 74HC541 connections: Pin 1 and 19: OE# connected to ground Pin 10: to ground as well Pin 20: to 5V Pin 2..9 are the inputs (connected to J5A/B/C) Pin 11..18 are the outputs (connected to your synth gear) Best Regards, Thorsten.
  25. There is a precompiled Linux binary meanwhile. To build the binary a modification in juce_1_52 is required to get MIDI running properly (documented somewhere in this forum). Newer juce versions are not considered yet by the source code. Do you have issues with the precompiled version? Best Regards, Thorsten.
×
×
  • Create New...