TK.

Ok, in this case just build a MIDIbox NG: http://www.ucapps.de/midibox_ng.html This page also links to a user manual - please read to get a better overview before asking the next questions ;) You need one MBHP_CORE_STM32F4 module and one MBHP_DINX4 module (for up to 16 rotary encoders - purchase more DIN boards of you want to connect more encoders...) This configuration file shows different kind of speed configurations: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fencspeed.ngc It works with up to 14bit resolution (just change the range and send NRPN events) Speed could also be varied by pressing a button as shown in this more complex example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fencbanks.ngc Best Regards, Thorsten.

It seems that it's currently not possible to access the octave range with the "real BLM16x16+X", it only works with the virtual BLM since it got special handling in the MBSEQ firmware. I've to work on this (since I was the only BLM16x16+X user for more than 5 years, the interface only works for functions which I use by myself ;-) Press MENU+EXIT to enable "Follow mode", so that the sequencer always shows the currently played step view. You need an unreleased version, here the prebuilt firmware: http://www.ucapps.de/mios32/midibox_seq_v4_090_pre2.zip Change to Utility->Opt->Option 13/15 "BLM16x16+X Fader Assignments" Currently it's only possible to configure MIDI events, the possibility to control internal parameters is on the TODO list, and will later be configured at the same place. Best Regards, Thorsten.

I found a solution to handle the Y position properly if the big font is used for SysEx based GLCD output Please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_034_pre1.zip Best Regards, Thorsten.

You are using the true 2.4.6, the version information passed to MacOS seems to be wrong (which is a programming error somewhere in MIOS Studio) But this is unrelated to your issue... Best Regards, Thorsten.

ok, strange Since I'm unable to reproduce the issue at my side, I can't doublecheck if the same version number is print. The log also doesn't give me hints about the location - therefore I don't know how to continue to support you on this. Did you already try different IPs and port numbers to get a better understanding under which circumstances the crash happens? Best Regards, Thorsten.

The log shows that you are using MIOS Studio 2.4.3, which has been released anno 2013. Meanwhile we've 2.4.6 So, it could be that the crash happens due to a bug which has already been solved in newer MIOS Studio versions? Best Regards, Thorsten.

Hi Mathis, this is strange indeed, and I've no plausible explanation for this issue (yet) Assumed that it's an electrical issue, it could make sense to turn off each possible source for electrical disturbance. E.g. I remember a case where I was troubleshooting sporadic spikes on the analog inputs of a MIDIbox, spent several days on this, replaced microcontroller, modified firmware, and one day it was gone, next day it was there again! To make long story short: it turned out that the cheapo PSU of my notebook generated the sporadical spikes, and this was really unexpected. Firmware behaviour: I've no explanation yet why Note On events are sent - I would expect Note Off on very short spikes which are shorter than two SRIO scan cycles, regardless of the polarity. I've to try to reproduce this to get a better understanding Best Regards, Thorsten.

Yes, MIOS32_USB_MIDI_NUM_PORTS should be set to 4, more than 4 USB MIDI ports are not properly supported. Best Regards, Thorsten.

Hi, how did you configure the tool? (Remote Host, Remote Port and Local Port number?) After a crash, the Konsole might give you (and me ;-) useful information about the reason, just enter "konsole" in spotlight to launch the tool and check the last log messages. Best Regards, Thorsten.

I remember that I added the possibility to shift the note view for lower/higher note ranges. But to be honest: I forgot the special key combination - and I always warned the requestors, that we shouldn't add too many of such combinations, because most users won't remember the keys anymore after certain time - a typical "dead feature". I handle this differently at my side: I just transpose the track to ensure that the played range is visible in the 16x16 grid. This way I'm also sure that I can still play the intended range after a reboot And I don't need to switch between different views when I change the track Best Regards, Thorsten.

Are you using the keyboard.c driver with FANTOM_XR_VARIANT switch set? The din_key_offset parameter isn't used with this switch. Best Regards, Thorsten.

No FPGA is required to scan highres encoders, this can also be done with a MIDIbox NG. It features USB MIDI which ensures fast transfer of highres (NRPN) values, I don't see the need for using the SPDIF interface for this purpose as explained at the 96khz.org page (I think that the information at this page is a bit outdated). The biggest problem is the price of such encoders (starting at ca. 40 EUR), therefore I never tried this by myself... But maybe we just misunderstood Ansolas? Typical encoders cost around 1..2 EUR, they provide 24 detents per revolution, but by using accelleration algorithms, editing higher resolution values (e.g. 14 bit NRPN) can still be handled. And this is exactly what MIDIbox NG is doing. Once you need a higher accuracy (such as 96 detents per revolution), you come into the 50 EUR range. Is this the class of encoders you are searching for? Best Regards, Thorsten.

