TK.

Yes, this will work. Now tested here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fconev_6.ngc Best Regards, Thorsten.

I understand your requests, but from my point of view they don't fit with the concepts behind MIDIbox CV. It would be a separate application with a dedicated UI. If you don't mind, I will split your post to a separate topic - maybe somebody else with programming skills is interested to help you... Best Regards, Thorsten.

yes Best Regards, Thorsten.

I won't delete this topic, because it's a useful confirmation that two chained MBHP_AOUT_NG modules are working :) Best Regards, Thorsten.

I'm using the feedback option in almost all bassline demos, e.g. in this one: http://www.ucapps.de/mp3/midibox_sid/mbsid_v2_tk2_soundbank_demo.mp3 However, the signal/noise ratio is very poor, which means that the option will only work for loud music... ;-) Best Regards, Thorsten.

I know what you mean, because I had the same impression and see the need for improvements. But it won't be trivial, especially since a (more than 10 years old) routine in MIOS8 has to be overworked, and this will be *very* time consuming. However, meanwhile I got the idea that I could try to improve this in MIOS32 first, which has the same algorithm. And once I'm happy, I could translate it into the (assembly based) MIOS8. Hopefully it will be possible without consuming additional RAM, because there is no free RAM available in MIOS8... Best Regards, Thorsten.

A SID player can switch between multiple patches quickly (almost zero-time) because it has direct access to the "patch memory". MIDIbox SID has to load patches from an external EEPROM instead, this consumes time and the amount of time depends on the patch size. During the development phase of the firmware (ca. 7 years ago) the first beta users preferred to get as many sound features as possible. This was leading to an increased patch size, and this was in contradiction to the patch load speed, but it has been accepted. So, somebody could implement an alternative firmware with much less sound features, but faster patch load time. Or somebody could use a more modern microcontroller with enough embedded RAM (or fast access to external memory) to overcome such limitations. It wouldn't be in my own scope, because I'm happy with the implementation. Best Regards, Thorsten.

Ok, I added to the wishlist that an "expert option" should be added which allows to disable this default behaviour (means: FTS only if enabled in the MODE page) Best Regards, Thorsten.

Alright, one issue solved :) Could you please try this version? It should work without compatibility issues: -> http://www.ucapps.de/mios32/midibox_ng_v1_031_pre1.zip To the query issue: it would be interesting if Query works again if you disconnect/re-connect the core and restart MIOS Studio. If this doesn't help: does it work after a Windows reboot? Best Regards, Thorsten.

The changed behaviour in V1.030 is related to the new Switch function, which ensures that a NoteOn/Off event is only sent once as requested here: So, you have a different use case which I haven't considered: you want to send continuous Note On events from an analog input like somebody is normally doing with CCs, right? Here a modified version which disables the change for "AIN Switches", so that you can proceed with the analysis: http://www.ucapps.de/mios32/midibox_ng_v1_031_modified_ain_notes.zip Unfortunately this won't satisfy the needs of dOperator anymore... :-( In future it will be required to enhance the EVENT_AIN configuration in order to select one of the contradicting use cases. I did another change in this version: "MIDI Clock Inputs" are disabled by default now. Could you please check if the "MidiFileClkOutPorts" workaround is still required at your side? Best Regards, Thorsten.

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.