TK.

Hi, yes, higher temperatures can cause such effects. Do you have a datasheet of your LCD? What is the specified temperature range? Is your MIDIbox built into a closed plastic case without "ventilation slots"? Maybe it makes also sense to measure the voltage at J2 when this happens. If it is much below 5V (I mean, 4.8V or less) due to increased heat, such random effects could happen as well. In this case, a heatsink for the 7805 could help - or if your MIDIbox is built into a metal case: just screw the 7805 on the bottom or sidepanel of your case. Best Regards, Thorsten.

ALBS is located in germany - it could make sense that somebody in Europe is doing the group order for ALBS knobs to save shipping costs and tax fees. ...how about a new "group order" board? ;-) Best Regards, Thorsten.

yes, it also works with other engines, just only the hold function is missing (yet) The same mechanism will be provided by the drum engine. Btw.: thanks to the ensemble it is possible to control all SIDs from the same MIDI channel, and to define split points in order to select sequences from different keyboard zones, or to layer them (e.g. selecting a bassline and drum sequence with a single key) You can also use the modulation matrix of MBSID, it selects and displays sequences in bassline/drum mode. :) However, something "Monome" like works also fine, but note that there is no feedback for LEDs, to display which sequence is currently selected. Best Regards, Thorsten.

Tables can be added anywhere. You don't need to specify a specific start address. Only exception are tables in setup_*.asm, but I guess that there is not enough free memory anymore between 3080 and 3300 Just include the file which contains the table at the end of main.inc, before "seq_presets.inc" is included 2: yes, it's a mistake in the .pdf file Best Regards, Thorsten.

Here a short impression - this demo is played with a single core and two SIDs. It basically consists of two sequences, which have been copied&pasted 4 times and slightly modified within the SEQ editor: There are different modes to play a bassline... In this demo I used a mode which allows to select sequences with a MIDI keyboard, so that I was able to switch back and forth between different parts with one hand, while tweaking sound parameters with the other hand. http://www.ucapps.de/mp3/midibox_sid/mbsidv2_bassline_demo1.mp3 Btw.: all 8 sequences are allocated, and I don't use the parameter track... Best Regards, Thorsten.

Of course, like the Lead and Multi engine, also the Bassline (and Drum) engine will get some randomize functions - it is possible to generate a completely random patch, or to randomize specific sections (e.g. only OSC settings, only Env, only LFO, only notes, only accent, only slide, etc...) from a special menu page --- so long, until it sounds cool. Again ;) Of course. There is a special edit screen (which differs from the normal WT editor for most ergonomic note entry). And you can add analog pots in order to control the typical 303 parameters. You can also control them from the Knobs layer with rotary encoders, or from a special menu page if you don't want to use the minimal control surface only. And in far future there will also be a Control Extension (breakout box) as described in the wishlist. But note that this extension is a low priority feature for me - first I want to see the complete firmware before deciting the final layout of this extension. It should fit perfectly for all engines, not only for basslines Best Regards, Thorsten.

I don't want to say that this isn't a nice idea, and I also don't want to say that it wouldn't be easy to add such a feature - but I'm sure that I won't have the time for a firmware update in the next months. However, I've started a list of feature requests here: http://www.midibox.org/dokuwiki/doku.php?id=midibox_cv Just add your ideas No guarantee that I will implement this - but if something else wants to contribute, just step forward - it's open source and one of the easier understandable applications! Best Regards, Thorsten.

Yes, it's actually the row index. The name seems to be an artefact from another code. However, it's important that the counter variable is located at a different address than SEQ_BLM_ROW_CTR, since ROW_CTR is incremented from an interrupt routine, and COL_CTR (which should mabye be renamed to ROW_CTR2) is incremented from the main thread (conflicts have to be avoided) Best Regards, Thorsten.

Hi Rutger, 6 voice polyphony is handled internally by each core seperately for multi engine patches. You are talking about some kind of global polyphonic mode (I call it "super-poly"), in which one core manages the voices of all SIDs connected to master and slaves. This mode has been requested multiple times, and I'm sure that I will implement it sooner or later. But it won't be part of the first MBSID V2.0 release, as I have to do some evaluations first (and for these evaluations I need a complete firmware). I especially have to check, if under full load ECAN messages can be broadcasted to all slaves without handshaking - this is a requirement for fast access to oscillator voices. If this doesn't work stable enough, super poly will propably add a latency of 1..2 mS I think that this currently isn't a big impact on your configuration. You are already able to do a lot of great things with 8 moog filters connected to the audio output of each SID. Just only the availability for a poly mode with seperated filter handling will be available later (maybe end of this year) Best Regards, Thorsten.

