TK.

GMAprogrammer's update issues with v1.030 are now discussed in a separate thread:

Please show me the AIN configuration of your .NGC file And which MBNG version did you use before the update? Best Regards, Thorsten.

Btw.: when you are writing AIN, do you mean the analog inputs of the MBHP_CORE_LPC17 module, or the analog inputs of the MBHP_MF_NG module? And with "not connected" you hopefully mean, that the unused analog inputs are connected to ground to avoid that a core generates random events (e.g. when you touch with your fingers over analog inputs...) Do you mean the faders connected to a MBHP_CORE_LPC17 module, or to a MBHP_MF_NG module? How does your EVENT configuration for this fader look like? Background: I added some extensions for analog input processing, maybe you are using an incomplete configuration which selects an unintended mode? I will probably add a feedback detection into the next firmware version which avoids this situation. But I guess that with the "MidiFileClkOutPorts" command you've a temporary solution which helps at your side, right? Best Regards, Thorsten.

You are writing: Previously you wrote: Does it mean that the previous observation was wrong, and that disconnecting the MBHP_MF_NG module makes a change? Best Regards, Thorsten.

Just to ensure (because it seems that you are an lazy updater... ;-)) - are you using the latest MIOS Studio version? One explanation could be, that you haven't selected the *first* USB MIDI IN and the *first* USB MIDI OUT of the core module in MIOS Studio, but a mixed pair (e.g. first MIDI IN but second MIDI OUT... or similar). Another explanation could be, that you are working under Windows. In this case it's important that you are using MBNG V1.029 or higher (and the latest MIOS Studio version of course) Previous MBNG versions didn't contain the special Windows workaround for multiple USB MIDI Ports. Analog inputs are directly connected to the LPC1769, there is no IC between these connections. When you are writing that they are not working properly, does it mean that they are not working at all, or does it mean that unexpected AIN events are sent? Best Regards, Thorsten.

What happens if you enter following command into the .ngc file: MidiFileClkOutPorts 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Note that you could also enter it interactively into the MIOS Terminal with: ngc MidiFileClkOutPorts 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 If you've used v1.015 before, it doesn't surprise me that the motorfader control wasn't working correctly. A lot of changes have been added until then based on various user requests. Previous releases can be found under: http://www.ucapps.de/mios32/backup/ However, let's focus on the MIDI Clock Stop Command issue - I think that I've to add something into the firmware which prevents such a situation. But I need to find out, what's special in your setup - therefore: than more observations that you could describe, than better. Best Regards, Thorsten.

You are writing "0xfc continuously" - does it mean that there is a delay between each 0xfc (MIDI Clock Stop) event, e.g. 1..10...100 mS? Or is it sent without any delay? Compared to older versions, v1.030 got a MIDI Clock generator which would send 0xfc if it receives the same event from any MIDI IN port. So: which MIDI device could send 0xfc at your side? E.g. any device connected to a MIDI IN port, or maybe your DAW which sends to an USB IN, or could it be related to a feedback loop? Best Regards, Thorsten.

You are right, "force to scale" is always enabled in grid mode: u8 use_scale = 1; // should we use this only for force-to-scale mode? I don't think so - for best "first impression" :) So: actually I wanted to achieve that people are starting with the scaled layout without special options when they are using the BLM. Do you really need the grid mode w/o FTS? Then I've to make this option configurable... Best Regards, Thorsten.

I need more input to understand the situation: - with "doesn't detect it anymore" you mean the MBHP_MF_NG module? - with "port 1" you mean "MIDI IN1"? - who/what receives "fc" at port 1, resp. how did you determine this? - what is your exact .ngc configuration? - anything else special in your setup which would be important to know? Best Regards, Thorsten.

Added to wishlist as well - no problem to add this as an option. Best Regards, Thorsten.

Yes, there are "hidden" implementations of the BLM emulation which have been programmed for MacOS, Juce and Lemur: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fblm_scalar_emulation%2F So: three examples which should give you enough informations. Please study them before asking the next questions... ;-) Up to 256x64 matrices are supported! The BLM will automatically switch to Force-to-Scale when you enable the option in the MODE page. So: the BLM will show reduced note space for each track which enabled this mode. The scale will be configured in Fx->Scale It's maybe also worth to mention that the scale will be considered in the vertical directory in Edit mode, and in horizontal direction in Live Keyboard & Record mode. Best Regards, Thorsten.

