TK.

You are totally right, therefore I'm starting with a "virtual control surface" this time (in distance to MBSID V2 design where a HW based control surface was already available), which forces me to keep the parameter handling simple! All parameters can be controlled via NRPN messages now. Bidirectional communication is supported as well - means: by sending a special NRPN message, all parameters will be dumped out. This works fine with Lemur, and I'm sure that it will also work with ctrlr, Max4Live, etc... all those modern PC based controllers which allow perfect DAW integration :) Yes, I agree that this is a nice thought directed to maniac! The jacks of my semimodular synth are working on a similar way - this simplifies patching. Current state: - bidirectional communication with Lemur working -> means: Lemur can display and control the current patch from MBCV! :) - access via MIDI (NRPN events) and Ethernet (OSC messages) supported - synth engine still working with no performance loss! :shifty: - my Kraftzwerk outputs very interesting sounds! A snapshot of my workbench (reduced cable set!) A scope is very helpful for debugging - and depending on modulation settings it shows very nice animated pictures (not part of this photo)! :ahappy: Next steps: - implementing the multistage envelope - taking over modulation matrix from MBSID V3 code - creating some sound samples Best Regards, Thorsten.

This was my first idea as well. Are you using a PIC18F4685, and did you upload the right MIOS version? -> mios_v1_9g/pic18f4685/midi/mios_v1_9g_pic18f4685.hex Best Regards, Thorsten.

Nice work! But please consider that we've already an alternative layout created by SmashTV: http://www.midibox-shop.com/mbhp_SIDR3a.html Therefore we haven't spent much effort to improve the single layer layout. However, if you want to ensure that your layout ideas won't get lost, please add a link to the files in the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=layout_improvements Best Regards, Thorsten.

Of course, the LPC17 core has enough resources to handle this! :) Due to the USB MIDI port it especially provides the required bandwidth (more than 100 times faster) to transfer so many MIDI events concurrently. Schematic: see the MIDIO128 page, keyword "Scan Matrices" The push buttons should be connected as matrices as well to avoid unnecessary cabling and to reduce the number of DIN modules. Yes and no. It was limited to the internal AIN ports, but there is a new solution: the which will be available in future. Multiple MBHP_AINSER64 modules can be cascaded, also the wiring will be much easier since the modules are connected via a single ribbon cable to the core. Btw.: I'm still searching for people who are interested to join the prototype order for this PCB. The prototypes will be a bit more expensive than later in SmashTVs shop (I guess ca. 10 EUR per PCB), but you would help me to finance this (sparetime) development. Best Regards, Thorsten.

Hi, This message means, that your MIDI file contains a huge meta data block which is larger than the available RAM. It could be a SysEx block for example. Too large blocks will be ignored, and the message will be output as a warning. Best Regards, Thorsten.

This topic (MIDIbox CV V2 concept) is now continued here:

Yes, triggers will be routable to DOUT pins (up to 128 trigger/gate pins at 5V level available!) It will also be possible to route internal events to DOUTs, such as LFO overruns, ENV stage transitions, mathematical operations from the MOD matrix (such as Src1 >= Src2), Predivided Clocks, etc... :) Best Regards, Thorsten.

Update: the initial value can be set in the first step, and the delay is relevant on a release->attack transition. But of course, it could be set to 0 mS if you want. Of course, MIDI Clock sync is already implemented. :) Great input! -> SpeedFactor Seems that I should take over the Trigger Matrix of MBSID as well! ;) Here the first "mockups" - not for the physical control surface, but for a SW based editor :) Next step is to establish the communication between Lemur and MBCV, so that I'm able to test the parameters. Note that the modulation matrix will allow to pass a value of a certain channel to other channels. This means for example: LFOx of channel A can modulate channel B (and C!) regardless what kind of electrical signal they are controlling! Best Regards, Thorsten.

Alright! Now were we've more concrete ideas, I will start with the Lemur interface :) It will help to quickly find a suitable parameter set. E.g. I think that it makes sense to provide default modulation routing paths for LFO/ENV (like I've already implemented - advantage: quick access) + additional matrix paths where two sources can be combined with a mathematical operation and routed to up to two destinations (like known from MBSID) Best Regards, Thorsten.

Thanks for the inspirations! Tap Tempo can be re-used from MBSEQ V4, manual envelope trigger is a low hanging fruit (but definitely useful! -> it's like the "Play" button in MBSID) Yes, an envelope follower would require additional hardware, it's a different topic. But the possibility to route analog input signals into the modulation matrix is on the agenda :) No, it's very simple to realize... I must also say that I started MBCV with a 7 stage envelope, but switched back to traditional ADSR after I realized, that I very rarely use the additional stages, but get more interesting effects by selecting different curves. Therefore I would like to go this way -> it's more practicable and it will result into a simpler user interface. E.g. all relevant values (A D S R) are visible on the same LCD page! On the other hand I think that a multi-stage envelope could be helpful for pad sounds. It could be implemented in addition to the ENV (means: as a second ENV) and it could work table based. Each step would define the target level and the time in mS which should pass for the sweep to the target level. Such as: 1: 100% 1000 mS 2: 75% 200 mS 3: 50% 500 mS 4: 25% 1000 mS 5: 0% 1000 mS What do you think about this approach? Definitely there will be different output curves (e.g. a one which emulates the behavior of a RC network). Of course, some tables could be added as well, they could be loaded from SD Card! :) no, this will be too complicated to control from a user surface which is mainly intended for synth parameters. And I would like to use the available resources (memory, CPU load) for synth features instead of sequencing features -> therefore the sequencer/arpeggiator and note processing capabilities will be simple. Already implemented, and the bassline sequencer will allow to control it as well (like known from MBSID) of course! Poly mode is implemented as well, it just uses the note stack of the first channel to control the remaining channels which are set to "poly mode" as well. Best Regards, Thorsten.