Rio: I've connected the SID audio output to both channels (A and B) Best Regards, Thorsten.

Thanks a lot for your votes! Seems that the '8 sequences per patch w/ note and parameter track (16 steps)' is the most prefered option. :) A general comment to this topic: MBSID V2 has grown up to an extremely complex application. Meanwhile we have 40000 lines of assembly code. The way how the application is programmed allows me to add certain features very easily without much programming effort. But there are also functions, which might sound primitive, but which could take me several hours or days for implementing it into MBSID V2. In addition, the integration of such functions could also affect the system stability and/or the memory consumption in a negative way, so that other - more useful functions - cannot be added anymore. For example the possibility to vary the sequencer paritioning: it's absolutely no problem to add this to the sound engine, mostly it would only mean that I have to add two or three additional lines of assembly code. If only hackers like me would have fun with MBSID V2, it wouldn't be a big issue for them to edit the sequence directly with an hex editor - this would open a lot of additional powerfull possibilities btw. But most of the users are not hackers. (some people even have problems to change the LCD display size from 2x20 to 2x16 ;-) They prefer a comfortable and especially a consistent user interface. The user interface of MBSID V2 is optimized for low memory consumption. Many references and parameters are compressed in tables. One of such a parameter is the maximum value of a menu item. This one is static - and thats the point. So, we have only a static maximum value for number of sequences and/or steps. And we only have a static number of menu items which can be displayed in a page. If I would change the menu handling, so that these constants can be varied, most tables would grow up, which would limit the possibility to add other memory intensive features in future. Best Regards, Thorsten. P.S.: don't panic, only 66% of flash is allocated yet, and most stuff for the final release is already implemented! So, using the PIC18F4685 is future proven :)

yes, this is correct. But switching between patches stalls the engine for ca. 250 mS, which is not preferable, therefore my assumption is, that providing as much sequences as possible into a single patch would be better. It isn't an easy decition, therefore I'm asking here (thanks for the fast feedback btw!) So, a completely user definable partitioning. Thats possible but the configuration will be complicated :-/ Yes, using a MBSEQ is still the most preferable option :) With a lead patch, 4 tracks per step can be processed, so it would be a good alternative solution, but entering sequences is much more time consuming than the current implementation of the "simple" bassline sequence editor (it still fits in a single 2x20 screen) Best Regards, Thorsten.

I've nearly finished the bassline engine and would like to know from the users, which sequencer partitioning they would prefer. Each patch has an reserved area of 256 bytes for sequences. Two basslines (left/right SID) will be available, each can play one of x (x=16 or 8 - your choice) sequences of the patch, and you can switch back and forth (measure synchronized or not...) between the sequences, e.g. from a MIDI keyboard by playing another note, or from the control surface. I'm unsure about the best partitioning of this 256 byte area, therefore would like to know your oppinion. 256 bytes could be divided into 16 * 16step note tracks. Each step of a note track would contain the note itself (C/C#/D/D#...B/C+), the octave (normal, up, down), accent and slide flag So, like a normal TB303 - this is the first option of this poll Or I could provide 32 step tracks, but in this case only 8 sequences would be available per patch. (second option) Maybe an A/B option (chaining) would be better? Or I could provide a second parameter track which could control an assignable sound parameter (e.g. cutoff or depth). But this would reduce the number of sequences per patch to 8 (third option) Of course, I could also make the partitioning configurable. But this increases programming effort, makes the usage more complicated and could just lead to the typical "featureitis" (people requesting features which they never use) So - which implementation would be your choice? - please use the poll form above and don't hesitate to make alternative proposals Best Regards, Thorsten.

I will try SwinSID and give feedback how it works with MBSID Btw.: ATMega 8515 is available for ca. 2 EUR at Reichelt, + the other parts makes ca. 3..4 EUR in total I will canibalize the DAC from an old soundcard (TDA1387 seems to be compatible) So, it's indeed an interesting experiment which doesn't cost much money :) Best Regards, Thorsten.

