TK.

Unfortunately this seems to be a common issue with HP computers and WinXP. See also and The last article contains a solution (install an alternative MIDI driver) Best Regards, Thorsten.

Um zu ueberpruefen, ob es sich hierbei um ein Hardware- oder Software-Problem handelt, wuerde ich vorschlagen, in mios32_config.h die L/R SRs zu vertauschen: #define DIN_16x16_L0 11 #define DIN_16x16_R0 12 // DINs of second 16x16 matrix (counted from 1) #define DIN_16x16_L1 13 #define DIN_16x16_R1 14 // DOUTs of both matrices #define DOUT_16x16_L 1 #define DOUT_16x16_R 2 [/code] aendern in: [code] #define DIN_16x16_L0 12 #define DIN_16x16_R0 11 // DINs of second 16x16 matrix (counted from 1) #define DIN_16x16_L1 14 #define DIN_16x16_R1 13 // DOUTs of both matrices #define DOUT_16x16_L 2 #define DOUT_16x16_R 1 Welche MIDI Events werden nun gesendet? Gruss, Thorsten.

Before starting with a hypothesis some questions: really 1.05V or 2.05V as expected? And could you please measure the DAC output voltages directly at the TLV5630? Channel #1 -> Pin 12 Channel #2 -> Pin 13 Channel #3 -> Pin 14 Channel #4 -> Pin 15 Channel #5 -> Pin 6 Channel #6 -> Pin 7 Channel #7 -> Pin 8 Channel #8 -> Pin 9 Best Regards, Thorsten.

Hi, The Java MIDI API which comes with MacOS 10.6 doesn't support SysEx. Workaround: install mmj: http://www.humatic.de/htools/mmj.htm Best Regards, Thorsten.

