TK.

You could also use two transistors instead of an OP Amp: http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Best Regards, Thorsten.

-> redirected to Adam and Rutger - I only pushed the release button! :) Best Regards, Thorsten.

A new version is available: MIOSStudio_beta8_3 Complete ChangeLog for v8: Removed references to incomplete features in MIOS Studio Added upload facility for MIOS32 platform Added MIOS debug terminal for plain text output instead of cryptic MIDI messages Fixed window dragging problem in MIOS Studio Added Cascade Windows function to MIOS Studio Merged codebases between MIOS Studio and SID V2 Editor. SID V2 Editor updated to use base MIDI classes from most recent MIOS Studio Different complete binaries are built from the same codebase: MIOSStudio (MIOS Studio standalone), SIDV2Editor (SID V2 Editor standalone), MIOSStudioSID (MIOS Studio with SID V2 Editor integrated), VirtualKeyboard (standalone MIDI keyboard and device routing) Renamed "driver" classes as listed above Fixed MIDI disconnecting issue under MacOS/mmj Added MIDI Thru port to MIOS Studio (with option to pass traffic through OUT port as previous) and Virtual Keyboard apps Fixed dialog box problems (Alt-tab) Moved MIDI Device selection and MIDI Filters to main toolbar, separate from MIDI Device Routing Created separate Windows for LCD Message and MIOS Debug Functions Added custom sliders to SID V2 Editor Fixed MIDI keyboard bug (see this post). Added PgUp, PgDown, Home and End keyboard inputs for all knobs. Added custom backgrounds to SID V2 Editor Added right-click row selection to BankTable Note: the updated MBSID V2 Editor will be released in a separate package later. Thanks to Adam and Rutger for keep working on the Java tools! :) Best Regards, Thorsten.

It's normal, the slave SIDs (Device ID >= 01) don't show a patch name, since they don't try to access a BankStick. Instead, they get their patches from the master core via CAN. So long they haven't got a patch, they will play a simple lead instrument at MIDI channel #1 No, Note control via CAN is only done in Super Poly mode. Normaly, each slave receives notes directly from the MIDI Rx input It makes sense to check the MIDI channel settings for each core in the ensemble menu (ENS->INS page) Best Regards, Thorsten.

Such a CC is already available - we call it NRPN ;) However, I implemented some useful CCs for the Lead Engine in RC28: mbsidv2_cc_chart.txt This is the Logic8 environment I used for testing: Best Regards, Thorsten.

It works like on MBSID V1 again. The "Easy Chord" feature, which was confusing you since it was an hardcoded switch in previous releases, has to be enabled in the ARP menu ("Esy" flag) Best Regards, Thorsten.

RC28 is available now ChangeLog: o fixed arpeggiator note handling bug o arpeggiator: the previously hardcoded "experimental arp behaviour" switch is now available as software controlable switch called "Easy Chord". It has to be enabled in the ARP menu ("Esy" flag) Difference compared to normal chord entry: depressed keys will still be cylced by the arpeggiator until a new key is pressed. This feature is especially useful when slow arpeggios are played, since it avoids unintended "long notes" on chord changes. It is not useful if you intend to play a voice like a common lead instrument, which should turn into a fast arpeggio when more than one key is played (in this case, ensure that the "Esy" switch is disabled) o fixed drum model handling (listen to the drum patches again - they sound much better now :) o preliminary support for parameter access via 7bit CC (only available for Lead Engine yet) [/code] Best Regards, Thorsten.

Welcome back :) Of course, it does. The Multi engine covers many usecases, and they are controlled by Mono/Poly mode, MIDI channel settings, keyboard splitzone and Voice Assignments. E.g., by assigning each instrument (6 are available) to dedicated voices and MIDI channels and/or keyboard ranges, you are able to give each oscillator an own soundset (see Manual) yes, because the Multi Engine covers the remaining usecases on a much more flexible way than known from MBSID V1 -> see "ensemble" section in the user manual I just have improved this - changes will be released with RC28 All functions are available. Only exception: ensembles But Rutger is currently working on a solution which is almost finished. I propose to read a bit more in the user manual, as all functions are explained there. It also answers your questions in more detail. Best Regards, Thorsten.

I found and fixed the bug. :) I also found an issue in drum model handling (default patches sound a bit strange) which is fixed as well. RC28 will be available soon Best Regards, Thorsten.

Hi Skunk, which computer, which operating system, which driver, which HW variant? I recently had similar issues on my Mac with one of my GM5 modules which is connected to a passive 4x1 USB hub. After some troubleshooting it turned out, that the power consumption on the hub was too high (e.g. a MBHP_CORE_STM32 module + a MBSEQ Frontpanel with backlit LCDs was connected as well). I solved this by using an active hub with dedicated power supply. The strange thing was: the MBHP_CORE_STM32 module was still working pretty stable - so it seems, that the Atmel chip is less tolerant against voltage drops, but I haven't checked this further (as I found a stable solution...) Best Regards, Thorsten.

