TK.

Wie zuletzt hier: http://www.midibox.org/forum/index.php/topic,12892.0.html Link zur Blacklist: http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist Gruss, Thorsten.

I moved the buttons to the navigation frame - hope that it works with all browsers (especially the google search was a bit tricky) Best Regards, Thorsten.

I added search buttons for Site/Forum/Wiki search to uCApps.de Best Regards, Thorsten.

It's more helpful to guide newbies directly to the manual page instead of linking to an article which doesn't give the concrete answer, but only confuses even more. Best Regards, Thorsten.

http://www.ucapps.de/midibox_sid_manual_fp.html Search for "Analog Control Elements" Pots: linear type, 1k ... 10k Best Regards, Thorsten.

mmj installieren -> http://www.humatic.de/htools/mmj.htm Gruss, Thorsten.

The MIOS32 based DOGM touchpanel driver Best Regards, Thorsten.

Could you please copy&paste the debug messages of the MIOS Studio upload window when you are trying to upload MIOS? /Edit: the same when you are uploading the MBSID firmware Best Regards, Thorsten.

If you are working under Windows, it definitely makes sense to try the update! The issue is, that the Windows Java version sends invalid data to MBSID once the stream length varies, and this can cause strange effects (also hangups) We found a workaround which should solve this. It also makes sense to use the latest MBSIDV2 firmware release (>= RC28) - in general, it will be very difficult to find an explanation for effects you noticed with tool/firmware versions which don't match together, or which are outdated. Best Regards, Thorsten. P.S.: this isn't the MBSID Editor thread - I moved your posting

Yes, would be nice if you could add this driver as well. "dog_spi" sounds ok MIOS: In order to select the display, just add a "USER_LCD_Select" function (with exactly this name) to the driver, it would make it compatible to clcd_multi MIOS32: the function to select a LCD device is already part of MIOS32, the LCD number is stored in mios32_lcd_device. This function is only used for CLCD drivers, as we need to address the displays separately once special characters should be initialized. GLCD drivers usually allow to combine multiple displays to a big screen without any restrictions, so that a device selection isn't required. Best Regards, Thorsten.

The display output was working immediately, there was only a minor issue in the APP_LCD_Clear() routine (6 lines cleared instead of 8 ) Best Regards, Thorsten.

Phil: the MIOS32 driver is working as well: (display + touch panel donated by Ultra :)) Best Regards, Thorsten.

It's finally possible to edit ensemble settings with the editor: http://www.midibox.org/forum/index.php/topic,11935.msg110329.html#msg110329 Means: all parameters are accessible now w/o a control surface Best Regards, Thorsten.

A new editor version v0.4 is available: Download Main changes: some parts now use the same classes like MIOS Studio to improve overall robustness of the java tools Ensemble librarian added! Ensemble editor added! Multiple selection possible (to send multiple patches at once, copy multiple at the same time, etc. NOTE: for some functions (i.e. upload a patch to the buffer) doesn't make sense. In this case the first item of the selection is taken as 'the one'). Improved SysEx handling, better Sysex-bug workaround (RC27 slave don't crash anymore). The visualisation of ensemble data will be improved later (e.g. MIDI Notes are currently displayed as a number, MIDI channel is counted from 0 instead of 1, etc...) - we thought, that releasing a version which allows to edit an ensemble is more important (especially for users who haven't built a control surface yet) than the cosmetic stuff. /Edit: complete changelog: Complete ChangeLog: play and panic buttons added in Sysex editor default startup tab in librarian is now bank A better init functions (loading from internal syx files) multiple selection functionality added (solution for 64 entry banksticks) ensemble editor added ensemble librarian added check loading midi setup (strange behavior!) oscillator link or stereo link would not update the internal patch properly retaining settings of midi configuration improved sysex handler (makes use of new sysex commands in RC19) simplified midi routing fix alot of minor bugs improved drum sequencer representation fixed sysex handler for Mac improved WaveTable representation arpeggiator patterns UD2 and DU2 missing modulation inversion buttons not working properly fixed values as modulation source not working properly LFO One shot button added LFO Key sync shortcut added Reorganized tabs LFO sine wave button not behaving properly name mistake in lead engine parameter list wrong cc's above knob assignment rate knob labels did not follow MIDI sync on/off from patch Best Regards, Thorsten.

Clever! Don't do this at home, kids! ;) Best Regards, Thorsten.

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.