TK.

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.

No problem, I've added this to the wishlist because I find it useful as well. Best Regards, Thorsten.

added to wishlist Best Regards, Thorsten.

Yes, I read it, and think it makes sense to change the behaviour, so that incoming CC values will also be stored in the edit buffer. Only value changes caused by ModWheel, Velocity, Aftertouch, Knobs and Wavetable shouldn't be stored. It will be an option which is enabled by default (because I guess that most people will like it), and could be disabled in setup_*.asm (for the minority who doesn't like it). In addition, I will add a "CC dump request" which will allow to synchronize a MBNG with the current patch CCs. Behaviour of SHIFT button will be configurable as well, and switched back to the original "slow" switching like in pre-42 releases. Back to topic: help to find best matching speed parameters, please! ;-) Best Regards, Thorsten.

In this case I would propose that you try the testmode in the new firmware. Help to find better matching values and give feedback about your thoughts. With good settings the value range shouldn't matter, it should always feel "good" and "usable". For encoders I don't really see an advantage if I would try to translate a relative or passthrough (resp. "snap" or "soft-takeover") mode. This wouldn't solve the problem that we actually only need better speed parameters. Best Regards, Thorsten.

You could set it to an unused port (e.g. OSC1), and only set it to USBx when you really need to configure/calibrate the MFs Best Regards, Thorsten.

Of course, it will get motormix values over USB2 since you've configured it as the "config_port". I assume, that you get the CC/Pitchbend via USB1, right? Select another "config_port" for configuration purposes which isn't used by your DAW. Best Regards, Thorsten.

@3090: you are mixing pots with rotary encoders - the modes that you are explaining are already supported by typical MIDIbox based controllers since more than 10 years; they are well known to me. But pots are not supported by MIDIbox SID. Please let's focus to improve the existing hardware! It would be helpful, if only people join the discussion who already own a MIDIbox SID, know the current behaviour, and help to evaluate various software options. Otherwise I fear that I'm more busy with explaining unnecessary details (the "what" and "why") instead of doing the actual work. :-/ Please also note that I'm not planning to develop a new hardware. @jrp: please find a prebuilt binary with the new "DEFAULT_TESTMODE_ENC_SPEED" under: http://www.ucapps.de/mios/midibox_sid_v2_044_enctest1.zip It's enabled by default (and has to be disabled to get MBSID "productive" again). All encoders are configured with the same speed mode which doesn't vary automatically depending on the value range (as they are normally doing). You can change the speed settings by pressing the SHIFT button + GP button 1 and 2 (to toggle modes and speeds) Please try to find best matching mode/speed values for following value ranges: - CutOff (12bit value range) - Resonance (8bit value range) - Depth (bidir 7bit value range) - Sustain (4bit value range) I would like to know two sets: one set of mode/speed values for "normal behaviour", and another one which should be used later to slow down the incrementer (when the SHIFT button is pressed). Best Regards, Thorsten.

I can make this optional - added to the wishlist Best Regards, Thorsten.

Added to the wishlist Best Regards, Thorsten.

->

I got some complains about the rotary encoder behavior in the MBSID firmware lately, and think that this can be changed & optimized in the firmware easily. Different variants are possible - let's try to find the best suitable solution together! Who would be interested to test some variants? Best Regards, Thorsten.

Hi, this hidden "remote control" feature exists since several years. My intention was to access "slave cores" from the UI of a "master core", this would make the design scalable. But it turned out, that the setup and handling is too cumbersome, therefore I never released this (and actually I considered to remove it from the firmware, since I don't use this feature by myself and therefore can't check if it is still working...) For which purpose do you want to send strings? And should they be displayed as a temporary, or permanent message on screen? Best Regards, Thorsten.

Der STM32F4 Bootloader unterstuetzt nur USB und kein UART basiertes MIDI, weil dafuer der reservierte 16k Speicher zu klein ist. Der Query funktioniert jedoch, und dies ist auch der einfachste Weg, um eine bidirektionale MIDI Verbindung unabhaengig von der Applikation zu testen. Wenn der Query nicht antwortet, ist etwas mit der Hardware nicht in Ordnung. Ich habe das auch gerade mal mit meinem midiSport 2x2 ausprobiert - funktioniert problemlos. Gruss, Thorsten.

Hi Tom, thanks for the hint! I've updated the MBHP_CORE_LPC17 page, it now suggests the download of version 5.2.6 Is this the version that you tried (successfully?) I'm not aware of a schaeffer version of the frontpanel. If you create one, please share it here and I will publish it at the MBSEQ V4L page. Best Regards, Thorsten.

I tested this at my side with: set router 1 IN4 all USB1 all set router 2 USB1 all OUT4 all and it works. Need more informations to understand the issue. MF: the Motormix events will be filtered automatically. Don't use the router for this, configure the MF module instead and forward/convert events via EVENT_MF like shown in the configuration examples. Best Regards, Thorsten.