TK.

->

Hi, today I made an interesting observation: while testing the upcoming MIOS Filebrowser on a MBHP_CORE_STM32, I noticed sporadical hang-ups after 100..200k of transmitted data under MacOS. Once this happened, the core behaved very similar as if it would hang-up under Windows when multiple USB MIDI ports are enabled. So, finally I had a nice test scenario to investigate this issue on a *real* operating system ;) It turned out, that transfers are working very stable (no hang-up anymore) if the USB IN and OUT port are assigned to different endpoints. At the next step, I noticed that I did the same in previous PIC and Cypress based projects - and they were working under Windows without problems. Also the Ploytec guys are using separate endpoints for GM5... So, hopefully I finally found the reason, why Windows users reported problems with MIDIbox SEQ V4 and the Windows Legacy driver: probably it can't handle IN/OUT transfers over a single endpoint correctly. And this might also explain, why transfers are working with the Korg USB MIDI driver: the implementation of this driver seems to be more robust! Anyhow, now I'm searching for Windows users who would like to beta-test the changes in MIOS32. Unfortunately the different USB configuration requires not only an application, but also a bootloader update! But fortunately the risk that you could mess up your MIDIbox with this update is zero, since in the (already very unlikely) case that USB doesn't work anymore, it will still be possible to downgrade to the old bootloader by uploading it via MIDI IN1/OUT1! :) How to update: upload the MIOS32 Bootloader V1.009 UPDATE: link removed, Bootloader V1.010 is now available under http://www.ucapps.de/mios32_download.html wait some seconds until the bootloader has been installed close MIOS Studio power-cycle your MIDIbox open MIOS Studio: the USB port should be found upload the MIDIbox SEQ V4.067 application: UPDATE: link removed, the MBSEQ update is now available under http://www.ucapps.de/mios32_download.html -> done! IMPORTANT: don't upload v4.067 before updating the bootloader, otherwise the next updates via USB won't work anymore! Please let me know if this update solves the issues at your side. If it helps, I could provide all MIOS32 applications with multiple MIDI ports enabled in future, which is a good replacement for multiclient capabilities. :) Best Regards, Thorsten.

Hi, a bank would switch to another setup with different values. The current values won't be stored. Probably the "switch to group" meta event is better for such a purpose, because it switches to a different range within the same bank. Best Regards, Thorsten.

Hi Gert, do I see this correctly, that the PIC application seems to crash since the LD (resp. RCLK) line isn't pulsed anymore? Are you testing UART transfers before or after this crash? Best Regards, Thorsten.

No, this won't work, because MBSEQ hasn't enough RAM to buffer incoming SysEx data for all ports (because you've to consider that multiple SysEx streams could be received concurrently over different ports) You might remember that you already touched the RAM boundary (we had this discussion in another thread), and only with some luck I found a way to free some bytes. Now you want to consume RAM for buffering SysEx streams? ;) SysEx buffers are only provided by the standard midi_router module ($MIOS32_PATH/module/midi_router), which can't be integrated into MBSEQ The forwarding can be configured (somewhere in a configuration file) The recording channel works independent from the output channel. Means: you can use the same MIDI channel for recording, while targeting different synths. Btw.: I've very interesting news on the SysEx issue under Windows... more about this in a couple of minutes in another thread (need to do some checks first ;) Best Regards, Thorsten.

Hallo Ronny, :ahappy: Ja, das ist richtig so: die erste Eingangsleitung soll der ersten Ausgangsleitung gegenueberliegen, deshalb werden die Ausgaenge am DOUT Register von MIOS8/MIOS32 gespiegelt. Ja, es gibt schon die ersten Erfolgsmeldungen :) -> Gruss, Thorsten.

SysEx is routed in seq_midi_router.c, SEQ_MIDI_ROUTER_ReceiveSysEx: ///////////////////////////////////////////////////////////////////////////// // Receives a SysEx byte from SEQ_MIDI_SYSEX_Parser (-> seq_midi_sysex.c) ///////////////////////////////////////////////////////////////////////////// s32 SEQ_MIDI_ROUTER_ReceiveSysEx(mios32_midi_port_t port, u8 midi_in) { u8 node; mios32_midi_port_t def_port = MIOS32_MIDI_DefaultPortGet(); seq_midi_router_node_t *n = &seq_midi_router_node[0]; for(node=0; node<SEQ_MIDI_ROUTER_NUM_NODES; ++node, ++n) { // SysEx, only forwarded if source and destination channel set to "All" if( n->src_chn >= 17 && n->dst_chn >= 17 && (n->src_port == port || (n->src_port == DEFAULT && port == def_port)) ) { // forward as single byte // TODO: optimize this by collecting up to 3 data words and put it into package MUTEX_MIDIOUT_TAKE; mios32_midi_package_t midi_package; midi_package.ALL = 0x00000000; midi_package.type = 0xf; // single byte midi_package.evnt0 = midi_in; MIOS32_MIDI_SendPackage(n->dst_port, midi_package); MUTEX_MIDIOUT_GIVE; } } return 0; // no error } [/code] as you can see, we expect that the Src and Dst port are set to All. Because as you've already noticed, it would be difficult to extract something like a channel or device ID from the SysEx stream due to inconsistent handling by different manufactures. I'm unsure if it really makes sense to filter SysEx if the channel is set != All, I think that it would be better to pass the data also if a dedicated channel is selected (in other words: if the node is not disabled), do you agree? While thinking a bit further: it also makes sense to check if the SysEx data has already been forwarded by a previous node - this should also be changed. Modifications are simple in this function. Best Regards, Thorsten.