Thanks! :) I've to upload a new version, as there was a mistake in the mix (bassline too loud) - I noticed this while listening the video on YouTube. Sorry - but hey, it's a teaser ;) /Edit: updated the link Best Regards, Thorsten.

Demonstration of an early alpha version of the upcoming MIDIbox SEQ V4. Stereo Version at Vimeo Many planned features are not available yet. However, most functions of MBSEQ V3 have already been re-implemented in C for the new MBHP_CORE_STM32 module and for an accurate PC/Mac based emulation. I also started to add new functions which were too complex for the old PIC based core. [0:00] new frontpanel designed by Wilba (but the firmware will also support the frontpanel of MBSEQ V2 and V3) [0:02] a drum track can play up to 16 instruments [0:10] patterns are stored on a SD card now, and can be loaded (and stored) w/o sequencer hickups [0:18] zoomed step view (shows 64, 128, 256 steps on a single page) [0:10] snare is triggered with the overworked (more flexible) roll function at 384ppqn resolution [0:20] new pattern selection page with pattern labels and categories [0:23] MIDIbox SID V2 in bassline mode [0:30] Roll function used on the bassline [0:38] a loopback track controls the transposer, it doesn't matter anymore at which position this track is located [0:53] Piano controlled from a track in chord mode [1:13] some randomly selected chords [1:24] simple synth line [1:45] now with MIDI echo in Force-to-Scale mode (synth is in mono mode, therefore only one sound will be played - it sounds like an arpeggio) [2:14] a second MIDIbox SID bassline is played [2:43] slowly muting the tracks [3:00] thanks for listening! :-) This track has been made in a 2 hours session on a sunday afternoon after the last blocking bugs have been fixed Best Regards, Thorsten.

available at YouTube and Vimeo in ca. 1 hour :)

1..24 was required for 96 ppqn with MBSEQ V4 we have 384 ppqn, accordingly the length is 1..96 for a single step (higher resolution) Best Regards, Thorsten.

Danke fuer den Input - etwas anderes haette ich mir auch nicht vorstellen koennen. Ich habe das Interface in die Blacklist eingetragen Gruss, Thorsten.

To give you some impressions (pictures taken from emulation, but it already works on the real HW as well): Drum Edit Page: Step View selection with zoom function (64 steps): Step View selection with zoom function (256 steps): (unfortunately, due to the LCD limitation of 8 special chars, only 15 of 16 dots (gate triggers) can be displayed per stepview) Trigger View selection: Now it's time to implement a 16x16 BLM for the emulation ;) Best Regards, Thorsten.

