TK.

MIOS Studio can connect via MIDI IN1/OUT1 But you could also change the router configuration in DEFAULT.NGC via an USB based connection to MIOS Studio before connecting the keyboard. Best Regards, Thorsten.

Which MIDIbox application? Best Regards, Thorsten.

Hi, the MIOS terminal and SD Card Filebrowser are not supported by the bootloader (which is a minimal program which only allows to update the application). Did I capture this correctly: the USB connection is working with the bootloader, but it isn't working with the MIDIbox SEQ application? Could you please try some other MIOS32 applications like MIDIO128 or MIDIbox NG to check if USB is working with these applications? Please upload the applications via MIDI in bootloader mode. Best Regards, Thorsten.

Yes, the bootloader is already part of the firmware, and USB should work by default, no additional measures required. Let's start with the stupid questions: are you sure that your Micro USB cable is working? I mention this, since some mobile phones come with cables which can only be used to supply power for charging, but they can't be used for a data connection did you already doublecheck in the windows system control panel, if a USB device has been detected but disabled? There are situations in Windows, where it will be disabled, e.g. when you disconnect the cable during the first registration of the new device. It helps to remove the disabled USB interface, and to reconnect the cable if this doesn't help - just to be sure (because you are working under windows...) Did you already try to turn your PC off and on again? ;-) Best Regards, Thorsten. P.S.: the firmware version is V4.089, not 0.89

Hi Lamster, it's probably better if you would start with MIDIbox NG: http://www.ucapps.de/midibox_ng.html It's a configurable MIDI controller which should fit for your needs (see the user manual, especially the "first steps" section). And it supports the same keyboard scan routine like MIDIbox KB (see KEYBOARD command in the .NGC section), and the drawbars could be connected to a MBHP_AINSER64 module. Best Regards, Thorsten.

While thinking about possible reasons, I noticed the following in your setup: # Matrix for pedalboard DIN_MATRIX n= 1 rows=4 inverted_sel=1 inverted_row=0 mirrored_row=0 \ sr_dout_sel1= 1 sr_dout_sel2= 2 sr_din1= 1 sr_din2= 2 button_emu_id_offset=1001 # Matrix for both manuals DIN_MATRIX n= 2 rows=8 inverted_sel=1 inverted_row=1 mirrored_row=0 \ sr_dout_sel1= 3 sr_dout_sel2= 4 sr_din1= 3 sr_din2= 4 button_emu_id_offset=1033 DIN Matrix #1 has a 4x16 configuration, accordingly the emu_id_offset ranges from 1001..1064 But I guess that only two rows are connected, the two remaining rows are not used. DIN Matrix #2 starts at emu_id_offset 1033, which overlays the upper (unused) range of DIN matrix #1 Now let's assume that there is a glitch while DIN Matrix #1 scans row #3 or #4: in this case, an event in the range id=1033..1064 would be emitted, although it doesn't belong to Matrix #2. I haven't checked further if the hypothesis is true, but I would propose to change button_emu_id_offset=1065 for Matrix #2, and to change the corresponding EVENT_BUTTON ids as well and check what happens. For the next overnight-run, please also enable debug mode which will output some additional information (such as the row/column which triggered the event): set debug on There is currently no function in MIOS Studio which allows to store the window content directly into a file, but maybe I will add it into one of the next releases. Best Regards, Thorsten.

This is a protection for people who don't refresh the page to ensure that they won't download the wrong version... I clearly stated that the new version is called blm_scalar_v1_1, you even quoted it! -> if you see the version blm_scalar_v1_0whatever, you obviously haven't refreshed the page in your webbrowser. Best Regards, Thorsten.

What is the purpose of these unmounted parts? Best Regards, Thorsten.

The Mini-Core module has 4 additional analog inputs which are unconnected, and should be tied to ground to avoid that random CC values are transmitted if the project_with_8_mapped_ains.hex firmware is used. Alternatively (instead of grounding the pins) you can use the project_with_4_mapped_ains.hex file - because it won't scan the unusued analog pins. Andy has to help here based on the unpublished layout data. Best Regards, Thorsten.

I don't know from where this error should come from. It seems more related to your installation (maybe a GLib incompatibility with legacy Juce builds?) However, your snapshot shows an interesting detail: the path selection box (left to the Browse button) shows the error message instead of the file path. Accordingly it seems that GTK tries to pass the error message to the file selection box instead of the actual selected file name. It would be interesting what happens if you enter the (complete) path to the project.hex file directly into this box? At least I can confirm that this is an alternative way to load a file - and it might help at your side since the file browser isn't involved! Best Regards, Thorsten. P.S: that's the reason why I prefer reliable Linux derivatives which are at least 1 year old, but still maintained - never use the latest versions, or you are in the pole position for hunting bugs! ;-) E.g. @Work we're using RHEL6 which was released in 2010, and we don't plan to switch in the next 4..5 years to avoid unnecessary troubleshooting.