Sauraen's project isn't a typical MIDIbox project, and this might be confusing for users like Modulator who expect a certain documentation standard, which starts with the high-level view + completion state, and and then goes down to the hardware components and firmware description. What might also be confusing: "MIDIbox FM V2" is neither the official successor of "MIDIbox FM V1", nor a uCApps project, therefore no documentation can be found at my website. It makes sense to clarify this in the first posting so that readers are aware about this before continuing reading, and don't start unnecessary discussions. Best Regards, Thorsten.

The only explanation that I have for this situation is, that the MBSEQ OUT2 -> BLM IN path isn't working, so that the BLM doesn't get pattern updates. BLM OUT->MBSEQ IN2 seems to work... Best Regards, Thorsten.

Thanks for the detailed explanation, it gave me a clear picture about the missing/inconsistent information! The waveform parameter range was wrongly documented, it goes from 0-127 (now fixed in SVN repository). Because it's a 7-bit value; each bit represents a function: | | Bit 0: Triangle | | | | Bit 1: Saw | | | | Bit 2: Pulse | | | | Bit 3: Noise (disables all other waveforms)| | | | Bit 4: Disable Voice | | | | Bit 5: Sync | | | | Bit 6: Ringmodulator | | The resulting decimal value can be calculated with a binary->decimal conversion, which is obvious for programmers (we know the numbers by heart, especially the hexadecimal representation), but they are not obvious for newbies. If you want to enter these kind of "switches" efficiently, I recommend to learn how to handle hexadecimal numbers. -> google for "binary hexadecimal", and try to find the best explanation. The bitwise handling is required, since the SID allows to activate multiple waveforms at once + some special audio paths (sync and ringmodulation). They are all controlled from a single parameter to allow concurrent changes, which results into the magic 8bit sounds (try to do the same with a common synthesizer, and you will notice that multiple CCs or SysEx command might be required, resulting into a delay between each change command -> you won't be able to switch between very different waveform shapes) The reason why you probably think that the waveform parameter behaves randomly: each parameter with such a bitwise structure shouldn't be handled with relative values (+/- x). Use absolute values instead (without +/-) to set the bits (= switches) directly independent from the previous value. Best Regards, Thorsten.

I guess that you mean something like the Arc: http://createdigitalmusic.com/2011/01/arc-a-new-design-from-monome-creator-after-grids-encoders/ Such highres encoders are unfortunately not supported by the MIDIbox platform Best Regards, Thorsten.

Always welcome! :)

Hurray, it's (almost) christmas time ! :) Note that you could already connect the BLM via a common MIDI IN/OUT connection, e.g. to IN2/OUT2 Best Regards, Thorsten.

I only love ideas which I can try out by myself ;) Best Regards, Thorsten.

Hi, the clarification of this issue is still on my TODO list. Probably it's related to the way how the Y position is placed at the second line. For big fonts a special case has to be considered, this can only be changed in the firmware, and therefore I guess that I'm the only one who can help here... Best Regards, Thorsten.

Hallo, E131 steht fuer ein ungueltiges Bank Format (irgendetwas stimmt nicht mit den MBSEQ_B*.V4 Files in Deiner Session), FasFS Fehler D9 steht fuer "invalid object" (irgendetwas stimmt mit dem Filesystem nicht) Schau mal, ob Du via "SaveAs" im Hauptmenue eine neue Session anlegen kannst. Falls das nicht funktioniert, am besten vorher die wichtigsten Files auf Festplatte kopieren, und dann mit dem "sdcard_format" Kommando die SD Karte neu formatieren, und die alten Files wieder hochladen - danach sollte eigentlich nichts mehr schief laufen. Gruss, Thorsten.

I'm very sure that I won't start with this - it's like opening pandoras box. You come with a simple request, next people will come up with even more requests, etc... and this based on an outdated microcontroller which is difficult to program and limited in memory -> not with me! However, if I would be a marketing guy, I could just handle this the same way like commercial companies E.g. like Novation: http://createdigitalmusic.com/2015/07/hack-grid-novation-releasing-launchpad-pro-firmware-open-source/ So - actually BLM16x16+X is open source as well, it's well documented (MIOS API), users can "hack the firmware" Best Regards, Thorsten.

Fine! :) Best Regards, Thorsten.

Great work!!! :) Best Regards, Thorsten.

Alright, fine! :) And thanks for the reminder, that I've to rename "std_rgbled" to "std_rgb" in the DEFAULT.NGL file when it's created. (you could edit this with the MIOS Filebrowser) Best Regards, Thorsten.