TK.

Hi, this definitely won't work! The MB-6582 base board is intended for MIDIbox SID only! Please have a look into this thread where we discuss the upcoming MIDIbox NG: It will natively support USB, which answers your first question. Best Regards, Thorsten.

I've no experiences on this topic, and therefore no opinion ;) If this is the actual question: an existing PIC based MIDIbox64/64E/LC can be upgraded by replacing the core module. If it had a MF module before, it has to be replaced by MBHP_MF_NG All other components can be re-used. Best Regards, Thorsten.

Did you integrate your SID player as well? ;) Best Regards, Thorsten.

Found it, fixed it!!! :) MIDIboxSEQ V4.066 ~~~~~~~~~~~~~~~~~ o fixed potential stack overflow in LPC17 build [/code] Background: on heavy USB traffic, the USB stack consumes more stack memory than expected (because it can be interrupted by high-prio handlers) Actually this bug could happen independent from the configuration in the past... Lysander enabled some MIDI router connections, and this increased the probability of the occurrence. The bug only existed in the LPC17 build due to the special RAM layout which requires some data section allocation tweaks, with the result that the stack area is closer to the critical application data than in the STM32 build. I solved this by moving a huge block (mixer values) into a different RAM area. A firmware update is strongly recommended for all MBSEQs which are using the MBHP_CORE_LPC17, it isn't required for MBSEQs which are using the MBHP_CORE_STM32! Best Regards, Thorsten.

Hi, BLMs are very firmware specific, with BLM_SCALAR I'm trying to standardize this for controllers. A dedicated layout for MBSEQ V4 which I wouldn't recommend for controllers since it requires a special firmware handling. Only difference between this and Layout 1) and 3) is, that there are no LEDs! Recommended layout since it will be supported by MBNG Advantage: scalability is much better (therefore it's called BLM_SCALAR), also a PCB layout is more simple. Best Regards, Thorsten.

I've some good news for you: the PIC based MIOS already supports capacitive sensors, there is no need for an additional chip! :) Circuit: http://www.ucapps.de/mbhp/mbhp_din_touchsensors.pdf The MB64E firmware even has a special menu page which allows to set the touchsensor sensitivity Best Regards, Thorsten. P.S.: note that touchsensors are not supported by MIO32, since it would stall the firmware execution too much (CPU is running much faster -> more CPU cycles consumed -> worse performance)

If you donate one highres encoder to me, I could try to enhance the driver accordingly. Best Regards, Thorsten.

Yes, it will be possible to record DIN events - actually I only have to forward the generated MIDI events into the MIDI file recorder. :) Best Regards, Thorsten.

