TK.

Yes, this was due a conflict with the step recording feature. On the other hand it's probably a good idea to allow selection mask changes as long as the ALL button is pressed, I will consider this in the next release. Yes and no - so: Yo ;-) The ramp is a special implementation that I did for the EDIT page. I would have to write dedicated code for other pages as well to make this happen, on the other hand I wouldn't do this without knowing an attractive use case. Best Regards, Thorsten.

Also doch der LM317... ich dachte eigentlich, der waere "unkaputtbar" Das ist so gedacht. Wenn Du nur einen einzigen Fader bewegen moechtest, koenntest Du dies auch mit dem "Direct Move" Wert veranlassen. Gruss, Thorsten.

That's strange indeed! Did you build a PIC16F or PIC18F based MIDIbox64? And does the Query button in MIOS Studio detect your MIDIbox? Best Regards, Thorsten.

No, there is no MIDI Learn function for SysEx, and I'm not planning to add this. Best Regards, Thorsten.

Hi Kike, are you using your MIDIbox together with a LCD and the 4 menu navigation buttons? Then you could just assign different MIDI events, e.g. via MIDI learn. Or are you working under Windows? Then you could configure the MIDIbox remotely with the MIDIbox64 Editor: http://www.ucapps.de/midibox64.html Best Regards, Thorsten.

Thank's a lot for starting this initiative! Your articles are very nice to read and contain many details which might not be obvious for many people who haven't followed the development progress in the last years. I hope that other users will contribute as well :) Best Regards, Thorsten.

I agree that these functions will be useful; let's collect more ideas before I implement the changes. To summarize from my point of view: - if 16x8 layout is selected, Button 3 should toggle between track 1-8/9-16 and indicate the current selected track range with the LED colour. - a button to select alternative functions will be necessary. I will call it ALT (instead of SHIFT, because SHIFT is used for other purposes). - ALT available at the lowest button (16x8 layout: Button 8, 16x16 layout: Button 16) - Users of the original BLM16x16+X hardware have to press SHIFT and ALT at once to get access over the functions. Users of the emulation have direct access to the ALT button. In GRID and KEYBOARD mode the ALT button will allow to select the octave with button 1-7. Octave from C-0, C-1, C-2, C-3, C-4, C-5, C-6 (C-3 by default) 16x16 layout: all octaves can be selected, not only 7 In TRACKS and PATTERNS mode the ALT functions are not allocated yet. Feel free to request features for the "free slots". Best Regards, Thorsten.

Great! :) ok, I added this info to the webpage: apt-get install libfreetype6-dev:i386 libasound2-dev:i386 libasound2-plugins:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev:i386 Best Regards, Thorsten.

This is strange, something is different in your toolchain setup - I never had the situation that close() isn't available under Linux, maybe google will help you? I'm using "gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3" However, I think that the change was successful: now the access to midiInQueue is protected with a lock. Without the lock I can reproduce the error, with the lock messages won't get lost. Here the prebuilt binary: http://www.ucapps.de/midibox_blm/MIDIbox_BLM_1_2.tar.gz Best Regards, Thorsten.

Update: I remember that I had a similar issue in MIOS Studio and solved this with a ScopeLock - I will keep you updated if it helps. Best Regards, Thorsten.

