TK.

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.

There are new docs and demo samples: Hardware Options http://www.ucapps.de/midibox_sid_manual_hw.html Frontpanel http://www.ucapps.de/midibox_sid_manual_fp.html V1->V2 Upgrade Guide http://www.ucapps.de/midibox_sid_manual_up.html Known Issues and Troubleshooting http://www.ucapps.de/midibox_sid_manual_ki.html Best Regards, Thorsten.

Euphoricgrey - for the case you are still reading the forum: analog inputs are now handled like knobs, which means, a joystick can control 2 * 4 sound parameters of the selected SID(s), and it can be used within the modulation matrix as modulation source. Analog input handling is flexible as never before - so, this hardware option is a good decition for MBSID V2 :) Best Regards, Thorsten.

S&H is especially useful with analog signal sources, so I finally implemented a dedicated AIN handler for MBSID V2, which is officially supported from my side. In addition some other improvements (as usual)... From the ChangeLog of beta4: o an incoming patch or bank change request doesn't update the the patch anymore if it was already selected before. This is to avoid "glitches" when a sequencer sends a program change shortly before a note is played. o the "Knobs" are sending CC values now when the CC function is activated (press SHIFT + Page Up/CC Button to toggle this mode) Other parameters are still not sending CCs over MIDI, as NRPNs are not implemented yet (low priority) The CC numbers are 1 for Knob #1 (Modulation wheel), and 16/17/18/19 for Knob #2-#5 (GP values) In addition, Knob #P sends Pitchwheel Events in CC mode o support for analog inputs (J5:A0..A4) This feature has to be enabled in the setup_*.asm file by setting DEFAULT_J5_FUNCTION to 1 Conversion results of the analog inputs are directly passed to the knob handler. This generic approach has the advantage, that it is possible to control 5*2 parameters within a specified Min/Max range, and that in addition the analog values are available as modulation source within the modulation matrix (K#1..K#5) The feature behaves differently on master and slaves: Master: analog inputs are forwarded to the selected SIDs - use this option as replacement for rotary encoders, or for adding analog control elements like pots/faders/joysticks to your CS Slave: analog inputs are only handled internally - use this option for modulation with analog signal generators [/code] Best Regards, Thorsten.

Ja, richtig - LCD und Button Handling passen auch nur zu den von mir verwendeten Routings. Alternative Routings muessen hart in die Applikation einprogrammiert werden, und erfordern auch eine Ueberarbeitung des User Interfaces. Gruss, Thorsten.

Hallo, Du hast Glueck, dieses Routing entspricht der Default-Einstellung. Alle Daten, die in den MIDI In von IIC0..3 reingehen, werden am MIDI Out des Core Moduls ausgegeben. Alle Daten, die in den MIDI In vom Core Modul reingehen, werden zum MIDI Out von IIC0..3 ausgegeben. Im Grunde ist also der MIDI In/Out des Core Moduls an meinem PC angeschlossen, und die restlichen MIDI In/Out Ports mit MIDIbox SID, MIDIbox FM, MIDIbox SEQ und einem Keyboard. Alle Geraete koennen bidirektional mit dem PC kommunizieren (und optional - aber diese Switches benoetigst Du ja nicht - auch untereinander) Gruss, Thorsten.

LED Rings are not supported, and it is impossible to add this to the firmware due to conceptional reasons Best Regards, Thorsten.

1) won't be provided from my side, I will only make proposals I'm happy with my frontpanel as it is, but of course, there is always room for improvements 2) don't know, depends on the community Maybe you should just continue reading here? http://www.midibox.org/forum/index.php?topic=9238.0 (please read the whole thread, not only the first posting) Best Regards, Thorsten.

As mentioned in other threads (today two times, this is the third time): a hardware discussion page will be available this weekend. The more often people are asking for details, the higher the delay... ;-) To give you a quick answer: it will even work with the never released mbhp_core_v1 and mbhp_sid_v1 boards - in MBHP hardware compatibility is a high priority criteria. Of course, you might have to add one or two pull up resistors at the right places, but I think this is not really a killer for the old boards? Best Regards, Thorsten.