Im Forum-Header gibt es einen "Donate Development" button. :) Best Regards, Thorsten.

I'm not able to reproduce this... @jjonas: could you please send me your .mid file in a zip package via PM? Btw.: I'm currently working on a new feature which will not only be useful for MIDIO128, but also for other MIOS32 applications which store files on a SD Card. -> a filebrowser which communicates with the application via MIDI! Advantages: - no need to switch to MSD mode anymore, files can be transfered on-the-fly - pretty fast communication (in the example above, a 2 MB file has been received with ca. 50 kb/s!) - a text and hex editor will be integrated as well, which means that configuration files can be directly modified in MIOS Studio :) Best Regards, Thorsten.

I will open a new thread once the beta version is released. We will see ;-) Best Regards, Thorsten.

Hallo, ich wuerde Dir empfehlen, auf die MIDIbox NG zu warten: Damit lassen sich auch Encoder, MBHP_MF_NG usw. einbinden - also genau passend zu Deinem Projekt. Die Applikation sollte bis Weihnachten fertig sein, und die Anschluss- und Konfigurationsdetails sollten bis dahin auch dokumentiert sein. Gruss, Thorsten.

Um welche Applikation geht es? MIDIbox SEQ hat ja bspw. einen DIN Clock Ausgang, mit dem man den Monotribe ebenfalls antriggern koennte (ohne einen Kanal zu verschwenden...) Der Clock laesst sich im CV Menu auf ein 16tel runtertakten, falls 24 PPQN zu schnell ist. Gruss, Thorsten.

Hi Gaël, it won't be so easy to add this to the song mode, because switching the clock mode while the sequencer is playing can result into unwanted hick-ups (e.g. it can't be synchronized by the scheduler). I would only add this if multiple people request such a feature, and if they accept that it won't work without synchronisation issues. Best Regards, Thorsten.

yes, therefore we don't have a fourth digit Best Regards, Thorsten.

It works at my side - which firmware version are you using? And did you update the firmwares of all slaves as well? (Press MENU button during startup) Best Regards, Thorsten.

Again: thanks for the valuable feedback! :) We've a new pre-release: http://www.ucapps.de/mios32/midio128_v3_011_pre3.zip With following changes: MIDIO128 V3.011pre3 ~~~~~~~~~~~~~~~~~~~ o application doesn't hang-up anymore if recording is enabled while no SD Card connected o first MIDI song already selected after boot o play modes: aside from All and Single, we've now also a "Loop" mode which repeats the selected song o a fourth clock mode has been added: "Lock". It prevents tempo changes from the MIDI file. The BPM generator is always in master mode. o the "MIDI" page has been renamed to ".MID" o if you scroll the .MID page to the right side, you will find configuration options for MIDI ports assigned to the Rec/Play/Clock IN and Clock OUT functions o all new options can now be stored/restored into/from .MIO files [/code] (hopefully) fixed. > I also noticed that you added code that when backing up in the file structure that you loop back to the last entry. Yes, sometimes I'm doing undocumented changes :) > I don't know if this is a issue or not but when I remove the SD card and then insert it again, the software doesn't seem to reset back to the first file. fixed. Now the first .mid file will be selected (also after power-on) >I noticed that when I get to recording file names that are displayed as REC10.MID or larger, that the file pointer on the right side of the display starts jumping left and right on the display since the file string being one character longer. fixed. > I am surprised at the amount of functionality that has been added to the TEMPO feature. I was expecting something simpler like always recording at a 120 BPM rate and only being able to change it when playing back a file. Tempo can now be locked with the fourth MIDI clock mode option >don't know now many people will use these different modes of AUTO, MASTER, and SLAVE but it seems like over-kill to me. From my point of view the MIDI clock synchronization features are one of the highlights! ;-) - Master mode: use it if a groove box, drum machine or even a MBSEQ V4 is connected to a MIDI Out to synchronize the .mid file with such a device - Slave mode: same, but in the opposite direction. In addition, slave mode is the preferred choice if you want to synchronize the MIDI player with a DAW running on your computer - Auto mode: automatically switches between Master and Slaves (whenever a clock is received, it switches to slave mode) - the new Lock mode: Master mode selected, Tempo only controlled from control surface implemented. OUT3 and OUT4 are currently disabled due to the reason, that somebody requested to enable all J5 pins for analog pots (AIN entries). MIDI3 would allocate J5 pins as well, so we've a conflict here. I could enable MIDI4 (at J4B), but fear that users would be confused about the non-working MIDI3. Therefore I'm still searching for a solution to make the configuration as fool-proven as possible (so that somebody doesn't run into unnecessary HW troubleshooting sessions if he isn't aware of these dependencies) Probably the most simple way would be to provide only 6 AINs, and to assign J5B.A6/7 to MIDI3 by default Cheers! The MIDI player is probably in 'All' mode, which automatically loops through all .mid files. If only one .mid file is stored on SD Card, it will play the same multiple times. Just enable Sngle Mode Great! :) (my very first MIDIbox was built into a satellite tuner, therefore I like such constructions!) Best Regards, Thorsten.

