Jump to content

FantomXR

Members
  • Posts

    1,035
  • Joined

  • Last visited

  • Days Won

    22

Everything posted by FantomXR

  1. Hey people, it's me again! ;-) Since @Zam helped me solving a problem, I have another one. My setup is a keyboard and some RGBLEDs. If I now press C3 I'd like the corresponding RGBLED to light up. Of course I could do this by entering tons of receivers and senders but I'm looking for a smarter solution. I tried several things. The most promising was, that I'm able to convert the pressed key into another command f.e. if I press C3, NG outputs CC60, if I press B2, it outputs CC59, and so on. What I'm looking for is kind of this (which is not working at the moment but it makes it more clear): EVENT_RECEIVER id=1001 type=NoteOn key=any use_key_number=1 fwd_id=RGBLED:^value The last command is not supported in NGC. In NGR there is a ^value-command, but I can not use it for this purpose. Any idea how to do that? Thanks! Best, Chris
  2. Hey people, I use a STM-core running MBKB for scanning my keybed. The core is connected to another core via direct-connection which works perfect. This core runs MB_NG. The 2nd core is connected to a computer. I'd like to use the receiver / sender functionality to transform the notes coming from the keybed. So at first I set up the router which forwards the IN4 to USB1. This works great. Now I add a receiver. Something like this: EVENT_RECEIVER id=1001 type=NoteOn key=any use_key_number=1 fwd_id=SENDER:1001 EVENT_SENDER id=1001 type=CC cc=1 What I'd expect is, that NG uses the key-number to output the corresponding cc-value. But that is not working. Also tried a very simple forwarding mechanism: EVENT_RECEIVER id=1001 type=NoteOn key=any use_key_number=1 fwd_id=SENDER:1001 EVENT_SENDER id=1001 type=NoteOn key=any use_key_number=1 Here I'd expect, that MB_NG generates the same notes twice at the USB1 output. The first coming from the router directly, the second from the receiver / sender. But this also doesn't work. I'm sure that I overlook something. Does anyone have an idea? Best, Chris
  3. Dear TK, thanks for your reply. Alright, I'll add this resistor. For the other "problem" I'll try to add a hardware delay with RC circuit to prevent the LED from flashing.
  4. Hey people, I have two questions regarding the WS2812. If you read through the internet you will find various articles that one should use a resistor between DIN of the LED and the output-pin of the microcontroller. Is that also right for the STM32F4? The second thing is, that the first (or sometimes an other) LED lights up short after a few seconds after powering the core (both share the same power supply). Any ideas how to prevent this? Thanks, Chris
  5. Hi, I'm pretty sure that you will not achieve a result that comforts you or your father in law with normal switches. There are other systems out on the market (PNOScan from QRS) which are perfect for this purpose because they use some kind of infrared-sensors and work without mechanical contact to the keys. This makes it very easy to set the deadbands and the correct brake / make points per key. Maybe you should save work and time and go with this system even if it's not that cheap (about 1200€ or so).
  6. Might be! But today I tried to add two 0.5mm wires for GND and VRef.... without any success. I checked again the NGC-File. I was wrong. I checked the faders at 7bit, which works okay and not with 11bit like I stated above. The jitter only happens when switching colors. With 11bit it doesn't even matter if the LEDs are connected. The fader jitter all the time. Anyway: I really do not need 11bit on the faders. 7bit is totally sufficient. 11bit I do only need for the pitchbend-wheel. All other controllers (also foot controller) will work fine with 7bit. So if it would be possible to set the resolution on a per-pin-base, it would be the easiest solution. Maybe I could hardcode the pitchwheel.... I think I need to dig deeper into the code. Maybe @TK. can help here?
  7. I was at my local electronic-shop today and got a LM3940 which makes 3.3V out of 5V. And here is something strange: Lets take the original schematic from the AINSER64 which is basically what I use. If I do not set the jumper J5 at all, I still am able to read out the potentiometer with nearly the full range (starts at 1 instead of 0 and goes up to 125 instead of 127). I'd expect that I either get jittering values or I'm not able to read out the potentiometer in total. I tried to connect the 3.3V to the Vref of the MCP3208. Now I'd expect that I can read out the faders but wouldn't reach 127, because I have not configured them in the NGC via pinrange for 3.3V. But nothing changes here... I get the fullrange of the potentiometer. But jittering continues as soon as I change the colors on the LEDs.... //edit: I measured the voltage when connecting 3.3V to VREF. It seems to be right. At the faders I measure 3.3V and not 5V anymore. I'll do another test with a separate power supply for the LEDs again...
  8. And two side notes: I'm running at 11bit resolution and the faders I use are Bourns PTA4553 at 10k linear.
  9. Sounds like a plan! I'll report! ;-) Thanks!
  10. Thanks for your suggestions! I'll keep an eye on it again tomorrow. I took a look into the LM317 datasheet and it looks like it needs Vin - Vout = 5V, which is with 5V = Vin not possible. If I want to use another source for Vref, do I just need to change the source for Vref or also for VDD of the MCP3208? And the 10Ohm resistor than is no longer needed? Thanks!
  11. @Zam: I followed up on this today. Meanwhile I received the new PCBs where the LEDs are not sitting on the fader-PCBs. The jitter has improved a lot. Thanks for the suggestion. I also tried, not using the USB-power directly from a computer which also improved the stability and the jitter-issues. Anyway: If both PCBs (and the core of course) are powered from the same power supply, I still get some jittering. Way less than before. But it's still there. The only solution for now is, to use a totally separate power supply for the LEDs, but share GND with the core & fader PCB. This works great... but I'm not totally satisfied with using two power supplies. I did some experimenting with direct USB-power. Like I wrote it's not good, to power everything from the same port. But, and that is kind of weird, if I use one USB-port for the core & faders / AIN and another USB-port from the same computer for the LEDs, it works great too. I don't think it has something to do with power consumption because I tested it with 16 LEDs at low brightness. They shouldn't draw too much current. I also measured with an oscilloscope. I'm not very experienced with that... but I noticed some voltage drop when switching the colors from the LEDs and it seems that this will influence the AIN. So my question is: Is there a way to power everything from one power supply but add some filtering before the LEDs (or AIN?) ? Do you have any recommendations on this? Thanks! Chris
  12. Alright. I found a way to boost the brightness of the OLEDs. It's in the app_lcd.c of the universal-driver folder in line 678 APP_LCD_Cmd(0x7f); // middle change it to APP_LCD_Cmd(0xff); // high done! But anyway: My new oleds are still much darker than the other ones....
  13. Hey out there, I received another bunch of OLEDs from China and they are much darker than the others I had before. Is there any solution on the software-side for that issue? I don't know what I need to change on the hardware-side / on the OLEDs to make them brighter.... Thanks, Chris
  14. Dear TK! Thanks for clearing this up. Yes, I can define unique MIDI ports in my host. But a definition in the driver would be ideal. Anyway: If it's not possible, we can't do anything! Best, Chris
  15. Yes, I know. But you have to adjust not only the MIOS32_USB_MIDI_NUM_PORTS. You also have to edit the midi_port.c in the midi_router-folder. Otherwise the terminal will give you error messages about invalid output and input ports if you try to use the midibox-router. Thanks for the hint... I'll have a look.
  16. Dear Peter, that problem I fixed already. See here:
  17. Hey people, I'm not sure if this has been asked before (maybe by me?!) but I was not able to find something with the search engine. I'd like to know if there is a way to assign individual names to the four USB ports the midibox provides when connecting to a windows computer? Thanks, Chris
  18. Hi! Any ideas for the whole thing / eveything?
  19. Why don't you call nothing with section == 0 but assign metas to the buttons directly so that they load a NGC file when hitting them?
  20. FantomXR

    RGB hue sweep

    It seems that I've got it working. I changed in ws2812.c this line #define WS2812_BUFFER_SIZE (((WS2812_NUM_LEDS+2)*24)) // +2*24 to insert the RESET frame to #define WS2812_BUFFER_SIZE (((WS2812_NUM_LEDS+2)*24)+200) // +2*24 to insert the RESET frame because of the 300us reset, the 2017 WS2812B need. The LEDs are now working. I didn't do a mass-test, but it looks promising.
  21. FantomXR

    RGB hue sweep

    There is a post from Adafruit where they report the new LEDs. And they say that they had to adjust the reset-time and everything went well again. But in the midibox code I do not see any kind of reset-feature....
  22. FantomXR

    RGB hue sweep

    Thanks for that hint! I found that document: Now I need to figure out, how I make the adjustments to the firmware.... if even possible?
  23. FantomXR

    RGB hue sweep

    Hey people, I ordered a new bunch of WS2812B LEDs. The problem: They are not working! I tested them in the same environment as the last bunch, which worked great. But the new LEDs do not. I at first thought that I received the wrong LEDs. But I doublechecked with an Arduino and they work well on those as well as my old LEDs. I tried to replace the pullup with a 470Ohm and a 10k but both is not working. Any ideas?
×
×
  • Create New...