Jump to content

norbim1

Programmer
  • Posts

    77
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by norbim1

  1. Looks really great guys. I've been thinking about building one LoopA V1. I saved a core and a display for it some month ago, but I'll wait for V2 to finish and the pcbs. As far as I see it is a waveshare core in it, isn't it? Regards, Norbim
  2. AFAIK the load command works only from NGR. But never mind, I found the cause in "mbng_file_r.c", corrected and built it and now load commands in conditional branches work correctly. BR Norbim Edit: Attached the diff mbng_file_r.c.diff
  3. The problem is that even the load command is in a conditional branch and the condition doesn't match, the commands after load doesn't execute. In the above example the "load setupA" doesn't execute in the else branch. Also miss the other commands outside the if branch. Is there a meta op that loads a new NGC config? I coluldn't find it in the user manual. Am I miss something? BR Norbim
  4. The same problem for me. By further investigate NGR script doesn't go beyond the load command. Anything after "load <setup>" command doesn't execute. BR Norbim
  5. Hi, In the core module the voltage level setting is working well with the LCD data lines (D0-D7) which are going through the HC595. But there are the control lines (RS, RW, E) which are pulled high with resistors only and the STM32F407 PIN protection diodes allows pulling them up to only somewhere around 4V. I agree, that at the 3.3V jumper setting the OLED overdrives the DISCO vreg, so you should supply it with an external vreg. I just think its way simpler using just one diode at 5V setting, than an external vreg with 3.3V setting.
  6. Hi, In an other project I use Raystrar 4*20 oled display with f4discovery. At first it had similar strange behavior and the probelm was that the oled supplyed with 5V power while the driving data lines provides only about 3V high level due to the direct connection to the stm ports. The 3V is way below the datasheet specified input high level which is 0.9*VDD. My solution was to lower the 5V power to the oled by a diode, but somewhere a 22ohm resistor was suggested to the same problem. Hope this helps. Norbim
  7. Read somewhere that the FreeRTOS in the repository does not includes the Cortex-M4 floating point support, does not support the saving and restoring the vectored floating point registers during context switches. See the #4 tip on this page: https://community.arm.com/docs/DOC-7544
  8. Hi, I used the cheap metal shafted blue one, bought years ego form a Chinese supplier (unfortunately he doesn't sell it anymore) and recently the ALPS with plastic shaft form the above mentioned German source. I was happy with them, both type have good tact feel, smooth running. I've never had any problem with plastic shaft. BR, Norbim
  9. Hi, Regarding the other HW options, I think the F4Discovery modul value for money is still among the best. Currently I'm working on a new solution for BLM16x with the following HW plan: F4Discovery with modified MB BLM firmware, simple 17*17 button matrix directly connected to F4Discovery pins, WS2812 led strip instead of duo leds. If this config is feasible you don't need any other IO module to drive the BLM. The pin assignment has been done, there are enough pins on the disco to direct drive the 17x17 button matrix, the led strip with 289 leds (needs only one out) and one serial Midi IO. The modified MB firmware is 95% ready, but I need to make a test HW. (I'm too busy in this month, so I can't promise anything). Some challenge: power for led strip, mechanical connection of the buttons and leds. The plan is low profile standard tackt buttons on simple perfoboard, SMD diodes on the copper side. The led strip lays on the top of one row of buttons, the next row is the same, but the led strip runs in reverse direction, so the full led strip is connected in a "zigzag" way. BR Norbim
  10. Hi Lee, nice to hear You are on board again. Regarding your question my wav code simply replace the RIFF header in the first block with zeros: if(samplefile_pos[voice_samples[voice]]==0 && samplefile_type[voice_samples[voice]] > RAW_FILE) // WAV file format, do not play the header { for(i=0; i<sizeof(WAVE_FormatTypeDef); i++) { // Fill the sample buffer header with silence samplebyte_buf[voice][i]=0; // Muted output } //DEBUG_MSG("header mute %d",samplefile_type[voice_samples[voice]]); } It causes some delay, but the RIFF header is only 44 bytes long ( canonical wav). The header equals 22 mono or 11 stereo samples which is roughly a half or a quarter of a ms delay, I think it is acceptable.
  11. Hi, Would be very nice feature IMHO. I like the chords with nice chromatic notes in it. Some suggestion: - Current chord table states " // note: chords are used together with the forced-to-scale feature in seq_scale.c ". If we are using foreign (chromatic) notes, it will conflict with fts. My suggestion is using the chord table without fts or the chord generation algorithm should ignore the fts. All the note numbers are chromatically defined in the table, so only the root note should be followed. I think it's a way better implementation than with fts, so you can add some nice colored chords from other scales to the song too. - The Min7 should start with 0, I think. Br. Norbim
  12. norbim1

    MIDIbox KB

    Updated, but caused a HardFault. I have to check my working copy and the tool chain, because I have just changed to W7 from good old XP. It works with the prebuilt ng_v1_033_pre16 (excluding the modified KB handler) without HardFault, so I'm afraid the fault is at my side. Will check tomorrow. Norbim Finally I've successfully built. Ngr from memory works fine.
  13. norbim1

    MIDIbox KB

    Sorry for the late answer: SRIO num_sr=2 debounce_cycles=0 # keyboard configuration KEYBOARD n=1 rows=10 dout_sr1=1 dout_sr2=2 din_sr1=1 din_sr2=2 din_inverted=1 break_inverted=1 din_key_offset=32 scan_velocity=1 scan_optimized=0 note_offset=0 make_debounced=1 delay_fastest=20 delay_fastest_black_keys=0 delay_slowest=500
  14. norbim1

    RGB hue sweep

    What about RGB LEDs with embedded controller? WS2812B based RGB LEDs or LED strips are quite cheap on ebay. Even a long strip or LED chain can be controlled via one wire. As I analyzed the protocol I think DOUT isn't fast enough to drive it, but they might be controlled via direct SPI with some trick. I planned to test it, but didn't have enough time so far. It can be a much easier solution for RGB button LED matrix too.
  15. norbim1

    MIDIbox KB

    Yes, the code was worked out for the second case only, because I need only this option. I know it is not an universal solution, even I'm sure it will not work with non inverted diodes. I soldered my diodes the wrong way by mistake, and it was easier to alter the code than change 138 diodes.... One thing that surely works in NG is break_is_make on for organ style playing.
  16. norbim1

    MIDIbox KB

    Sorry I cant upload at the moment to my playground, but attached the diff. I modified the keyboard.c only in modules/keyboard. Here is my keyboard spec from the NGC file: # keyboard configuration KEYBOARD n=1 rows=10 dout_sr1=1 dout_sr2=2 din_sr1=1 din_sr2=2 din_inverted=1 break_inverted=1 din_key_offset=32 scan_velocity=1 scan_optimized=0 note_offset=0 make_debounced=1 delay_fastest=20 delay_fastest_black_keys=0 delay_slowest=500 Hope this helps. Norbim keyboard.c.diff
  17. norbim1

    MIDIbox KB

    Hi Chris, I built a custom keyboard with inverted diodes, and had the same issue in NG. The solution was a massive rewriting on the nlate mentioned debounce processing code. It works now perfectly without any stacking notes. I will upload my modified routines to the playground as I get close to my PC. Norbim
  18. Booting stable with this version at my side. BR Norbim
  19. Just realized nearly the same HardFault issue, but a different PC number. My Seq works with Wilba CS and LPC17 core. Unfortunately don't know when the problem appeared, it happened first yesterday, when I tried with a Vista PC. Strange thing that it occurred only in Vista permanently, but on my old XP it worked fine. Tried with .089 pre5 and pre6 with the same issue. It worked fine with .088. It happened once on the XP with .089 pre5, but I couldn't repeat it. I think it can be some USB, delay or power issue, because it always works without USB connection. My box uses a power switch to switch the 5V from USB, the one fault occasion on XP was when this switch accidentally left on, and the box booted right after I connected the USB. On Vista the fault was permanent regardless the powering sequence. More tests are planned with external power.
  20. Hi! I had the same pitch mismatch issue on the SD card sample player project. The pitch was approx a half note lower than it should be. It was due to the stm32F4 incorrect I2S PLL divider settings. Code part from my SD sample player fork for the 44.1kHz sample rate, in the SYNTH_Init func: #if defined(MIOS32_FAMILY_STM32F4xx) RCC_PLLI2SCmd(DISABLE); RCC_PLLI2SConfig((uint32_t)271,(uint32_t)2); //I2S PLL dividers for 44100. Values from Stm32f407 RM0090 Reference manual. Chapter 28.4.4, Table 126. MIOS32_I2S_Init (0); #endif. Unfortunately I have no free STM32F4Discovery board at the moment to test the Goom fw, but I hope it's enough info to test it by someone else. BR. Norbim
  21. Don't worry about it. In the "command line" there is the same processor definition (-p p16f88) as in the code (list p=16f88). Can't be any problem as long as these define the same processor.
  22. I'm just reading this topic. I had the same issue in an earlier, not MB related project with Raystar OLED (4*20) and F4Discovery. The solution was to lower the 5V VDD of OLED by a diode. It could be an alternative solution if the 3.3V regulator on the core was overloaded. And this OLED is for 5V VDD according to the type number. Attached a part of my schematics. Anyway these Raystars are really cool LCD alternatives.
  23. I suggest you read the PreenFm2 forum. It has a windows editor in beta state but useful. It can also accept CC or NRPN controls for some parameter changes, these are documented on the project home page.
  24. Hi Reggie, nice project. As I had a spare Discovery board too, I also had examined the Dekrispator synth project to make use the Discovery's onboard codec. Finally I found the PreenFM projekt http://ixox.fr/preenfm2/ which is based on an STM32F405 module (CERB40) but I managed to port it to the STM32F407Discovery board. It's a nice little FM sinth, maybe You can find some usable code parts in it. More info about my porting: http://ixox.fr/forum/index.php?topic=63425.0 https://github.com/norbim1/preenFM2 Regards Norbim
  25. I think, that the MF_NG doesn't read the real resistance value of the pot but the voltage level on the pin instead. It should work with 15k too. I think the problem isn't related to the pot resistance, there should be an other problem. Did you connect the pot the right way? The two end pins should be connected to +5V and GND, Regards, Norbim
×
×
  • Create New...