Jump to content

alfadeo

Members
  • Posts

    7
  • Joined

  • Last visited

  • Days Won

    1

alfadeo last won the day on November 25 2017

alfadeo had the most liked content!

Contact Methods

  • Website URL
    http://alfadeo.de

Profile Information

  • Gender
    Not Telling

alfadeo's Achievements

MIDIbox Newbie

MIDIbox Newbie (1/4)

1

Reputation

  1. Yes. Yes this happens without a MIDI device. If I connect an external MIDI device no events are sent or received. J4A is correct, but I am unsure about the ribbon cables (for all boards). Do you know good instructions how to assemble them correctly? I was trying to compile apps/troubleshooting/mbhp_core_stm32_module in order to check the core module, but now I realize that this is not the same as STM32F4. My fault. Are there any other tools that could help to debug my core module. Thanks a lot for your help! Christoph
  2. I have assembled my SeqV4 modules (mbhp_core_stm32f4, wilba control surface, 2x MIDI I/O, Quad IIc R2, AOUT_NG R1, DOUT R5, PCBs from SmashTV). The STM32F4DISCOVERY board seems to work fine, no problem with the bootloader and I have successfully uploaded MIDIbox SEQ V4.088 via MIOS Studio. After connecting the STM32F4DISCOVERY board with the MBHP Core the LCDs and the SD card work as expected. Troubles begin as soon as I try to connect other modules (wilba control surface, MIDI I/O, Quad IIc tested, wilba/MBSEQ_HW.V4 on SD card root): Wilba control surface (J8/9): I get the LCD message asking to create a new session, but the core does not react to the control surface. No LED response on the surface (L31 is mounted in reverse). MIDI I/O (J11E): No response to MIDI in/output, if I start the sequencer in MIOS Studio I get timeout error messages: [MIOS32_MIDI_Receive_Handler] Timeout on port 0x20 [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 Quad IIc: The core does not boot (no LEDs on, no MIDI ports at computer) It is also strange that the CPU always runs at ~ 230% (obtained by sending the "system" command from MIOS Studio). And I have the impression that the whole board gets rather hot (I have no comparisons though). I have tried different ribbon cable orientation (very confusing for newbe), but the effect was the same. So I concluded that I have messed up the MPHP core and resoldered suspicious looking joints (having messed up 4 modules is quite possible but less likely). In particular I have tried to remove a suspected short at the left pins (see attached image) of the SD card connectors. I am also not sure, if they should be soldered to the PCB or not). The only effect was that LCDs stopped working when I connected the control surface. Searching for tests I found the troubleshooting apps in the mios32 source code. After a few adjustments I am stuck at (I am on 4.0.4-2-ARCH Linux, MIOS Studio compiled without problems): Creating object file for check.c check.c: In function 'CHECK_Pins': check.c:160:34: error: 'GPIO_Mode_IPU' undeclared (first use in this function) GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPU; ^ check.c:160:34: note: each undeclared identifier is reported only once for each function it appears in check.c:180:36: error: 'GPIO_Mode_Out_PP' undeclared (first use in this function) GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; ^ check.c:229:36: error: 'GPIO_Mode_IPD' undeclared (first use in this function) GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IPD; ^ /home/ch/src/mios32/trunk/include/makefile/common.mk:160: recipe for target 'project_build/check.o' failed make: *** [project_build/check.o] Error 1 Indeed GPIO_Mode_IPU, GPIO_Mode_Out_PP and GPIO_Mode_IPD are defined in drivers/STM32F10x/v3.3.0/STM32F10x_StdPeriph_Driver/inc/stm32f10x_gpio.h, but not in drivers/STM32F4xx/v1.1.0/STM32F4xx_StdPeriph_Driver/inc/stm32f4xx_gpio.h. Sorry for the massive amount of probably unrelated details. I am pretty much stuck at the moment and would appreciate any sort of help. I am attaching images of the (i) MBHP solder joints, (ii) SD card joints, (iii+iv) two ribbon cable connections, I would consider (iii) to be correct but most images I have seen would point to (iv). Best, Christoph
  3. But I need to send PCs a few ticks in advance (ie before pattern start) to change OT patterns at the first step of the next pattern. Otherwise patern changes will be delayed e.g. by a bar (depending on OT setings). Programming PCs at the pattern end is not a real solution, because after a single repetition loops will be out of sync again.
  4. Yes MM can change patterns with midi notes, but not the Octatrack ...
  5. I am new to Midibox (just ordered parts for a Midibox SEQ) and wonder if it is possible to send program changes a few ticks ahead of time. I want to use program changes to change patterns on Elektron boxes (Octatrack and Monomachine). Unfortunately they do not change patterns immediately, but wait (depeding on settings) e.g. until the next bar after the PC event. Ideally I would like to select Elektron patterns by setting PCs at the first step of each pattern, but that would require that they are sent a few ticks ahead of time, so that pattern changes occur at the beginning of the new pattern (and not one bar later). So far I have found no hardware sequencer (except Elektrons) that sends PCs ahead of time. Is that possible with the Midibox SEQ? I have found nothing in the manual and the forums, but might have missed something. I also would not mind adjusting code, if MIDI scheduling allows to send events ahead of time. Best, Christoph
×
×
  • Create New...