Damned, it happens again! It's really time to search for the root cause, I believe that a third-party driver like the USB or ethernet stack overwrites a memory location which is used by FreeRTOS. And again I'm not able to reproduce this. Could you please send me a PM with following files of your SD Card in a .zip package: /MBSEQ_HW.V4 /MBSEQ_GC.V4 /SESSIONS/LAST_ONE.V4 /SESSIONS/<your-active-session-directory>/* Best Regards, Thorsten.

Thank you! It's party time - see you tomorrow! :ahappy: Best Regards, Thorsten

you're welcome! For me it's nice to see, on which way functions can be re-used without much effort at my side, that I initially developed for different purposes. :) And of course it's always a nice challenge to create something which matches the needs of multiple users. Ok, I will make it optional and consider the possibility to define the MIDI events which should be sent on the different "states" of the player. This should work at your side. It's possible to send the same MIDI events to selected ports in parallel. The idea is, that then you would do the MIDI channel filtering at the receiver side (your synths) But it wouldn't be a big problem to add a channel filter at the transmitter side (MIDIO128) as well in order to save some MIDI bandwidth. Best Regards, Thorsten.

yes, I think that it will be sufficient for your purposes. Everything else can be solved in software running on your PC. I'm not a cubase user, but somebody showed me (long time ago!) that he can switch between the banks with dedicated buttons which were sending MIDI events. You should find informations about the configuration in the Cubase user manual. Best Regards, Thorsten.

For the record function I could just re-use the "MIDI file export" function of MBSEQ to directly stream incoming MIDI events into a .mid file - so: confirmed that it will be available. :) Best Regards, Thorsten.

It wouldn't be so difficult for me to add a transpose function for selectable MIDI channels. Also the Karaoke function can be realized (just a special display mode). Changing the tempo: no problem as well, since the MIDI scheduler can be clocked at any BPM rate (therefore it's also possible to synchronize the MIDI player with an external clock) And I guess that you would like to scrub through the tracks (fast forward/backward, e.g. with the rotary encoder), which is already possible as well - just not accessible ;-) Currently ALL plays the files one by one, and restarts after the last file has been played. And single plays the song only once. Yes, it would be possible to provide a separate loop function. yes... But for live usage it's important that all these functions have a dedicated button, so that you can do the changes quickly with one hand, right? Anything else? Best Regards, Thorsten.

Hi, some time ago I asked for a reasonable reduced set of parameters which should be directly controlled via CCs, but I haven't got any response - therefore this feature is still only available for the lead engine as some kind of demonstrator. However, probably users (including myself) are already happy enough with the 8 knob functions, which can be controlled with CC#1, CC#16..19, Velocity, Aftertouch and Pitchbender. The big advantage of knob assignments is: a min/max range can be defined - it's even possible to switch the "polarity", and to assign two parameters to the same knob. Means in other words: depending on the patch you could configure knobs so that they lead to the most interesting sound changes within a given value range. Knob functions are documented here: http://www.ucapps.de/midibox_sid_manual_l.html (search for "knobs menu") And assignable parameters are available for all engines: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fdoc%2Fmbsidv2_parameter_chart.txt Best Regards, Thorsten.

Hi Roger, yes, the first part could be solved with the MIDImon, but note that this is a PIC based solution. Such a MIDI monitor could also be realized with the upcoming MIOS32 based MIDIbox NG in future, see also: Part 2: let's check first if fader banks are already provided by your DAW before deciding the best HW solution. Depending on the DAW it could even be, that you only need to add some buttons to your Brain V2. They would have to send MIDI events to switch between the banks (which are maintained by the DAW). This is at least possible with Logic Audio and Cubase - are you using one of these applications? Part 3: I don't see a relationship between analog audio VU meters and MIDI. Actually you would need a comparator (e.g. LM339 based) which turns on the LED when the input has reached a certain voltage level. The input voltage has to be rectified - your audio VU meter probably already has such a rectifier which could be re-used. Best Regards, Thorsten.

Hallo Alexander, ja, das ist moeglich. Hm... mal abgesehen davon, dass dies in der Tat die bequemste Verdrahtung ist, wuerde es mich schon interessieren, woran es nun liegt. Hast Du eigentlich schonmal versucht, im "Normalmodus" (Matrix deaktiviert) mit mehreren DOUT pins LEDs anzusteuern? Ich schreibe mit Absicht mehrere LEDs, denn es geht hierbei darum, sicherzustellen, dass jede LED einzeln ansteuerbar ist, und keine ungewollte Kopplung vorliegt. Das ganze koennte man natuerlich auch mit einem Multimeter durchmessen, doch mit LEDs geht das normalerweise schneller (und ist weniger fehlertraechtig) Gruss, Thorsten.

It seems that previously the bankstick read wasn't reliable, and now it doesn't work at all. This could be related to a power problem, because while the PIC and maybe also your LCD works fine even in (unwanted) lower voltage ranges, the EEPROMs are more sensitive against this. In order to check, if this is the case, it would be interesting to know if the SID chip outputs a sound, and if the filter is working (because on too low voltages the filter just mutes the sound, or has no effect - depending on the filter mode) Best Regards, Thorsten.

Hi Luke, thanks for pointing out! It's now in the repository. Best Regards, Thorsten.

Hi again! :) I remember that in the RC38 release I made sure that all SID engines can be controlled from another MBNET master. I tested this with a STM32 and LPC17 core, but it would also be possible with a PIC based core of course - and this would be the recommended solution from my side, because the MIOS32 based MBSID has no control surface yet ;-) It's important that the second MIDIbox gets a device ID which is dividable by 4, and which is not 0. So, valid IDs are 4, 8, 12, ... And the firmware needs a small change, so that this MBNET master accesses slave 0/1/2/3 instead of "own ID"+0..3 - thats all. I will add this option to the next release, because I can easily test this with my two full-blown MBSIDs :) Btw.: in order to get a robust connection between the two devices, you should consider to use CAN transceivers at both ends! Best Regards, Thorsten.

Exactly! Initially I developed the MIDI file player for MBSEQ to play premade tracks in parallel to the step sequencer tracks. It supports mode 0 and 1 (and now even invalid formats ;-), which means that multiple tracks can be played in parallel. Timings are very accurate, because the sophisticated MIDI event scheduler of MBSEQ is used. And it inherits features like external MIDI clock synchronization, song position synchronization (e.g. with DAWs), and even a tap tempo function. It could also output lyrics... But these functions are not directly accessible, since nobody asked for this (yet). Usually I prefer to wait for such requests - in best case from 2..3 different users, so that we are able to define the best fitting user interface together. So: Which button functions would you need for this purpose? Note: at J10 we've already 6 buttons + 1 encoder, I could provide additional button inputs at J5 so that no shift register is required. Best Regards, Thorsten.

Thanks for the nice words! :) Testing this minimal WLAN->LAN adapter with integrated antenna is still on my TODO list: It's available at Reichelt for ca. 25 EUR: http://www.reichelt.de/WLAN-Adapter/HAMA-53149/3//index.html?ACTION=3&GROUPID=770&ARTICLE=116355&SHOW=1&START=0&OFFSET=500 Best Regards, Thorsten.

Finally I managed to centralize the documentation about Ethernet/OSC support in MIOS32 based MIDIbox applications here: http://www.ucapps.de/midibox_osc.html It also contains some usage examples to improve the understanding. :) Feel free to request additional examples (I don't know if anybody is really using this feature yet... although it exists since more than 3 years ;-)) Best Regards, Thorsten.

An OSC midi bridge is available here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Ftools%2Fosc_midi_proxy%2F But the Makefile is only prepared for MacOS... nobody created a Makefile for Windows yet. I'm unsure if this will solve your issues, or if it will bring up new issues (e.g. performance wise). ;-) Best Regards, Thorsten.