Some updates from my side: 1) a new firmware blm_scalar_v1_1 can be downloaded from http://www.ucapps.de/mios_download.html It contains prebuilt hex files for various hardware configurations: o project_without_ain.hex -> without AIN enabled (use this if J5 pins not connected to ground) o project_with_4_mapped_ains.hex -> for Latigid On's BLM PCB layout, only 4 faders used o project_with_4_unmapped_ains.hex -> AIN pins are mapped 1:1 o project_with_8_mapped_ains.hex -> for Latigid On's BLM PCB layout if 4 faders + 4 extension AINs are used o project_with_8_unmapped_ains.hex -> AIN pins are mapped 1:1 2) if you are using a PIC18F452, it's required to change the PIC device configuration while flashing the bootloader: the brown out reset level has to be changed from 4.5V to 2.7V as shown in this picture: Otherwise PIC could be reset sporadically (depending on the number of enabled LEDs) because the voltage level could fall below 4.5V! This change is only required for PIC18F452, other pics (such as PIC18F4620 and PIC18F4685 will work w/o this change). Unfortunately this change can only be done with a PIC programmer. Please contact me for the case that you don't own a PIC programmer. I could send you a replacement PIC18F452 Alternatively use a PIC18F4620 or PIC18F4685 if you own one Best Regards, Thorsten.

Besten dank! Habe den Link korrigiert. Mir ist aufgefallen, dass das Wiki die MBSEQ V4 Konfiguration nicht ausreichend beschreibt - gibt es freiwillige, die das nachholen? Gruss, Thorsten.

say HELLO to your HACKABLE device! Best Regards, Thorsten.

Here is the MIOS32 app which allows you to connect the matrix directly to a 32bit core: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2F Best Regards, Thorsten.

Hi, there are no known problems, and I'm using the file editor whenever I'm working on MBNG, and I never noticed such an effect. Note that the file editor works independent from the bootloader, the communication interface is implemented in the application. It seems that after each quote (") two ÂÂ are added, except for the LCD command, where we see a different scheme. Could it be that you edited the file with a different editor (which inserted these characters for some reasons) and then uploaded to the SD Card? Best Regards, Thorsten.

With relative changes the sound will be different with each keypress - that's a feature! (of course, not so relevant for the waveform parameter, but nice for some other parameters) Best Regards, Thorsten.

Added to the wishlist. Best Regards, Thorsten.

The usage of these IO pins is not recommended for new MIDIbox SEQ builds, therefore you won't find information about this legacy option at my website (this should also avoid In future, DOUT based outputs should be used. They have many advantages (especially the scaleability: e.g. we've 8 individual clock outs with separate clock dividers) Best Regards, Thorsten.

Die Weiterleitung sollte wieder funktionieren. Gruss, Thorsten.

Which parts of the MBHP_CORE module are not mounted? E.g. the two pull-ups for the IIC EEPROM are essential. And the pull-up + diode for the CAN interface as well (as you mentioned in 8. - please ensure that these components are still connected). Topic 9. would work as well - it's important that the CAN (and EEPROM) interface are at a defined voltage level and not floating. Best Regards, Thorsten.

No, there is no way with the current firmware. Which possibilities do you have with your MIDI controller? Would SysEx be fine? Best Regards, Thorsten.

I won't have the possibility to help you on this issue the next days... Best Regards, Thorsten.

Alright, this was finally the hint which helped me to reproduce the issue. It's related to the fact that with newer MacOS versions MIOS Studio is running in 64bit mode, with older MacOS versions it was running fine in 32bit mode. The OSC parser is inherited from MIOS32 (and not MIOS64... ;-) It needs some time at my side to handle 64bit properly - after christmas... Best Regards, Thorsten.

I checked this, and it turned out that it isn't so easy to switch to a valid step view within the track range, because some other functions such as scroll, copy+paste, etc. wouldn't work properly anymore. However, I just release the official V4.090, which provides the possibility to restore the track selections for each individual track (new option: 9/16) which might help. The other requests haven't been considered in this release yet - as you can see in the CHANGELOG, there are many unsolved items in the wish list which I would like to consider before I can start with (consolidated) improvements for the BLM. Best Regards, Thorsten. P.S.: I moved this side discussion to the BLM feature request thread.

I've to come back to this topic: it turned out, that will will become an expensive function (RAM wise) once the random generator will be enhanced based on several open feature requests on the wish list. How important is this request? Best Regards, Thorsten.