Ein Moog VCF zieht immer, zumindest erhaelt man mit diesem Keyword eine Menge Google Hits - so kommen die anderen Schaltungen besser zur Geltung ;-) Was ich insbesondere fuer eine deutsche SDIY Seite interessant faende, waere eine Auflistung von Bezugsquellen in Deutschland/Oesterreich/Schweiz. @Sonicwarrior: Du hast da glaube ich einen sehr guten Ueberblick (ich erinnere mich an den einen oder anderen guten Tip) - mit einer Uebersicht wuerdest Du selbst fortgeschrittene Bastler gluecklich machen. Auch Literaturtips waeren interessant, evtl. mit Rezension - doch da hier sicherlich auch andere Leute einen Beitrag liefern wuerden, waere ein Wiki vom Verwaltungsaufwand her praktischer. Gruss, Thorsten.

In this demo I controlled cutoff and resonance of two CEM3378 with two AOUT_LC modules from a single core: http://www.ucapps.de/mp3/midibox_sid/mbsidv2_cv_out.mp3 So, apparently it works? Best Regards, Thorsten.

So far I remember, you only need to enable some kind of feedback flag in Cubase, so that an incoming button event will be sent back to MB64E in order to control the LED? This is the perfect solution anyhow, because the LEDs will always be in sync with the sequencer (especially important when you load a new song) I'm a Logic user, so I cannot help you how to configure Cubase correctly Best Regards, Thorsten.

The SID has freerunning oscillators, which means, that phases are not in sync so long you don't reset them. The phases can be synchronized manually by setting Phase=1, and they are synchronized automatically while changing a patch. In addition there could be of course small sound differences, especially for filtered sounds. They especially happen when you are using different SID revisions - and yes, it could also depend on the filter caps. For real mono, it's better to use a single audio channel and pan it to the middle The mono flag was intended for people who don't own a second SID... Best Regards, Thorsten.

V2A -> see http://www.ucapps.de/midibox_sid_manual_e.html In addition, from the mod matrix, you can route any mod path to any CV out. Btw.: is there anybody beside of Wilba who already uses the MBSID V2 and can provide really useful suggestions? I've the impression, that either the firmware has so many bugs, that you've uploaded v1 again, or that the usage is so complicated, that nobody really likes it. Best Regards, Thorsten.

