TK.

I guess that you mean pin 6? This is a pull-up resistor. If the gate is closed, we get a logic-0, if it's open the resistor will pull the level to logic-1 Best Regards, Thorsten.

Actually I used the cheap TLV5631, and I got them as free samples many years ago ;-) Great that it's working now - yes, I tested with different DAC numbers :) Best Regards, Thorsten.

Some years ago I used an Reaktor plugin for this purpose - it has a VU meter which I modified so that it sends a CC on LED updates. See also this video where I used this component: https://www.youtube.com/watch?v=oJpwpAHuDvQ Just add the plugin into the FX chain and define dedicated CCs for each channel strip - done :) If you don't own Reaktor, but if you are experienced in plugin programming, you could program something similar by yourself (this is a DIY forum... ;-) Best Regard, Thorsten.

Ok, I finished the prototype and fortunately the HW itself worked immediately ;-) The issue was as initially described by Andy: during the initialisation phase, the DOUT pin has to be enabled step-wise for each chip in the chain before the next one can be accessed: // initialize CTRL0 // Note: with each CTRL0 access we enable the DOUT pin which is connected to DIN of the next module // Therefore we've to strobe FS after each 16bit transfer to ensure that the next module will get the following data for(dev=aout_num_devices-1; dev>=0; --dev) { MIOS32_SPI_RC_PinSet(AOUT_SPI, AOUT_SPI_RC_PIN, 0); // spi, rc_pin, pin_value // DO=1 (DOUT Enable), R=3 (internal reference, 2V) u8 ctrl0 = (1 << 3) | (3 << 1); MIOS32_SPI_TransferByte(AOUT_SPI, 0x8 << 4); MIOS32_SPI_TransferByte(AOUT_SPI, ctrl0); MIOS32_SPI_RC_PinSet(AOUT_SPI, AOUT_SPI_RC_PIN, 1); // spi, rc_pin, pin_value MIOS32_DELAY_Wait_uS(1); // short delay to ensure that RC will be pulsed by at least 1 uS } In addition, a short delay was required to ensure that the data is taken before accessing the next chip! (these are the details which are very time consuming to debug remotely, could have caused additional iterations without direct access to the HW!) All other transfers are working as intended: set FS=0, transfer n x 16bit data, set FS=1 -> data will be taken over Please try this version at your side: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre10.zip No need to try any pre9* version (because it will set FS for each 16bit transfer, also for channel value updates, which isn't required and will lead to unnecessary glitches) Best Regards, Thorsten.

We should stop speculation... ;-) I will solder three chips on a veroboard so that I can try out different update strategies in order to find the best (and hopefully) working one. Best Regards, Thorsten.

I don't really want to skip CTRL1 preload as a workaround, but prefer to understand the reason why the driver doesn't work as expected. For the case that you would like to try it out: here an alternative sequence, where CS is strobed after each 16bit transfer: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre9_aout_ng_multics.zip It might work, but I see the potential problem that the first DACs will temporary output the voltage of the following DACs (and I can't believe that this is the intended way how to preload the DACs). :-/ Best Regards, Thorsten.

"Accepted quirk" is something that I should add to my reply templates ;-) However, if it helps to send a dummy note, then you could add this workaround to src/main.inc: search for movlw 0xfa call MIOS_MIDI_TxBufferPutand add following code before the "movlw" movlw 0x90 ; dummy note for MIDI2CV call MIOS_MIDI_TxBufferPut movlw 0x3c call MIOS_MIDI_TxBufferPut movlw 0x7f call MIOS_MIDI_TxBufferPutBest Regards, Thorsten.

The 0.4V noise is unusual, but shouldn't cause a problem. However, another possible reason could be, that you forgot to stuff Jumper J6 to select the pull-ups, and/or that there is a problem with the pull-up resistors (see schematic: http://www.ucapps.de/mbhp/mbhp_dio_matrix.pdf ) This hint might sound strange for you, but I learnt that sometimes it makes sense to mention even the obvious things: http://midibox.org/forums/topic/19699-flashed-bootloader-onto-lpc17-ok-but-cannot-flash-apps-help/?do=findComment&comment=171514 ;-) Best Regards, Thorsten.

It seems that the TLV5630 chip doesn't shift the data as expected (and unfortunately the datasheet doesn't make clear how to handle the cascading software-wise) However, I've some spare chips but no PCBs. I will solder them on a veroboard to debug the transfers soon. Best Regards, Thorsten.

I found a way to introduce negative delays for MIDI clock and other MIDI events without too much implementation effort! :) New version: http://www.ucapps.de/mios32/midibox_seq_v4_089_pre8.zip The changes require a lot of testing, not only for the case that delays are applied, but also for the normal case where all delays are set to 0 Especially: stretched and/or sustained notes, echos, song & pattern changes, MIDI file player I hope that everybody who requested this feature will help to ensure the firmware quality! Just let me know about everything which seems to behave different compared to previous versions. Best Regards, Thorsten.