yes, that's exactly the way how it works. Just assign the same MIDI channel. I think that especially the FM capabilities are very nice when working with a filter. Sooner or later I will post some samples to show what I mean :) A 303 like programming interface could be interesting. Not so much for the filter project, but more for people who want to turn their analog synth into a bassline with accent and especially a glide function :) Best Regards, Thorsten.

(continued from ) It's funny that you ask for this today, because currently I'm planning the "full featured" control surface of the upcoming MIDIbox CV V2 application. In distance to MBCV V1 it uses the MBSID sound engine, optimized for the needs for a CV controller. It features two LFOs, ENV, ARP... per channel! And with a much higher update rate than MBSID V2 (I think that up to 5 kHz can be achieved when all modulators are running in parallel, by disabling modulators even higher frequencies are possible) -> even FM modulation is possible by using two LFOs in "fast" mode /edit: meanwhile the feature list has been enhanced by a second multi-stage ENV2, a modulation and a trigger matrix! The sequencers (bassline/wavetable) will be integrated later, so: they will be available as well of course! Here the current list of parameters: /edit: removed, since it's obsolete! I'm still a bit uncertain how to continue this project, because I think that without a good control surface it won't be usable in practice. The SCS (Standard Control Surface) (2x20 LCD + 4 menu buttons + SHIFT button + encoder) gives access to all parameters, but the usage is too cumbersome. Therefore I thought that I should start with a "virtual control surface" by using Lemur, and once I'm happy with it, I can translate it into hardware. ;) Any additional ideas? E.g. how would your "dream interface" for this project look like? Best Regards, Thorsten. /edit: meanwhile we've a demo video! :-)

it was time to continue the long term sequel with some newer MIDIbox devices. :) Background a cappella from El Hadj Hamado Kanazoe (-> see http://www.awesometapes.com ) inspired from this german magazine article. Best Regards, Thorsten.

TouchOSC isn't flexible enough for a BLM. The grid doesn't allow multi colour, and each "led" has to be accessed with a single OSC packet, which would slow down the system performance of MBSEQ dramatically -> makes it unusable. With Lemur it's possible to decode incoming MIDI/OSC messages with scripts, and this makes the application much more powerful than TouchOSC, and finally made the BLM emulation feasible. E.g. the whole 16x16 grid can be updated with a single OSC packet, and I'm able to define if LEDs should be accessed in vertical or horizontal direction (which helps to improve performance as well). For TouchOSC we would need to send 256 individual packets! Accordingly, only an application like Lemur can be used for such purposes, or a selfwritten application of course. Since I don't own an Android device, I can't help here... Best Regards, Thorsten.

This is a typical MIDI issue caused by the limited bandwidth. In order to estimate, if an optional filter makes sense, I would like to know if the issue also happens if the MIDI forwarding function is disabled (-> press the "In->Out" button), and your Dx7 is working in "Local On" mode. Best Regards, Thorsten.

Got the PCBs (and some other goodies) today! Happy new year! :) Best Regards, Thorsten.

I uploaded v1_002 of the lemur patch (link: see first posting). It now supports direct communication via Ethernet (OSC), so that no computer is required to pass MIDI events to the iPad! (MBSEQ V4.055 resp. V4L.055 upwards required). With this version, MBSEQ Lite is supported as well: Sequences can be directly entered in Grid or 303 mode. Patterns can be selected in a grid as well (like known from Ableton Live). The keyboard mode allows to play a synth directly, but can also be used for recording! Setup procedure (commands can be entered in MIOS Terminal): (assumed that iPad IP address is 192.168.1.110): - set osc_remote 3 192.168.1.110 - set osc_local_port 3 8000 - set osc_remote_port 3 8000 - set osc_mode 3 1 - set blm_port OSC3 - store In Lemur, set the IP address of your MIDIbox with port 8000 -> done! :) Best Regards, Thorsten.