I just had a quick look into the README.txt file, it seems that TK left a note to the users which might be important to know - but I don't understand what he is saying... could somebody please translate? Some precompiled setups are part of this package: o setup_6581.hex (MBSID stuffed with 6581) o setup_8580.hex (MBSID stuffed with 8580) o setup_tk.hex (TK's Setup) o setup_wilba.hex (Wilba's Setup) The required application upload procedure is described under http://www.ucapps.de/mios_bootstrap_newbies.html Infos for customization: o note that a main.asm file doesn't exist, instead, main.inc is included from the setup_*.asm files. main.inc doesn't need to be touched! o do your setup in setup_8580.asm or setup_6581.asm MIDIbox SID slaves will be detected automatically depending on the MIOS device ID The setup_tk.asm file is intented for TK's own setup and partly requires special hardware The http://www.ucapps.de/howto_tools_mpasm.html page describes, how to build a new .hex file [/code]

Some time ago I wrote down the schematic I used on a paper, but it's lost. So, no chance to reconstruct this without opening the Behringer case... But basically the circuit was very simple: two outputs of AOUT_LC control CutOff and resonance. I added two trimpots against ground for an additional gain fineadjust. This was especially important for calibration of the four CEM3378 to ensure, that the same software driven cutoff/resonance value will result into the same effect at the analog side. MBSID supports software calibration (see ENV menu), but it's easier and more exact to do this with a pot, as a software calibration results into a reduced resolution! It doesn't matter to which CV outputs CutOff and Resonance are connected, as this can be configured in the setup_*.asm file of MBSID V2 anyhow, just read the comments. You could even control the outputs without the F2A (Filter-to-analog) option within the ensemble in order to address the filters seperately, and by doing so, you wouldn't need to do any change in the firmware - just select the right CV target in the modulation matrix and have fun. This as background information, and to answer your questions: 1: I used a TL074 2: these are the audio inputs. The CV outputs are marked with "C.V. Frequency" and "C.V. Resonance" in the CEM3378 schematic 3: is it clear to you, what CV (control voltage) means? 4: how many CV inputs are you planning to control individually? The calculation is easy: each AOUT_LC module provides two CV outputs, with 2 modules you get 4 outputs. For an stereo effect it makes sense to control at least the cutoff parameter of two CEM3378 seperately, and maybe also the resonance or the VCA. But note, that the AOUT_LC module is used in 12/4 mode, which means; each first CV channel is working at 12bit resolution, each second at 4bit resolution. Therefore in my own setup, I control CutOff with each first, and Resonance (where resolution doesn't matter) with each second output. 4 AOUT_LC modules are chained to control CutOff/Resonance of 4 CEM3378 In future I'm planning to replace the AOUT_LC modules of my "Behringer" by a AOUT_NG module due to the better resolution. Best Regards, Thorsten.

By default the LEDs are not switched via external MIDI events, this has to be enabled for each DOUT register seperately in the .ini file (-> mk_syx script), or with Serge's MIDIbox editor. Here the options and the default mapping: ################################################################################ # LED Map: assignes the LED shift registers to the Button Shift # registers or special values # Currently following values are supported: # 0 Default Setting (see Map below) # 1 Button Shift Register 1 (Button ID #1-#8) # 2 Button Shift Register 2 (Button ID #9-#16) # 3 Button Shift Register 3 (F1-F4 and Navigation Buttons: ID #17-#24) # 4 Button Shift Register 4 (Button ID #25-#32) # 5 Button Shift Register 5 (Button ID #33-#40) # 6 Button Shift Register 6 (Button ID #41-#48) # 7 Button Shift Register 7 (Button ID #49-#56) # 8 Button Shift Register 8 (Button ID #57-#64) # 9 reserved # 10 External Bank (1 of 8 ) # 11-15 reserved # 16 MIDI Status received for Button ID #1-#8 # 17 MIDI Status received for Button ID #9-#16 # 18 MIDI Status received for Button ID #17-#24 # 19 MIDI Status received for Button ID #25-#32 # 20 MIDI Status received for Button ID #33-#40 # 21 MIDI Status received for Button ID #41-#48 # 22 MIDI Status received for Button ID #49-#56 # 23 MIDI Status received for Button ID #57-#64 # 24-31 reserved ################################################################################ [LED_MAP] LED_SR1 = 1 # (Button ID #1-#8) LED_SR2 = 2 # (Button ID #9-#16) LED_SR3 = 3 # (F1-F4 and Navigation Buttons: ID #17-#24) LED_SR4 = 4 # (Button ID #57-#64) LED_SR5 = 5 # (Button ID #25-#32) LED_SR6 = 6 # (Button ID #33-#40) LED_SR7 = 7 # (Button ID #41-#48) LED_SR8 = 8 # (Button ID #49-#56) [/code] Brighter LED rings: yes, you could reduce the cycle counter from 16 to 4 in order to get brighter LEDs w/o additional hardware measure. Within mb64e_ledrings.inc, search for the first "andlw 0x0f", and replace it by "andlw 0x03" Best Regards, Thorsten.

I would propose to ask Bill directly for the case he doesn't read this forum section Best Regards, Thorsten.

I would propose to read http://www.ucapps.de/midibox_sid_manual_m.html as well, which describes the dynamical voice allocation in more detail It doesn't matter if the instruments are played poly or mono - voices are automatically allocated over the 6 available oscillators. Best Regards, Thorsten.

I also see that your synth chip has potential, and from my side it would be relatively easy to add support for additional sound registers. So, the infrastructure is already there. CS line: I think that an alternative addressing mode could help, so that only one CS line is required. The advantage of two CS lines (the addressing scheme I'm using) is, that I can write to a certain SID seperately, but also access two SIDs the same time. This speeds up register transfers and ensures synchronous configuration (important for stereo sounds, especially when the TEST flag is toggled to reset the oscillators) For the case that it is impossible to provide two CS lines from your side: would it be possible to provide two additional address lines, which allow following access modes: [tt] A6 A5 0 0 SID left channel 1 0 SID left channel 0 1 SID right channel 1 1 SID both channels [/tt] (basically this is propably already the same addressing you are using, only difference is, that by setting A6 together with A5, a register access will be forwarded to both SIDs) Or alternatively: do you think, that a different way to write into emulated SID registers could improve the overall performance? E.g., how about SPI, I think that AVR provides such an interface? By using SPI, the 74HC595 shift registers wouldn't be required anymore at the MIDIbox side, and the MBSID firmware could transfer register values directly to your synth chip Best Regards, Thorsten.