Thanks for testing! :) There is a new version: http://www.ucapps.de/mios32/midio128_v3_011_pre2.zip with following changes: MIDIO128 V3.011pre2 ~~~~~~~~~~~~~~~~~~~ o rotary encoder now selects the tempo (BPM) in main page o BPM mode can be switched between Auto/Master/Slave by pressing shift button + soft button 2 o MIDI recorder: tempo now stored in MIDI file o record event monitor: display input port name instead of output port name o record event monitor: display "DIN" instead of "Def"(ault) when DIN generated events are recorded o only in this pre2 release: whenever the next/previous file is selected, the searched files are listed in the MIOS terminal o MIDI router config: renamed SrcD to DstP [/code] I wasn't able to reproduce this. But in this pre2 release I enabled some additional debug messages for the file selection: the searched files are listed in the MIOS terminal. So: if it happens again, please show me the terminal logfile Def. stands for "Default" - actually this is a free assignable port (normaly USB1, but could also be MIDI1 or MIDI2)... This feature isn't configurable in MIDIO128, but I could enable it in future. One of the usecases: if you've two MIDI synths connected to OUT1 and OUT2, and only one of them should receive MIDI events from multiple INs, you could assign the default port to this OUT and change the default port assignment at a single place in order to select the synth. The router configuration doesn't need to be changed in this case. No the REC/PLAY port and channel selection won't be available in the MIDI router page, as this feature is based on a "plugin" which doesn't allow extensions. Instead, I will add a new configuration page to the MIDI menu. All other issues fixed (see changelog) - even the minor ones (I'm always interested on unexpected or confusing names) Best Regards, Thorsten.

Ich haette nicht gedacht, dass Windows dieses Leerzeichen nicht einfach ignoriert (so wie unter Unix...) Die MIDIO128 App hat uebrigens gerade einen Update erhalten -> es macht Sinn, das gesamte (!) Repository taeglich mit dem Server zu synchronisieren! :) Gruss, Thorsten.

Hallo Roman, wir mussten dieses Feature leider deaktivieren. Ich habe allerdings noch nicht herausgefunden, wie man den "Download" link entfernt. Der Download ueber Tortoise ist aber sowieso praktischer, da man hiermit das lokale Repository inkrementell updaten kann. Gruss, Thorsten.

It won't be possible to add a sampler engine... ;) Best Regards, Thorsten.

Hi Antix, yes, that's correct. The PIC based MBCV V1 doesn't provide modulation sources for the CV outputs Best Regards, Thorsten.

The encoder wheel of a mouse can already be scanned fast enough (the scan rate is 1 mS) You only need to add a schmitt trigger after the encoder outputs to ensure proper digital signals Best Regards, Thorsten.

Yes, you will need: 1 MBHP_CORE_LPC17 1 MBHP_AINSER64 (for the faders and mod/pitchwheel) 1 MBHP_DIO_MATRIX (to scan the keyboard matrix - includes two DINs and two DOUTs, although only two DINs/ 1 DOUT is used) - see also http://www.ucapps.de/midibox_kb.html for details. This firmware will be part of MBNG in future. 3 MBHP_DINX4 (77 digi IN's) 1 SD Card For the encoders, you could consider to buy this nice PCB which supports LED rings as well, and which comes with the required DIN shift registers: Advantage: this saves one DIN module at your side, and encoders can be soldered directly on the board which improves robustness. Best Regards, Thorsten.

we are looping to MBSEQ V4 where something like this could be added ;-) Today I implemented the MIDI recorder part - it's up & running! :) For those who want to beta-test: upload this preliminary firmware to your core http://www.ucapps.de/mios32/midio128_v3_011_pre1.zip From the ChangeLog: MIDIO128 V3.011 (pre1) ~~~~~~~~~~~~~~~ o It's now possible to record MIDI files! Press EXIT + first softbutton (under REC) o Fast Forward and Fast Rewind are now available by pressing EXIT [/code] It's currently not possible to set the tempo, we are always recording at 120 BPM in master mode, and at the incoming tempo in slave/auto mode. Best Regards, Thorsten.

Just to clarify: together with Al (aka. kogz23) I'm working in this one which will be PIC based: http://www.ucapps.de/tmp/mbdr_proto1.jpg Actually a slightly enhanced MB808 firmware with support for velocity. Al will run a batch order for PCB and frontpanel soon. Jef (aka. pcbatterij) works on this one: http://midibox.org/forums/uploads/gallery_8996_152_12242.jpg It's a modified MBSEQV4, he works independent from me on the firmware changes. Best Regards, Thorsten.