V4L.055 is now available for download: MIDIboxSEQ V4L.055 ~~~~~~~~~~~~~~~~~~ o LPC17 build: optimized MIDI IN handling o LPC17 build: MIDI clock can now be received over MIDI IN1..4 o SysEx forwarding via MIDI router working (again) o MIDI router supports 16 nodes now! (previously only 8) o added new MIOS terminal commands: - display network informations, modify network and OSC settings - display MIDI router informations, modify MIDI router settings - change BLM port remotely - "store" and "restore" the session remotely o it's now possible to set the loop point of a track: press&hold the LENGTH button, thereafter select the loop point with a GP button. o BLM now supports Lemur on iPad Example configuration (we assume that iPad IP address is 192.168.1.110): - set osc_remote 3 192.168.1.110 - set osc_local_port 3 8000 - set osc_remote_port 3 8000 - set osc_mode 3 1 - set blm_port OSC3 - store These commands can be entered in MIOS terminal On your iPad, set the IP address of your MIDIbox with port 8000 o BLM now allows to record MIDI notes in the keyboard page [/code] More informations on the Lemur based BLM can be found under: It's a great enhancement for MBSEQV4L :) Best Regards, Thorsten.

V4.055 is available for download: MIDIboxSEQ V4.055 ~~~~~~~~~~~~~~~~~ o LPC17 build: optimized MIDI IN handling o LPC17 build: MIDI clock can now be received over MIDI IN1..4 o SysEx forwarding via MIDI router working (again) o MIDI router supports 16 nodes now! (previously only 8) o fixed bug in PitchBender Editing mode o added new MIOS terminal commands: - display network informations, modify network and OSC settings - display MIDI router informations, modify MIDI router settings - change BLM port remotely - "store" and "restore" the session remotely o BLM now supports Lemur on iPad Example configuration (we assume that iPad IP address is 192.168.1.110): - set osc_remote 3 192.168.1.110 - set osc_local_port 3 8000 - set osc_remote_port 3 8000 - set osc_mode 3 1 - set blm_port OSC3 - store (the commands can be entered in MIOS terminal). On your iPad, set the IP address of your MIDIbox with port 8000 o BLM now allows to record MIDI notes in the keyboard page [/code] Have fun! :) Best Regards, Thorsten.

Once Lemur has been ported to Android (I'm sure that they will do this sooner or later), the template will run on this platform as well! :) Best Regards, Thorsten.

Well, you are hitting the RAM limitations again - the MBSEQV4 firmware allocates almost the complete 64k range, if you want to stay compatible with future extensions, you have to search for other ways. I should also prewarn you that changing such a global setting would result into a lot of adaption work in all the seq_ui_*.c files! In general you've two possibilities: 1) branch the user interface like I did in midibox_seq_v4_lite - this allows you to create a dedicated UI from scratch. This will probably the most simple solution as everything is under your control. When you look into midibox_seq_v4_lite/core, you will notice that the number of files is very reduced in this variant -> better oversight. 2) alternatively, re-use the existing UI and just change the display position of the second LCD device in seq_lcd.c, SEQ_LCD_Update() function You would also have to find a way to adapt SEQ_LCD_InitSpecialChars() for graphical LCDs - I don't have an automated solution for this yet... it's something what you would have to develop by yourself. This approach is pragmatic, but the display output will look ugly in comparison to a fully customized adaption. If you are asking me: creating a new UI from scratch (solution 1) is the best way to utilize this GLCD, because the original user interface hasn't been created for this. Since you are using different buttons/encoders as well, sooner or later you would have to do a lot of changes in different files anyhow, with the disadvantage that you won't get the changes that I'm doing in future. Best Regards, Thorsten.

Today I got my first experiences with Lemur for iPad and I must say that this software is really a master piece! :) In distance to TouchOSC the controllers are fully programmable with an easy to learn script language. And in distance to OSC it's also possible to work with MIDI at low-level -> means: at bit basis (e.g. a MBSID Editor is feasible)! :) Within a couple of hours I was able to implement a complete BLM16x16+X emulation: The user interface feels much better than the Juce implementation, and due to the easy to use Lemur Editor it's possible for everybody to customize the user interface! :) So, if you own an iPad, and already bought Lemur, just install this template: http://www.ucapps.de/midibox_blm/MIDIbox_BLM16x16+X_v1_002.zip Thereafter start the Lemur Daemon for a MIDI<->OSC connection, and on MBSEQV4 configure the BLM port (MIDI->Misc page) E.g. to USB3 like I did... This MIDI port can be select in Lemur as well: Now you are ready for having some Multitouch BLM fun! :) Best Regards, Thorsten.

I checked the DOGM128 driver on the LPC17 based core, and it works (basically) - there was a bug which caused that only the left half of the display was written, but the initialization was already working correctly. Here the schematic: http://www.ucapps.de/mbhp/mbhp_lcd_dogm128_mios32.pdf And here the picture which you should see with the apps/mios32_test/app_lcd/dog_g application: Best Regards, Thorsten.

I checked the DOGM128 driver on the LPC17 based core, and it works (basically) - there was a bug which caused that only the left half of the display was written, but the initialization was already working correctly. Here the schematic: http://www.ucapps.de/mbhp/mbhp_lcd_dogm128_mios32.pdf And here the picture which you should see with the apps/mios32_test/app_lcd/dog_g application: Best Regards, Thorsten.

What is the output of: gpasm --version" [/code] I'm using: [code] gpasm-0.13.7 beta Best Regards, Thorsten.