I've some additional hints which are worth a try: for the case that this isn't properly documented: in distance to other DACs (MBHP_AOUT and MBHP_AOUT_LC), the TLV5630 has to be configured via serial commands before voltage outputs are properly working. This is done in AOUT_IF_Init(). While MBSEQ allows you to call this function again by changing the AOUT interface selection from any module back to AOUT_NG, the tutorial application requires that the core is reset (resp. power-cycled) so that APP_Init() calls AOUT_IF_Init() again. measure the voltage at the REF pin (pin #16) of the TLV5630. It is ca. 0V as long as the chip hasn't been initialized, and 2.05 once AOUT_IF_Init() has been called another interesting experiment (I'm very interested on the results): configure the J19 pins in push-pull mode. This can be done by adding following defines to your mios32_config.inc file: #define AOUT_SPI_OUTPUTS_OD 0 [/code] (recompile the application). Thereafter change the J26 jumper so that 3.3V are output at J19:Vd - the TLV5630 can work at this voltage range, and by using the pins in push-pull mode the SCLK signal should look "cleaner" than in open drain mode, pulled to 5V. Even if this doesn't solve the problem, it would be interesting to know if you can see the SCLK on your scope now Best Regards, Thorsten.

Yes, the internal pull-up resistor at J19:SI pulls the input to high level - thats normal and you can ignore it as you are not using the serial input anyhow. I don't think that the AOUT_LC test will give you new input which could help to troubleshoot the AOUT_NG issue. Could you please describe, how you are testing the AOUT_NG module exactly. Where do you measure voltages? Did you already try to measure the unamplified voltages directly on the TLV5630 pins? Which pull-up resistor network are you using at J19 (J32), maybe it could make sense to try another value, e.g. 4*1k instead of 4*10k (or vice versa) Jumper J26 of the core module is selected for 5V? (the resulting voltage on SC/RC1/SO pins should be ca. 4.4V) Best Regards, Thorsten.

This won't work, because the PIC based merger emulates the second MIDI IN via software, which requires low interrupt latencies. No chance to add the MIOS based SRIO driver, the PIC architecture is too slow (or you would need some really good assembly skills to manage this). You could use a second PIC to scan DINs... but today the most elegant solution would be to use the module (or a downstripped version built on veroboard) This tutorial demonstrates, how to route MIDI events: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F001_forwarding_midi%2F&# With following code in app.c: void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package) { // toggle Status LED on each incoming MIDI package MIOS32_BOARD_LED_Set(1, ~MIOS32_BOARD_LED_Get()); switch( port ) { case UART0: MIOS32_MIDI_SendPackage(UART0, midi_package); break; case UART1: MIOS32_MIDI_SendPackage(UART0, midi_package); break; } } [/code] you would route incoming events from MIDI1 and MIDI2 to the MIDI1 output The SRIO driver is already running in background. Following example demonstrates, how to handle DIN events: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F010_din%2F [code] void APP_DIN_NotifyToggle(u32 pin, u32 pin_value) { // toggle Status LED on each DIN pin change MIOS32_BOARD_LED_Set(1, ~MIOS32_BOARD_LED_Get()); // send MIDI event MIOS32_MIDI_SendNoteOn(DEFAULT, Chn1, (pin + MIDI_STARTNOTE) & 0x7f, pin_value ? 0x00 : 0x7f); } As you can see: there is no need to spend time on the old PIC platform anymore, because the new platform simplifies a lot. Best Regards, Thorsten.

You will find the binary under http://www.ucapps.de/tmp/016_aout_modified.zip After compile I get following message: ------------------------------------------------------------------------------- Application successfully built for: Processor: STM32F103RE Family: STM32F10x Board: MBHP_CORE_STM32 LCD: clcd ------------------------------------------------------------------------------- arm-none-eabi-size project_build/project.elf text data bss dec hex filename 44976 96 12608 57680 e150 project_build/project.elf [/code] The code size (listed under "text") is 44976 Do you get exactly the same value? Then your toolchain installation is ok, and the repository is up-to-date. Best Regards, Thorsten.

Please try the prebuilt binary, just to ensure... Note that the source code should be compiled with the official MIOS32 toolchain package, otherwise you could notice random effects, such as "overoptimized" or "worse optimized" code. It could even happen that certain functions won't work anymore due to a new (or old) gcc bug. The AOUT driver uses the MIOS32_SPI_TransferByte() function in MIOS32_SPI_MODE_CLK0_PHASE0 mode to drive the pins: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2FSTM32F10x%2Fmios32_spi.c This won't work, as J8 is already used to service the DOUT chain. And I think that this won't really help to solve this issue. The problem is maybe the wiring you are using, maybe the frequency of the SCLK output is too high. I've used 20..30 cm cables in the past as well, but I'm always using ribbon cable. You could reduce the clock rate by duplicating some MIOS32_SPI2_SET_SCLK_1 and MIOS32_SPI2_SET_SCLK_0 lines in MIOS32_SPI_TransferByte() to check that the cables don't limit the frequency. Best Regards, Thorsten.

Press EXIT, thereafter scroll with the datawheel to the right. The page is between "Save Pattern" and "MIDI Configuration" Best Regards, Thorsten.

This won't help, because these are different pins (except for SC, Vs, Vd) It seems that your AOUT_NG module is already connected to the right pins (but it's a bit confusing that the colours are a different on the pictures) The SC pulses are very short, sometimes ca. 100 nS (= 5 MHz) Did you select the right timescale on your scope? It would be interesting if you can see the pulses if the cable on the SC line is disconnected from the MBHP_CORE_STM32 module. Maybe the cable is too long? (what is the cable length?) Note that J19 is a software emulated SPI port. This means, that if MBSEQ can control the pins, MIOS32_SPI should be able to do this as well without reconfiguring the IO pin. Are you using the prebuilt binary (beta44), or did you build the application by yourself? Did you already ensure that you are using the latest sources of the repository, and that you are not using modified sources? Best Regards, Thorsten.

Wow! This gives me the vision of some new "MPC1000 jog wheel bulk order" topics :) Best Regards, Thorsten.

Which pin was 5v? Sounds like a connection error! Could you please take a photo of the wiring and attach it to this thread? This could help me to understand the problem. Best Regards, Thorsten.

Typically your DAW (like Logic, Cubase, Ableton Live) will allocate the MIDI port for the LC protocol, so that you are not able to control any other parameter from the same port. Accordingly you have to send MIDI events to a separate MIDI port anyhow. Best Regards, Thorsten.

Thank you! This mistake happened during code changes that I made to share parts of the MBSEQ firmware with future MIOS32 applications. MIDIboxSEQ V4.0beta44 ~~~~~~~~~~~~~~~~~~~~~ o session can be selected again [/code] Best Regards, Thorsten.

Hi, MIOS8: just generate (valid) MIDI events to output the variable value, e.g. MIOS_MIDI_TxBufferPut(0xc0); // program change allows to send one additional 7bit byte MIOS_MIDI_TxBufferPut(the_variable & 0x7f); [/code] or: [code] MIOS_MIDI_TxBufferPut(0xc0 | ((the_variable & 0x80) ? 1 : 0)); // program change + MSB of variable MIOS_MIDI_TxBufferPut(the_variable & 0x7f); Alternatively you could try the debug_msg module which is located under modules/debug_msg See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fdebug_msg%2FREADME.txt It sends text strings to the MIOS terminal MIOS32 (to complete this posting): use MIOS32_MIDI_SendDebugMessage to generate debug messages with a printf like parameter list See also http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F003_debug_messages%2F Best Regards, Thorsten.