Very well done, Serge! It's a pity that the company doesn't open the specs, it would be such a nice possibility to get soundbank contributions from more people Best Regards, Thorsten.

Please try this out: http://www.ucapps.de/mios32/midibox_seq_v4_089_pre7.zip The MIDI clock delays can be configured in the MENU->BPM page with GP#12 and #13 Currently only positive delays are possible, and (unfortunately) other events can't be delayed as well - this might change in future, but currently it would be too much effort (many parts of the firmware have to be overworked and reviewed). At least a starting point for first experiments. Best Regards, Thorsten.

This shouldn't cause a problem, the .o files should be compatible anyhow. Best Regards, Thorsten.

Hi Erik, unfortunately due to the way how the sequencers are implemented, it isn't possible to send MIDI data (for experts: the sequencers are handled in the interrupt service routine, but MIDI data can only be sent from the main thread. There isn't enough free memory for a FIFO from interrupt to main thread to decouple the data) It seems to be an issue in the MIDI2CV firmware that clocks are ignored until a MIDI note has been received: according to the user manual, the first MIDI note is required to auto-learn the MIDI channel, but why isn't the clock handled regardless of the first note? Did you already contact the author of the firmware? Best Regards, Thorsten.

Hi Andy, today I spent some time on a code review (since I've only a single AOUT_NG module there was no easier way...) I think that I found the potential problem: all AOUT_NG modules require a CTRL0/CTRL1 register configuration after power-on, but the AOUT driver did this only for a single module. This means that only the first AOUT_NG module was configured correctly, and that the second AOUT_NG module got an incomplete configuration (only CTRL0), and that the following AOUT_NG modules haven't got a configuration at all! Please try this version, where all chained modules should get CTRL0/CTRL1 properly: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre9.zip Best Regards, Thorsten.

Hm... it would be interesting if the MBSEQ_HW.V4 file can be accessed after you entered the "reset" command into the terminal (this will reboot the MIDIbox without power-cycling) Best Regards, Thorsten.

To 1) a remote update is already possible with the MIDI router, e.g. take an USB port != USB1 (USB2, 3 or 4) and take one USBx->OUTy, and one INy->USBx connection To 2) added to wishlist, but it's unlikely that I will allow to modify parameters with the sliders, because 99% of the users don't have them, and they will need an alternative solution anyhow. In order to avoid complexity, I would prefer to allow only a single way of configuration. Best Regards, Thorsten.

Hi Andy, long cables between DIO_MATRIX and buttons/LEDs shouldn't cause a big problem, but it's important that the cable between CORE and DIO module is as short as possible (typically 10cm and not more than 20 cm), otherwise random things can happen due to transfer failures to the shift registers. If this isn't already the reason, I would recommend two strategies: 1) SW side: reduce the configuration and check if the problem comes up again. E.g. remove all parts from a matrix row, and/or from a matrix column 2) HW side: disconnect cables from a row or column Best Regards, Thorsten. P.S.: I assume that the 1N4148 diodes have been soldered for all buttons/switches, because without them one switch could influence the other switches of the same row

Thanks for the inspiration; interesting, what can be hidden into an Eurorack case! :) The "ICs" in the yellow package are actually 8x220 Ohm resistor arrays Best Regards, Thorsten.

Are the messages really problematic? I mean: these are warnings and no error messages, hence the .hex file should be generated, right? Best Regards, Thorsten.

First of all please install the latest firmware, because the current release for LPC1769 can cause a stack overflow which could lead to random effects: http://midibox.org/forums/topic/19646-pc0x00038a50-hard-fault/?do=findComment&comment=171163 If this doesn't already solve the problem, I would like to know which messages are print on the terminal after the firmware has been uploaded. Best Regards, Thorsten.

Hi Tom, it looks like jumper J27 (bootloader hold mode) is mounted, resp. Pin 1.27 is connected to ground maybe by fault - see also schematic: http://www.ucapps.de/mbhp/mbhp_core_lpc17.pdf This would explain, why the application can be successfully uploaded, but won't be started. Best Regards, Thorsten.

I've to test this at my side if nobody is using this configuration yet Best Regards, Thorsten.

MBSEQ is currently not able to delay individual MIDI clocks, but since this isn't the first time for this request, I added it to the wishlist It could be, that this feature won't be available for the LPC17 based build, since this firmware is running out-of-memory. Best Regards, Thorsten.

I think that this is intended in slave mode: the sequencer won't stop, just mute the tracks and continue in-sync Best Regards, Thorsten.