ilmenator

Thanks!

Hi, I am having troubles downloading the Lemur Daemon from Liine's website - I simply can't register there because their website opens some fancy pop up window which does not display the complete registration form. It only shows the upper half, and I can't seem to scroll inside of this pop up window... So, I can't register, which means I can't download the Daemon. Bummer, because I just purchased Lemur to have a virtual BLM... Are there alternative download sites for the Lemur Daemon for Windows? Thanks, ilmenator

I agree - if you can get the LED to light up otherways then what you describe must be software related. Does it work properly if you use one of the LEDs on Wilba's panel for this?

You are right, I can confirm your results - it seems like my numbering of physical pins is wrong in the schematic (compared to the official MIDIbox way of counting pins). However, this shouldn't affect functionality at all. There is only a color mismatch for LED 4 (you say it's red whereas it is most probably green). Pin 0 = LED IV red Pin 1 = LED III red Pin 2 = LED II red Pin 3 = LED I red Pin 4 = LED IV green Pin 5 = LED III green Pin 6 = LED II green Pin 7 = LED I green You should get LED 4 to light up in red if you assign Pin 0 to LED_TAP_TEMPO - if not, there seems to be a problem with the hardware.

Quant. | forum name ----------------------- 1 | blingy 1 | borfo 2 | Elektruck Teig1 received a board from someone who backed out from the previous batch.

Unless I messed up something, that assignment doesn't look right to me. It should rather be something like this: Pin 0 = IC's physical pin 15 = LED I green Pin 1 = IC's physical pin 1 = LED II green Pin 2 = IC's physical pin 2 = LED III green Pin 3 = IC's physical pin 3 = LED IV green Pin 4 = IC's physical pin 4 = LED I red Pin 5 = IC's physical pin 5 = LED II red Pin 6 = IC's physical pin 6 = LED III red Pin 7 = IC's physical pin 7 = LED IV red This is documented in the schematic. EDIT: Pin 0 = LED IV red Pin 1 = LED III red Pin 2 = LED II red Pin 3 = LED I red Pin 4 = LED IV green Pin 5 = LED III green Pin 6 = LED II green Pin 7 = LED I green Reason for mistake: I counted the physical pins on the SR the wrong way round - funtionality is not affected by this, obviously.

Hope you used a current limiting resistor when connecting the backlight to the battery?!

An example configuration (TPD directly connected to J2 of Wilba's Frontpanel PCB) can be found under hwcfg/wilba_tpd/MBSEQ_HW.V4

The individual LEDs are connected to the last SR in the chain - so, check the highest SR number in the section that configures the duo LED matrix modules and add 1 to that.

You should be able to set the encoder type from within your application with the info provided here: http://www.midibox.org/mios32/manual/group___m_i_o_s32___e_n_c.html

No, you just navigate here http://www.midibox-shop.com/buy.html and buy it once it becomes available again! The waiting list was before Tim aka SmashTV listed the board in his online shop.

Great to hear that you figured it out - and sorry, I was away and couldn't guide you through this. I assume that your TPD module is connected directly to Wilba's frontpanel - would you care to share your config file so I can upload it to the Wiki? Then we have the two most popular use cases covered, one with the TPD connected directly to Wilba's board, and one with a 16x4 BLM in between. (I just realized that the file in the Wiki does not contain the correct settings - my bad.)

Oh, I see - I didn't realize that your comment was exclusively CV V2 related! :smile:

That's also news for me, maybe the respective web pages at ucapps.de describing the AINSER8 and 64 modules could be updated as well? Currently, the AINSER64 page as well as the AINSER8 page still say:

Yes, you marked the right spot! The side with the single leg goes to the single copper square on your PCB. The two legs on the other side of the 6007 connect to the copper trace and the ground plane. Make sure that you heat up the ground plane with a little bit of solder before you put the 6007 in place. The ground plane will absorb an awful lot of heat, and if your 6007 is already there when you are trying to heat it up it will be fried.

I'd say a 1mm gap is plenty, considering that the standoffs will not move sideways if properly fastened!

Did you compile for the new target? Edit: ok, I just saw that you can now download a binary version for STM32F4, and you skip compiling yourself. So, you are using that one?

Their price matrix looks highly uninteresting for prototype orders though... :sad:

Sendest du die richtigen MIDI-Daten an den Core?

Quant. | forum name ----------------------- 1 | Teig1 1 | blingy

Next batch of boards has arrived - everyone on the list should have received PM. Ole Peder, you're in for the next batch. Quant. | forum name ----------------------- 1 | Teig1

To make it easy, you could simply count down the shift registers on the BLM 16x4 that are not physically there in your setup. The BLM 16x4 uses 6 DOUT SRs and 2 DIN SRs. Starting from the config file in the Wiki (that includes the BLM 16x4 setup), in the part of the config file that Hawkeye is referencing above, reduce the number behind each TPD DOUT SR by 6, and behind each TPD DIN SR by 2. Also, make sure that you deactivate the BLM matrix, i.e. change ################################################## # Optional BLM Matrix ################################################## # set this value to 1 if each track has its own set of 16 LEDs to display unmuted steps and current sequencer position # or if you are using a button/led matrix for misc. button/LED functions BLM_ENABLED 1 to ################################################## # Optional BLM Matrix ################################################## # set this value to 1 if each track has its own set of 16 LEDs to display unmuted steps and current sequencer position # or if you are using a button/led matrix for misc. button/LED functions BLM_ENABLED 0 Once you have this up and running correctly, please send me your new config file and I'll add it to the Wiki for others!

Ok, you're in. PM me for shipping address!

Oops, that doesn't look good - glad we are moving on to the next generation ARM cores... You can fix that by using wires, but I wonder how they can just change the layout from rev to rev? Also, I'd double check that the pins have actually just moved physically, and don't carry different functionality altogether (like in: they moved the pins to protect the user from bad mistakes...).

1 semi kit left.