Ok, these are no good news. :-( As you can see in the diff, for Linux I'm calling the MIDI parser (which is doing some GUI updates) directly whenever new MIDI messages are received instead of putting the messages into a queue for later processing from a timer callback: http://svnmios.midibox.org/comp.php?repname=svn.mios32&compare[]=%2Ftrunk%2Ftools%2Fblm_scalar_emulation%2Fjuce%2FSource@2056&compare[]=%2Ftrunk%2Ftools%2Fblm_scalar_emulation%2Fjuce%2FSource@2058 This measure was necessary for MacOS, and it seems that it's also required for Linux (although the app didn't crash at my side... maybe because the timing conditions on my slow laptop are different). On the other hand it seems that the queue doesn't work reliable under Linux - maybe because it isn't thread-safe. I need some time to understand the backgrounds before I can provide a proper solution for Linux. If anybody wants to try it out by himself: the sources are in the repository under tools/blm_scalar_emulation/juce In order to build the application, just change to the Builds/Linux directory and enter "make" Best Regards, Thorsten.

Thanks for testing! :smile: I was able to reproduce the problem, it only happened under Linux and was related to a special method that I added for MacOS. It should be fixed now. The official binaries (MIDIbox_BLM_1_1) are now available under: http://www.ucapps.de/midibox_seq_manual_blm.html The 32bit build is intended, because my good old Linux laptop which I'm using for testing can't run in 64bit mode, and I guess that some other users could have the same problem. A 64bit build won't give us any advantages anyhow. Best Regards, Thorsten.

Here is the MIDIbox SEQ V4 firmware: http://www.ucapps.de/mios32/midibox_seq_v4_087_pre1.zip Here a (temporary) BLM build for Linux: /edit: removed, now available at http://www.ucapps.de/midibox_seq_manual_blm.html After you've started the BLM emulation, select the MIDI IN/OUT port which connects to your MBSEQ. Don't take the 1st USB port (normally used for other purposes), I usually take the 3rd In the MBSEQ MIDI->Misc page, select USB3 (for the 3rd USB MIDI port) Back to the BLM emulation: select the "16x8+X" layout and click on the "Ext. Controllers" button and configure the MIDI ports to which your Launchpads are connected, and the "rotation" (this is freely configurable, but I only tested 270° for the first, and 0° for the second Launchpad as you can see on the photo above). It's currently too late in Europe to give you more details (or test the BLM emulation under Linux)... More informations tomorrow - just try out whatever is possible today. It also makes sense to start a separate thread for this topic, because I think that you will have a lot of questions and proposals ;) Best Regards, Thorsten.

Hallo, nein, das sollte nicht sein. Vielleicht ein Kurzschluss? Nimm mal alle L293D ICs aus den Sockeln, ist Vm dann wieder normal? Gruss, Thorsten.

I've enhanced the BLM Emulation so that it supports Novation Launchpads, and I updated the MBSEQ V4 firmware so that it properly supports 16x8 matrices. Up to 4 Novation Launchpads can be connected to emulate a complete BLM16x16+X, here only two for a BLM16x8+X The BLM Emulator is currently only tested under MacOS, but it should also run under Windows and Linux. @borfo: which OS do you prefer? I could build & test the binary for you. Best Regards, Thorsten.

Yes, it may be less intuitive (but that's also a question of good documentation... you could help me to improve this :smile:) Maybe it's implemented this way because I thought a step further: it makes sense to control transpose and root note centrally (from loopback tracks or from an external keyboard). Mostly you want to transpose the root note as well, but there are also cases where it makes sense to keep the root note as demonstrated in the tutorial. yes: with root="keyb", the root note will be set according to the notes which are received from Bus1 (and only from this one). Which means: if you would like to get an independent control over root note and track transpose, then send the notes which should target the transposer from another loopback track to different bus. Best Regards, Thorsten.

Hi, Yes, but this is exactly what the text above the configuration option wants to say: ;; select the BankStick type you are using here: ;; 0: "normal" 24LC256 EEPROM (32k), up to 8 EEPROMs can be connected for 8 banks ;; 1: 24LC512 EEPROM (64k), up to 4 EEPROMs can be connected for 8 banks ;; (it is not possible to mix 32k with 64k EEPROMs, more than 4 64k devices not supported) 24LC256: 8 EEPROMS, 8 banks 24LC512: 4 EEPROMS, 8 banks Means: one 24LC512, 2 banks, two times a rising sound during startup, alright? :) See http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v1%2Fdoc%2Fsid_cc_implementation_chart.txt CC # | Hex | Description | Range | Reset =====+=====+==============================================+=============+====== 0 | 00h | Bank change | 0-7: bank | 0 Best Regards, Thorsten.

In MBSEQ you would transpose the notes played by a track centrally from a loopback track or external keyboard. Advantage: all tracks follow the transpose note (or chord if arpeggiator is used) at once. For those who prefer separate control, they could use different transpose/arpeggiator busses. 4 Busses are available, which should be sufficient (I never used more than 2 busses by myself) @Daniel: I will reply to other ideas sooner or later (piecewise) Best Regards, Thorsten.

Some words how something similar could be achieved with the current firmware: The force-to-scale function allows you to set the root note to the one which is received from the transposer. Means: if you transpose from C to D (Track mode set to Transpose in the MODE menu page), the scale root will be automatically shifted by +2 and the played chords would still be proper major, playing the i, ii, iii, iv, v, vi, and vii and some other combinations depending on the selected chord number. The transpose function has to be enabled for the track similar to this tutorial: http://www.ucapps.de/midibox_seq_manual_tut3.html Only difference is, that you would set Root=Keyb in the MENU->Fx-Scale page. Note also, that it's possible to control the root note from a loopback track as well (there is a CC for this) Are you already aware of this possibility, or is this new to you? Well, easy: just use a drum track and configure the notes for the different trigger layers according to the chord members you want to play. Enable force to scale, and take either a static root note, or set the root note to Keyb Would this already solve your request? Best Regards, Thorsten.

-> http://www.ucapps.de/midibox_seq_manual_in.html Best Regards, Thorsten.

Yes, it will be integrated into the Juce based emulator. Of course, it can be compiled for Linux, and with a newer Juce version it should even be possible to compile it for a Raspberry Pi which then will be the cheapest solution to connect the controllers. ;) Best Regardsm, Thorsten.

No, I've haven't implemented the required code yet... Best Regards, Thorsten.

An update on the Novation Launchpad Mini experiment: I got the devices today. The adaption shouldn't be so difficult, although we will miss the second half of the original BLM16x16+X, and MBSEQ will also be loaded much more due to the poor LED control protocol (even the "optimized" solution is multiple times slower than my own protocol, especially when LED rows should be updated vertically). However, since it's a USB MIDI connection, we would probably never noticed this... But I've also bad news: the controllers won't work with a direct USB connection to a STM32F4 core due to three reasons: 1) MIOS32 doesn't support USB hubs, which means that only a single device can be connected directly. Adding support for USB hubs will be a challenge, because there isn't so much information available in the internet which would directly help. Developing it from scratch would result into too much effort, and the only open sources I found so far are in the Linux driver, but even this one needs some days & try & error to get it working. 2) even more annoying: a USB MIDI connection can't be established while connecting a single Novation Launchpad Mini to a STM32F4. The communication already stalls while STM32F4 tries to get the device descriptor. 3) But not only that: this device is the first one that I've seen so far which uses isochronous transfers instead of bulk transfers for USB MIDI; transfers will only take place each mS instead of "as soon as possible". Again a poor choice - I've no clue why this should make sense, e.g. data integrity is not guaranteed with this type of transfers (-> MIDI events can get lost) However, considering these flaws I think that Novation devices shouldn't be accessed directly by a MIOS32 core, but only from a computer (Mac or (Micro-)PC). And if a computer is involved anyhow, MBSEQ doesn't need to provide the remote device protocol directly, but it could still use it's own "optimized BLM protocol", and the translation to the remote device can be done externally. Thinking a bit further I come to the conclusion, that I could simply implement the "translation" into the BLM16x16+X emulation app! This might also add some more flexibility - let's see. More updates on this topic this weekend. Best Regards, Thorsten.

It still puzzles me how this can happen. Best Regards, Thorsten.

Yes, a software solution should be easy. Providing a switch which allows to change the behaviour during runtime is a bit more difficult, because this hasn't been considered yet. But if it's acceptable to provide a runtime control only for MBNG, and only via a .NGR command, then it wouldn't be a big deal. Best Regards, Thorsten.