tago

@Phatline Here the pcb layout. There is a voltage reference (U3) (center bottom - looks like a transistor) and on the right side an opamp (U2) to scale the voltage range because of the limited rotation angles of the wheel pots. I did that with the help and recommendation of @FantomXR and others. Can't find the original thread at the moment. See how the Vref (red) goes to the opamp (U2) and then to the jumper J8 where both wheels are connected to.

Hi Phatline, i'm using an AINSER8 module (see that perf board on the third photo). So pots aren't directly connected to the core. Power is coming via USB. I'll take a look into the docs for a middle offset function. I think Doepfer is calling it 'plateau' on their keyboard controller boards. I assume there is no way around something like that. EDIT: do you think it could be because the pot is old/used?

Hi, I built two identical controller keyboards using CORE_STM32F4 running MIDIbox NG. They currently feature analog ins, two wheels and octave up/down buttons. It was very hard and time consuming to build these without a proper workshop (used mainly beech wood and aluminium). Issues: #1 One big problem i have is that the velocity resolution is very low. It looks like just 5-10 values are generated, nothing in between. It's too coarse for playing properly. #2 Another problem is that i get random pitch wheel values when in zero position. I wonder if there is kind of a plateau range around the zero position to mitigate that. Or maybe it's because of a faulty pot? Thanks for your help

@Hawkeye Thanks for providing more details and trying to fix this issue. I know what you mean by rescanning/reconnecting the Core after uploading via MIOS Studio. It's not ideal but workable. I really hope Thorsten will look into it and update the toolchain. Getting an additional computer is really a hassle. This hobby is already expensive enough. It should also help to get more people onboard with MidiBox, having lower hurdles.

Do you mean stable USB drivers for development purposes? I'd only use a Hackintosh/Mac to be able to compile an app, not for music making, if there is no other way around it. Do you know who did the original Windows toolchain?

Thanks @Hawkeye A pity Windows is not supported anymore. I think that's makes it lesser accessible to us Windows people. Is there really no one in reach who has the chops to update the toolchain? For the love of the Midibox project. If i only had an idea about those things, i would do it. Maybe i can go the Hackintosh route, but that sounds like much work better invested in other things. So with a Hackintosh i can compile the most recent NG app? @TK. What do you think about the situation? Any chance to get it working for Windows/Linux again?

Hi, Any tips how to optimize NG to get better velocity performance? I'm getting very few velocities. I'm getting a very coarse velocitiy resolution. I'm using a STM32F4 core and have a 5 octave keyboard plus an AINSER8 attached. No menu or displays. I'm thankful for any tips.

Any news on this? @Hawkeye

Any news regarding the Windows compilation issue?

Here is some talk about open vs closed: https://forum.arduino.cc/index.php?topic=695264.0 In the second post someone says: "One disadvantage of a N/C is that with a pullup, as most switches spend the majority of their time in the un-pressed state, you will have increase current consumption." If this is correct i'd get a normally open pedal.

Ok, i found an answer here http://midibox.org/forums/topic/20751-fatar-tp40l-midification/?do=findComment&comment=181241 If this is the best way, i'd like to know what kind of pedal is the best. Normally closed or normally open?

I'm no expert. I guess you should see debug output in the MIOS Studio terminal. Search for "debug" in http://www.ucapps.de/midibox_ng_manual_fs.html

Hi, i want to add a sustain panel to my NG based keyboard controller. Which switch type is the best? Normally closed or normally open? (i somehow think normally open would be better, because the circuit is only closed on press = less energy consumption) What would be the best way to connect them? Via analog or digital input? Thank you

@m.str What apps do you run on your controllers? How are the banked menu items displayed exactly? Can you changed them per menu encoder? Thank you!

I've tried banking 8 pots and get little bars for each event on the second line of the display, but can't find a way to display the corresponding labels and change the values just using the menu encoder. I think i need something like an generic EVENT without any hardware control associated to it.

Thanks @m.str yes, i'm talking about the NG app. I'll give banks it a try.

Hi @m.str yes i've considered banks, but think that isn't what i really want. Does banking display the items of each bank in the display like a normal menu without the need of dedicated hardware controls? As i understand it, it can build banks of hardware inputs (ie 8 encoders in a row). Thanks

Hi, i'd like to add some pages for various parameters to the menu. Those parameters will be normal midi parameter/CC and should send midi events. It seems like the current menu system is directly coded in C. Is there a way to add menu items or submenus per config file (NGC for example)? Thanks in advance

Thanks for looking into it @Hawkeye ps can't find a like or thank you button

It would be nice if someone who knows a thing or two about the toolchain stuff could look into this. Thanks in advance.

After looking through the code for hours there is no solution in sight. It looks like SCS code is derived from SEQ V4. So it should be possible to configure. I've uploaded the SEQ app which was working as expected. Comparing NG and SEQ code wasn't that helpful. SEQ has a much more complex UI system, but the underlying menu handling should be the same.

In scs_lcd.c it says //! The 2x80 screen is buffered and can be output over multiple LCDs //! (e.g. 2 * 2x40, but also 4 * 2x20) //! By default we configure this driver to support a single LCD with the size //! 2x<SCS_NUM_MENU_ITEMS*SCS_MENU_ITEM_WIDTH> (see scs_lcd.h, this size //! can be overruled from external, e.g. in mios32_config.h) I've tried to overwrite SCS_LCD_NUM_DEVICES in NG's mios32_config.h by adding "#define SCS_LCD_NUM_DEVICES 2" and overwriting it directly in scs_lcd.h without success. Any idea how i can enable two devices? Edit: My two displays a basically working.I already tried to increase SCS num_items and a bigger font to get some overflow.

Hi, i'd like to put 2 or more little OLED displays next to each other and have the SCS shown across those displays (as one). Is there a way to do it? Thanks in advance

Thanks Peter, reverting back before the WS2812 change works. If i only had some experience with C, i 'd be glad to help. But that's defnitely too complicated for me. I hope there will be a better solution. Best

I tried an older altered NG app hex file which still works. It really looks like it doesn't compile correctly anymore. But what has changed? I think my toolchain hasn't changed. Unfortunately i don't have a Mac at my disposal.