yes, because 2 * 16 * 64 = 2048 bytes, but only 1024 bytes (per track) are reserved for parameters (for various reasons) Just use two tracks with 8 instruments each, it doesn't make a big difference (in distance: it gives you more flexibility when defining direction/progression parameters) You won't be able to send CCs on drum tracks, since CCs are channel based, but drum instruments are note based. Thats the MIDI protocol. Instead, you would either control a sound parameter via velocity (if your drum machine allows this, e.g. it's supported by MBSID), or you would send the CCs from another track within the same pattern. You can comfortably switch between the drum and CC track with the track button - in fact, if you wouldn't know that these are different tracks, you wouldn't see a difference. Or you would use a common track with 4, 8 or 16 parameter layers, and control the drums which really require sound parameter changes from there. If you would like to send two notes, just use two trigger layers Btw.: I noticed, that a drum track is nice to play polyphonic sequences with up to 16 predefined notes (scale) on a synth as well. :) This means: "Drum" track doesn't mean, that you can only play drums and "Note" track doesn't mean, that you cannot play drums from there... Basically the track type only defines, how MIDI events are generated and edited. Best Regards, Thorsten.

Alternatively to StrydOne's vX (which is the most flexible solution of course), you could simply use the MBSIDV2 firmware, and output the modulation path values via MIDI. The easiest solution would be to write a special "AOUT" driver, which outputs MIDI instead of accessing the AOUT module. MBSID V2 has some nice integrated sequencers as well (e.g. wavetable or bassline), and beside of LFO you can realize portamento, ADDSRR envelopes, mathematical operations, Sample&Hold, etc. as well - and all this synchronized to the MIDI clock, with an already available user interface, and with an already available SysEx editor. Best Regards, Thorsten.

I simplified the layer configuration concept to a minimum of userful possibilities, because I fear that more variations will only confuse you, and disturb the workflow. My questions (please read the black code box in previous posting): - Note/Chord/CC mode: is any useful layer parameter option (like Notes/Velocity/Length/Base Note/CC/Pitch Bender/Loopback/Delay/Probability) missing? - drum mode: does anybody really see the need for more variations, e.g. 4 parameter layers with 64 steps, if only 8 drum instruments are played per track? (I think: no) Note that the actual track length can be configured separately (like before) - "number of steps" means the maximum track length, taken as constraint for segmenting the track memory Best Regards, Thorsten.

You can create so many presets as you want by storing them into a special bank, and copy over to the pattern or track you want to edit. Patterns in a bank get a category (5 characters) and name (15 characters). There are some presets (under construction), but these are soft-presets which you can easily edit by entering the characters directly in the SAVE page. Current preset names (under construction - they will be read from a .txt file later) const char preset_categories[][6] = { " ", "Synth", "Bass ", "Drums", "Break", "MBSID", "MBFM ", "Ctrl" }; const char preset_labels[][16] = { " ", "Vintage ", "Synthline ", "Bassline ", "Pads ", "Lovely Arps ", "Electr. Drums ", "Heavy Beats ", "Simple Beats ", "CC Tracks ", "Experiments ", "Live Played ", "Transposer " }; [/code] Screen of the "save" page: [code] // layout: // 00000000001111111111222222222233333333330000000000111111111122222222223333333333 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789 // <--------------------------------------><--------------------------------------> // Grp. Save Pattern to Target Category: xxxxx Label: xxxxxxxxxxxxxxx // G1 (Track 11-11)/1:A1 -> 1:A1 Char Cur Ins Clr Undo Presets SAVE Overworked screen of the pattern selection page: // layout: // 00000000001111111111222222222233333333330000000000111111111122222222223333333333 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789 // <--------------------------------------><--------------------------------------> // G1: xxxxxxxxxxxxxxx G2: xxxxxxxxxxxxxxxG3: xxxxxxxxxxxxxxx G4: xxxxxxxxxxxxxxx // >>> xxxxx 1:A1 ____ xxxxx 2:A1 ____ xxxxx 3:A1 ____ xxxxx 4:A1 ____ [/code] Example pattern selection: [code] // 00000000001111111111222222222233333333330000000000111111111122222222223333333333 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789 // <--------------------------------------><--------------------------------------> // G1: Breakbeats 2 G2: Lovely Arps 5 G3: My fav.Bassline G4: Transposer Emaj // >>> Drums 1:B2 ____ Synth 2:A5 ____ Bass 3:B1 ____ Ctrl 4:C1 ____ Best Regards, Thorsten.

No, each track can be configured to control 16 drums, means: yes, you could control 256 drums at the same time. Note that drum assignments are part of the pattern. This means: you can change the instruments by selecting a different pattern. And: a pattern consists of 4 tracks (= up to 64 drum instruments, or 16 drums + 2 basslines + 1 pad line, or ... or... or...) And: 4 patterns + a MIDI file can be played in parallel So - at the end I must say, I cannot really give you a sufficient answer for your question ;) 80 characters are reserved for each track to store labels. On common tracks, we take only 5 characters to select a "category" (e.g. Lead, Pad, Fx, ...), and 15 additional characters to name the instrument (e.g. "MIDIbox SID" or track type ("Lovely Arps"). Using more characters doesn't make much sense here, just keep in mind that we want to display it somehow on a 2*40x2 LCD together with other informations. Drum tracks will take 5 characters per instrument. This is especially useful if you select a drum layer (16*5 characters can be displayed at the upper line of the 2*40x2 screen) Btw.: here my current plans how to configure track constraints in the "Event" page. Please compare with the "Track Event Page" of MBSEQ V3 Targets: easy configuration limited to a set of parameters which really make sense to be controlled from a single track - you can always use additional tracks to send more events to the same channel/MIDI port if required. This usually results into more interesting sequences anyhow. E.g., use Track #1 to trigger 16 drums, use track #2 to change drum sounds via CCs, and run the two tracks with different lengths, step direction/progression parameters, clock dividers, etc... This quickly results into a complex pattern which will never repeat in 2..3 minutes, especially if you are changing the parameters while the sequence is playing. Use the remaining 14 tracks for other useful stuff - e.g. loopback to Track #1 and #2 to automate parameter changes ;) // layout: // 00000000001111111111222222222233333333330000000000111111111122222222223333333333 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789 // <--------------------------------------><--------------------------------------> // Trk. Type Steps/ParL/TrgL Port Chn. Layer controls Edit // G1T1 Note 256 4 8 IIC2 12 D Prob Name INIT // Trk. Type Steps/ParL/TrgL Port Chn. Layer controls Edit // G1T1 Note 256 4 8 IIC2 12 D CC #001 ModWheel Name INIT // Track Type "Note", Chord" and "CC": // Note: Parameter Layer A/B/C statically assigned to Note Number/Velocity/Length // Parameter Layer D..P can be mapped to // - additional Notes (e.g. for poly recording) // - Base note (directly forwarded to Transposer, e.g. for Force-to-Scale or Chords) // - CC (Number 000..127 assignable, GM controller name will be displayed) // - Pitch Bender // - Loopback (Number 000..127 assignable, name will be displayed) // - Delay (+/- 96 ticks @384 ppqn) // - Probability (100%..0%) // - "Roll/Flam Effect" (a selection of up to 128 different effects selectable for each step separately) // Chord: same like Note, but predefined Chords will be played // CC: Layer A/B/C play CCs (or other parameters) as well - no note number, no velocity, no length // Available Layer Constraints (Partitioning for 1024 bytes Par. memory, 2048 bits Trg. memory) // - 256 Steps with 4 Parameter Layers A-D and 8 Trigger Layers A-H // - 128 Steps with 8 Parameter Layers A-H and 8 Trigger Layers A-H // - 64 Steps with 16 Parameter Layers A-P and 8 Trigger Layers A-H // layout: // 00000000001111111111222222222233333333330000000000111111111122222222223333333333 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789 // <--------------------------------------><--------------------------------------> // Trk. Type StepsP/T Drums Port Chn. Glb LayA LayB Drum Note VelN VelA Edit // G1T1 Drum (64/2*64) 16 USB1 10 yes Prb. ---- BD C-1 100 127 Name INIT // Trk. Type StepsP/T Drums Port Chn. Glb LayA LayB Drum Note VelN VelA Edit // G1T1 Drum (2*64/256) 8 USB1 12 no Vel. Len. SD D-1 --- --- Name INIT // Track Type "Drums": // 1 or 2 parameter layers for each trigger layer (drum instrument). // If parameters layers consist of more than 1024 steps in total, steps > 1024 will be mirrored // assignable to Velocity/Gatelength/Delay/Probability/Roll/Flam only // (no CC, no Pitch Bender, no Loopback, as they don't work note-wise, but // only channel wise // just send them from a different track) // Each drum instrument provides 4 constant parameters for: // - Note Number // - MIDI Channel (1-16) - optionally, we can select a "local" channel definition for the instrument // - Velocity Normal (if not taken from Parameter Layer) // - Velocity Accented (if not taken from Parameter Layer) // Available Layer Constraints (Partitioning for 1024 bytes Par. memory, 2048 bits Trg. memory) // - 16 Parameter Layers with 64 steps and 2*16 Trigger Layers A-P with 64 steps taken for Gate and Accent // - 2*16 Parameter Layer with 32 steps and 16 Trigger Layers A-P with 128 steps taken for Gate // - 8 Parameter Layer with 128 steps and 2*8 Trigger Layers A-P with 128 steps taken for Gate and Accent // - 2*8 Parameter Layer with 64 steps and 8 Trigger Layers A-P with 256 steps taken for Gate [/code] Best Regards, Thorsten. /Edit: simplified drum mode partitionation Layer Button assignments in edit page: Trigger Layer A: select Gate, Trigger Layer B: select Accent, Trigger Layer C: select drum instrument with GP buttons (alternatively use Datawheel or Up/Down button to select instrument) /Edit2: simplified again - this is really a concept in progress

Der Bootloader meldet einen Overrun error, das deutet auf eine (hardwaremaessige) Feedback Loop hin. Vielleicht ist es auch ein Problem mit dem MIDI Interface - welches verwendest Du? Gruss, Thorsten.

Mit den PICs wirst Du diese Performance nicht hinbekommen - viele Applikationen - wie bspw. MBSID/FM/SEQ - leben von der relativ niedrigen Baudrate, und wuerden schnell in einen Buffer Overflow reinlaufen, wenn die Daten schneller uebertragen wuerden. GM5 supported nur die normale Baudrate - hier koennten u.U aehnliche Probleme auftreten, da 4 IOs ja softwaremaessig emuliert werden. Der neue STM32 Core hat bereits einen integrierten USB Port - der wird so schnell bedient, dass die Bandbreite hauptsaechlich vom Host (PC/Mac) vorgegeben wird. Ich halte den Turbo-MIDI eher fuer einen Marketing-Gag ohne Relevanz fuer die Allgemeinheit (und schon gar nicht fuer MIDIbox Projekte). Man haette auch einfach einen USB Port spendieren koennen, der hat den Vorteil, dass eine echte Datenflusskontrolle stattfindet, die mit UART basierendem MIDI nicht moeglich ist. Gruss, Thorsten.

I will check this soon. What is the setting of the HOLD and SORT flag? Best Regards, Thorsten.

You have to assign parameters to Knob functions, they can be recorded. For an alternative CC mapping, see this discussion: http://www.midibox.org/forum/index.php/topic,12774.0.html Best Regards, Thorsten.