How about this variant? -> http://www.ucapps.de/mios/midibox_seq_v3_4g3.zip Best Regards, Thorsten.

No, I haven't increased the version number in the LCD message... strange, the code looks good now, even after the third review. Seems that I have to open my MBSEQ and exchange the core module to test it by myself :-/ Best Regards, Thorsten.

I reviewed the code and think (resp. hope) that I found the error: when checking the legato flag via AND the MIOS_HLP_GetBitORMask function has to be used to isolate the flag (the MIOS_HLP_GetBitANDMask function would isolate all other flags...) Please try http://www.ucapps.de/mios/midibox_seq_v3_4g2.zip Best Regards, Thorsten.

A comment to the OSC topic: I already tried this by tunneling the MIDI events (which are the most compact format) via MBSEQ V4 via Ethernet Router to a virtual BLM16x16+X running on my iPad and it worked - in both directions! The MIOS32 based BLM16x16+X could be easily adapted to support the OSC protocol as well, regardless if the compact MIDI based format (embedded into OSC packages), or a "human readable" format, or any other format expected by a DAW is used. This is on my TODO list. :) In mid term I want to separate the whole OSC parsing of the different proprietary formats from MBSEQ into a single source module which can be included into MIOS32 applications, so that enhancements are automatically inherited by all applications. The physical implementation is your topic ;) Best Regards, Thorsten.

Ooops! You are right! It's time to automate the release flow! Please download the .zip file again Best Regards, Thorsten.

perfect specs! But: Epuisé :-/ Best Regards, Thorsten.

Hi, it's always a surprise to read from people who are using a MIDIbox for so long time without the need for troubleshooting! :) I remember that somebody reported this issue a while ago, my statement was that it requires a notestack for proper handling, and that there isn't enough free RAM for such a feature (it has been solved in MBSEQ V4) But I just got an idea how to realize a minimalistic 2-level notestack which should be sufficient for this purpose. Could you please try following version: http://www.ucapps.de/mios/midibox_seq_v3_4g.zip I'm currently not able to test this (I would have to open my MIDIbox to exchange MBHP_CORE_STM32 by a MBHP_CORE). For the case that it doesn't work and you've assembly knowledge: this is the change in src/midi_evnt.inc ;; -------------------------------------------------------------------------- ;; FUNCTION: MIDI_EVNT_AOUT_GatePinSet ;; DESCRIPTION: Help Function which sets a Gate Pin independent from the interface ;; IN: ;; o pin number in WREG ;; o value in MIOS_PARAMETER1 ;; -------------------------------------------------------------------------- MIDI_EVNT_AOUT_GatePinSet SET_BSR GATES movf MIOS_PARAMETER1, F bz MIDI_EVNT_AOUT_PinSet0 MIDI_EVNT_AOUT_PinSet1 call MIOS_HLP_GetBitORMask #if 1 ;; extension for legato handling ;; if gate was already set, save this state in GATES_LEGATO movwf PRODL andwf GATES, W, BANKED iorwf GATES_LEGATO, F, BANKED movf PRODL, W #endif iorwf GATES, F, BANKED return MIDI_EVNT_AOUT_PinSet0 #if 1 ;; extension for legato handling ;; if GATE_LEGATO flag is set, clear this flag and exit ;; otherwise clear the flag in GATES (so that the pin is set to 0) movwf PRODL call MIOS_HLP_GetBitORMask andwf GATES_LEGATO, W, BANKED bnz MIDI_EVNT_AOUT_PinSet0_Legato MIDI_EVNT_AOUT_PinSet0_NoLegato movf PRODL, W call MIOS_HLP_GetBitANDMask andwf GATES, F, BANKED return MIDI_EVNT_AOUT_PinSet0_Legato movf PRODL, W call MIOS_HLP_GetBitANDMask andwf GATES_LEGATO, F, BANKED return #else call MIOS_HLP_GetBitANDMask andwf GATES, F, BANKED return #endif [/code] Best Regards, Thorsten.

The random function isn't documented in the manual, because it was initially planned as an easter egg ;) Best Regards, Thorsten.

This is a switching PSU with 5A for 5V supply (far too much), and 2.5 A for +12V (far too much as well) In addition, switching PSUs are not good for analog stuff. Unfortunately I can't give you an alternative proposal for the US (in germany we would order at "Pollin" where matching PSUs are mostly available for 5..10 EUR), but I can give you some specs: 1A for the 5V supply, only if a BLM16x16+X should be connected maybe 2A would be better. ca. 100 mA for the +/- 12V supply Best Regards, Thorsten.