FantomXR

Isn't that a usecase for MAPs? I haven't tried it but I'd set up an encoder in absolute mode and setup a MAP as range. In the NGR you can tell NG to set the encoder to a dedicated value when starting up.

Alright! Looks good. I need to test it in my environment. I'll report back. Thank you!

Hm, do you have a quick example how this could work?

Thanks for the reply. I think I've tested this already but for some reason it was not working. But I'll give this a new try early next week and report back! Edit: I remember. The reason why it wasn't working was I don't receive "values" from the DAW but ASCII / text strings instead. And it seems such strings can't be stored...

Hey people, my DAW sends a bunch of sysex strings at once to my midibox. The content of the sysex strings I'd like to display on my OLEDs. In my DAW there is a mixer. The DAW sends the values of the faders via sysex. I have one OLED that should show those value. So if I select channel 1 on my midibox it shows the first value, channel 2 the second. This is not working at the moment because the DAW sends those values of all channels at once and if I switch on my midibox from one channel to another I need to again dump the sysex strings to the midibox to receive the correct value. So I'd need to somehow save those received values inside the midibox and recall them. Any idea? Thanks, Chris

I don't see the enc_mode parameter in the line. You have to set it to enc_mode=40Speed for example. All modes are listed on ucapps.de

The bulk is closed. But you could contact weasel via PM. I'm sure he has some pcbs left.

Hey people, I had a strange behavior last night. My MIDIbox was in the car over night. It was cold, maybe -2°C. The next day I connected it to my computer and realized, that the EEPROM was reset and all settings were gone (it was a MIDIbox running MB_KB). Is there a chance to prevent it from doing that? I had another MIDIbox in the car which runs MB_NG. This was booting fine, but it uses an SD-card instead of the internal EEPROM.... Thanks, Chris

They are SO8. So easy to solder. I followed the design guideline from the official datasheet. I think it's 100R on the 5V rail. Can post it later.

Alright... I've got a solution that works great for me. I thought I share it with you. I now tried WS2811 driver ICs. They are cheap and only need one data-line which goes from one IC to the next. Each IC can drive three LEDs. Of course you are not really capable to control them individually with standard NG code. So I've added a meta command. Add this to mbng_event.c (row 2968 and following): case MBNG_EVENT_META_TYPE_RGB_LED_SET_SINGLE: return "RgbLedSetSingle"; row 3055 and following: if( strcasecmp(meta_type, "RgbLedSetSingle") == 0 ) return MBNG_EVENT_META_TYPE_RGB_LED_SET_SINGLE; row 3142 and following: case MBNG_EVENT_META_TYPE_RGB_LED_SET_SINGLE: return 3; row 3376 and following: case MBNG_EVENT_META_TYPE_RGB_LED_SET_SINGLE: { u16 led; if( (led=meta_values[0]) ) { led -= 1; WS2812_LED_SetRGB(led, meta_values[1], meta_values[2]); } } break; in mbng_event.h add this line 163 and following: MBNG_EVENT_META_TYPE_RGB_LED_SET_SINGLE, Done! Now you can call the meta RGBLEDSETSINGLE from NG. Here is a quick example. I had no buttons connected to that midibox. So I've worked with receivers and senders: EVENT_RECEIVER id=1 type=cc cc=2 if_equal=127 fwd_id=SENDER:1 EVENT_RECEIVER id=1 type=cc cc=2 if_equal=0 fwd_id=SENDER:2 EVENT_SENDER id=1 type=meta meta=rgbledsetsingle:1:1:255 EVENT_SENDER id=2 type=meta meta=rgbledsetsingle:1:1:0 This switches on the second LED of the first IC on if CC2 with a value of 127 is received. It switches off when 0 is received. So you can control each LED individually without overwriting the other :-)

Any knob made from metal will do. Even a plastic knob should do. But you'd need to increase the cap between SNS and SNSK to make it more sensible. I use knobs from Kobler here in Germany.

Hey people, I was looking for a way to detect, if an encoder (with metal shaft of course) is touched. Since NG itself doesn't support such touchsensors I was searching for an IC. And I found it: https://www.mouser.de/ProductDetail/Microchip-Technology/AT42QT1010-TSHR?qs=xbJoyvfFV%2F%252BFK88JVR2efg%3D%3D I've added a 22nF cap between SNS and SNSK and put a 10k resistor right before the encoder. It works great! As soon as I touch the encoder, the "OUT" goes high and if I release it it goes back low. You just have to connect that to an inputpin of an HC165 and you are done. Best, Chris

I guess that routing is way more comfortable and even better if I place all SRs on one PCB next to each other and use pinheader to connect the buttons & LEDs to it directly. For some I reason I never did it like this... I never had performance problems anyway... so I'm just interested how it is done in the professional world...

I know this is an old thread. But my question fits into this topic I think. What is the "professional" way to place the shift registers? Is it better to place them near the MCU to keep SPI-traces as short as possible or is it better to place them near the objects, that are connected to it (resp. buttons or LEDs)? I already designed tons of PCBs and I used to put the SRs near the objects which are connected to the SRs. But meanwhile I don't see really much sense in it. It means a lot routing and starting from scratch with any new PCB. How do you do it?

Hey people, Maybe you can guide me in the right direction. In my projects I use buttons with integrated LEDs. But I want to get away from the standard HC595. Mainly because it takes a lot of PCB space and it has a lot traces due to the SPI protocol. Is there another style to control those LEDs? I also work a lot with WS2812. This is great because there is only one single data line from one to the next. Thanks, Chris

But anyway I'm highly interested what causes this issue... Something seems to disturb the STM when booting... I have no idea.

I mean the bootloader of the midibox and not the computer.

I remember that I encountered that a few times too already. All digital signals where inverted after system boot. So also buttons that were connected to the midibox didn't sent 127 when pressed but 0 and the keyboard did the same. I never solved this. Maybe @TK. has an idea. Did you try to set fastboot on in the bootloader? I think that was my workaround...

You can not set the resolution on a "per input" base. So yes, you'd need a dedicated AINSER module. Please note: MIOS32 only supports two AINSER modules. Although TK shows how to implement a third module in another thread, I was not able to get it running.

Why dont you take those?? https://www.mouser.de/Semiconductors/Logic-ICs/_/N-4s5z6?P=1z0z63x&Keyword=hct541&Ns=Pricing%7c0&FS=True

Depending on what you want to do you can leave it away completely. What housing do you need? DIP or SMD?

Well, I hope that it looks better. Now you can really watch the OLEDs build up their text. If this could be speeded up, it would be great. BTW: I send SysEx strings on the displays.

I can confirm Brunos changes work well! :-)

Hey people, my setup contains nine 128x64pixel OLEDs in a horizontal layout. I usually print to all of them at the same time. Now, MIOS writes to the displays character by character. So it starts with the first line on the first OLED, goes all the way to the first line of the 9th display and then starts over at the 2nd line of the first display. Since there is a lot of data, it takes time to print to the OLEDs and you really can see how the characters are printed line by line. So my question is: Is there a way to speed up that transfer rate? I googled a bit and found this on an arduino forum: https://forum.arduino.cc/index.php?topic=286837.0 Is it possible to somehow adapt this to MIDIbox? Do you have an idea? Thanks, Chris

I think I ran into this problem also a while ago. Unfortunately I don't have a fix for that issue.