That's a complex question which deserves a separate topic! ;-) Finally MIDIbox NG V1.030 has been released with the changes of the last months: MIDIbox NG V1.030 ~~~~~~~~~~~~~~~~~ o increased event pool size to 64k for MBHP_CORE_STM32F4 o added ain_mode=Switch for AIN and AINSER events. Can be used if buttons are connected to analog inputs. The event will send the min value if a 30% threshold is reached, and the max value if a 70% threshold is reached. Schematic: Ground |----o Button o-----> analog input + 10k Pull-Up resistor to 3.3V (AIN) resp. 5V (AINSER) o .ngr: added "change" command. It works similar to the "set" command, but only changes the value, and doesn't generate a MIDI event. o .ngr: added "set_min" and "set_max" command which allows to modify the min/max range of a EVENT o added new meta events to control the internal MIDI clock generator: MClkPlay, MClkStop, MClkPlayStop, MClkPause, MClkDecTempo, MClkIncTempo, MClkSetTempo. Example can be found under cfg/test/midiclk.ngc o added new string formatting items: %t to display MIDI clock state (Play/Stop) %T to display tempo (BPM) o added new MClk menu page to SCS to control the tempo w/o dedicated controllers o fixed AOUT_NG module communication issue if AINSER was used in addition o added new meta events: - CvPitchBend14Bit:<cv-channel> - CvPitchBend7Bit:<cv-channel> - CvPitchRange:<cv-channel> - CvTransposeOctave:<cv-channel> - CvTransposeSemitones:<cv-channel> see cfg/test/cvtransp.ngc for usage examples o BUTTON toggle function can now also handle with inverted and reduced value ranges The user manual has been updated as well: http://www.ucapps.de/midibox_ng_manual.html Best Regards, Thorsten.

The Ambika project is based on an ATmega 644, which has two internal UARTs (= 2 MIDI IN and 2 MIDI OUT) Maybe the option for a second MIDI IN is not prepared on the PCB, but it shouldn't be so difficult to add one (and to enable the second UART in the firmware) - just ask the Author of this project. Best Regards, Thorsten.

I added this to the wishlist (Live FTS not for drum tracks) - will be available in the next release. Best Regards, Thorsten.

Hi, just have a look into the gallery for different options, e.g. this one which is a nice looking wooden case: Based on Ilmenator's PCBs: http://www.midibox.org/dokuwiki/doku.php?id=16x4blm_pcb Gjvti's frontpanel is probably from Schaeffer Apparatebau, here the link to the french pages: http://www.schaeffer-ag.de/fr/ Best Regards, Thorsten.

Implementation is possible without much effort - I added this to the wishlist Best Regards, Thorsten.

Yes, this should be possible. Best Regards, Thorsten.

No, it's running in 8bit mode, see also Best Regards, Thorsten.

I would like to get some more feedback from other users before release to ensure that most people are satisfied with the changes - resp. are there users who don't like the change? You could vary the speed for different encoders in CS_MENU_EncSpeedSet - the part which sets the speed depending on the range is clearly separated and therefore easy to change for your needs. I'm not planning to provide this as a generic option for all people, because it would increase the complexity for adaptions (e.g. if somebody wants to add more encoders, he would have to do changes at one additional place). And streamlining the encoder configuration to simplify changes would be a huge task at my side. Do other users have the same problem like jrp, that rotary encoders need different speed configurations although they control the same range? This is the wrong topic to reply your additional questions - here we talk about encoder behavior optimizations... I would need some time to understand the firmware that I programmed many years ago anyhow to give you sufficient answers... ;-)) Best Regards, Thorsten.

Always nice to read from satisfied users :) Meanwhile I've changed the firmware so that a Record Toggle button would be possible (inherited from MBSEQ V4L) I added this to the wishlist for MBSEQ V4 Best Regards, Thorsten.

Yes, MBSEQ uses a dedicated menu system. Major problem is the screen control, buffering and slow UART based MIDI update speed. Chords: limited to 0x1f, because the remaining bits control the octave Best Regards, Thorsten.

I agree that speed 8 would be nice, on the other hand - as you already noticed - this will lead into more stepiness. In order to compensate this effect for CutOff, you could activate the FIP option in the FIL menu, which smooths the waveform. New firmware available where encoder behaviour should be much better: http://www.ucapps.de/mios/midibox_sid_v2_044_enctest2.zip changed encoder speed modes depending on resolution encoders are fast by default, and SHIFT button slows down encoder speed speed of the "menu" encoder now also varied depending on the resolution. Especially sammichSID users will like this change Please try! Best Regards, Thorsten.

Yes, see http://www.ucapps.de/midibox_ng_manual_ngr.html search for "SET_ACTIVE" Examples are in the cfg/test/multibnk.* scripts Best Regards, Thorsten.

No problem, MBNG uses almost the same "buffered LCD" handler like MBSEQ, which means that the same method can be copy&pasted into the code. There is a problem: the messages should only be print temporary, but the buffered LCD handler expects a static screen. Changing this would lead to a bad MIDI performance. And adding a buffer for this LCD messaging feature at the MBSEQ side would mean less place for more useful features. Since this would only for you, and since I'm sure that you will find other ways (sending LCD strings via EVENT_ commands), I won't implement this. Best Regards, Thorsten.

Yes, in conjunction with MBNG you could also add LED rings if you still prefer rotary encoders. Or you could use pots and/or (motor)faders. Control via SysEx is possible as well of course, but the setup is more difficult, and sending the complete patch takes more time. If you are only interested on a high-res CutOff, then send it as a NRPN parameter, and set the appr. LED ring via the CC dump. Best Regards, Thorsten.