TK.

Hi, a short note to the AOUT board: I'm also not happy with this high-cost solution, especially because of the bad availablility of the MAX525. Currently I'm using only one AOUT board for myself for different purposes (MBSID/MBSEQ, later also with MBFM), a friend uses one AOUT driven by MIDIbox CV and one AOUT/SHX8 driven by MIDIbox64 to control his modular RSF kobol expanders. We both need more CV outs - therefore next year I will possibly build a cheaper version. The only problem I have is to find a DAC which suits perfectly: 1) best availability 2) best resolution 3) most channels 4) serial interface 5) best price To 1) the DAC should be available at a mailorder company which delivers worldwide to hobbyists (small quantities) To 2) 8bit is ok for most projects! 9-12bit are better, more than 12bit not required To 3) if 4 single channel DAC are available for less money than a 4-channel DAC, then I would prefer the single channel DAC To 4) a serial interface (SPI) with a chip select input, a clock and a serial in/output is preferable, otherwise the devices cannot be chained To 5) we want to save money :) So, if anybody has some tips, please inform me and I will try it out. Best Regards, Thorsten.

Hi Andrew, you must publish sound samples and pictures of the project once the first sounds are comming out! :) Best Regards, Thorsten.

I think that the MIOS C Wrapper is the better point to start for a floorboard project. It has the main advantage that it's much easier for people to customize the source code for their needs. Best Regards, Thorsten.

Hi Bblaze, sounds like the 1k resistor R2 is not connected to pin RA4 of the PIC (see http://www.ucapps.de/mbhp/mbhp_core.pdf Best Regards, Thorsten.

Hi Mandingo, it seems that you have the same problem like some other people before, either the SCLK or the RCLK line has a short. Some useful tips, how to debug this, can be found here: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1101405166 http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1096139044;start=15#28 (and in a lot of other postings, but to be honest: it's hard to find them again :-/) Best Regards, Thorsten.

It's possibly not clear that we are talking about compatibility with existing projects (there are a lot of very different configurations for the core in use), and not of future projects. Of course, if I would have to setup a new platform, I would do it different. But this is another topic and especially not in my current focus (think about the effort!) And no parallel vs. serial link discussions please ;-) Just imagine, how much people have problems with connecting the simple parallel interface of the LCD. From the system side the problem is, that the PIC hasn't enough pins to service two independent parallel interfaces for common and interrupt tasks. Therefore I prefer serial connections. Best Regards, Thorsten.

The final resolution for the destinations doesn't really matter here. You have to work with 16 (or better 24) bit anyhow once you add the LFO/EG output values, thereafter you have to saturate the result to the desired resolution to avoid distortions. thats the way how I've realized the envelopes and LFOs in the MIDIbox SID/MIDIbox FM firmware (see sid_lfo_table.inc and sid_env_table.inc) It definitely is a nice challenge, especially because you are able to hear the results - and sometimes really wired things are coming out, sounds which won't be doable with the final (bugfixed) algorithm ;-) Best Regards, Thorsten.

Hi Andrew, I'm missing an important spec, and thats the update cycle for all voices. I guess that this number of modulation sources/destinations can be processed within ca. 500 uS with 16 bit resolution. A lower resolution is not practicable, since especially EGs require a high-res counter, otherwise slow ramps cannot be realized Calculation example: let's say the waveform generator is clocked at each millisecond, the EG counter is working with 16-bit resolution, this means that ramps with up to 65s are possible. With 8-bit resolution the maximum ramp time is only 256 mS For LFOs a high-res counter is also required, with 8-bit you would only get a minimum frequency of 4 Hz (depends on implementation), with 16-bit ca. 0.015 Hz 1 mS update cycle means that 1mS-500 uS = 500 uS are free for other tasks: for updating the analog outputs, handling MIDI, printing LCD messages, etc... Best Regards, Thorsten. Addendum: I just remember that for such a dedicated application you can "unroll" your code, means: avoid iteration loops and avoid the use of pointers and indirect addressing, but generate the code directly (e.g. with macros). Registers should always be addressed diretcly. This enlarges the code dramaticaly, but can reduce the execution time by factor 3..5 and more :)

Hi TL, I get the message, that the application cannot be started due to a missing .bpl file (rtl60.bpl) Best Regards, Thorsten.

Hi, the upcoming minor release of MIDIbox SID will finally get the possibility to switch between different BankSticks from the CS menu or via MIDI. Since there are currently only 76 preset patches, I'm asking you to send me your creations (-> tk@midibox.org). The number of patches doesn't matter, there are 1024 free slots :) I will put them into a JSynthLib bank, and I will also provide 32k BankStick .syx files which can be uploaded directly with Serge's SysEx Loader for people who are not able to get JSynthLib properly running. Best Regards, Thorsten.

Hi Adam, problem with the OPL3 is, that there are not so much parameters which are worth to modulate with a high-resolution LFO/EG. Most of them are 4 bit only. Therefore my strategy is to have a modulation link to all high-resolution parameters, and these are the four "volumes" (note: volume on a modulator->carrier connection means that the amount of FM), the note pitch, the LFO frequency, the assigned AOUT (analog CV output) - and thats all. There are already 14 modulation targets (each has a seperate depth parameter into negative/positive direction), with 6 voices this makes 84 modulation targets which are handled in parallel. I think this is enough for the small PIC ;-) The diode, gain, etc... features could be selected with the waveform parameter, so here I'm open in the future Anyhow, all parameters can be modulated with the wavetable sequencer. Thats the strategy for more complex sounds, and therefore the possibilities are hard to compare with common synths. Best Regards, Thorsten.

Hi, also the MIDIbox project has a FAQ: http://www.avishowtech.com/midibox/wiki/index.php/Question%20and%20Answers#QA37 (there is no proper solution) Best Regards, Thorsten.

The most recent version of the C wrapper is now available for a public beta test: http://www.ucapps.de/tmp/mios_c_wrapper_beta1.zip This package also contains a binary of the release candidate for MIOS V1.8, which is required to get the wrapper properly working (there is only a small change: FSR0L and FSR0H will be saved on interrupts) More informations about the C interface can be found here: http://www.ucapps.de/mios_c.html Note that the current sdcc has a bug which doesn't produce proper assembly code for the PIC18F. Please use following sdcc snapshot instead: http://www.midibox.org/sdcc_tmp/sdcc-snapshot-i586-mingw32msvc-20040716.zip Best Regards, Thorsten.

Hi Graham, it seems that the current sdcc snapshot doesn't work properly. :-/ I've uploaded an older version and a new beta release of the C wrapper to the MIDIbox server - see next posting. Best Regards, Thorsten.

Hi Rowan, the MIDI messages are specified in the Logic Control User manual, which can be found somewhere at the Emagic Website, but also here: http://www.netzmarkt.de/thomann/prodbilder/151261_manual.pdf Best Regards, Thorsten.

Alright, the link to the drum example should work now: http://www.midibox.org/midibox_fm/mbfm_demo5.mp3 - if you get a "service temporarily unavailable" message, then try it again after some minutes. It seems that the server is currently very busy. Matteo: I've added some photos to the http://www.ucapps.de/mbhp_opl3.html page. Marcel: yes, but a very FM-like drum synth (see example): punchy bass drum and a lot of noise ;-) Unfortunately the frequencies for the Toms and snare/hihat/cymbal is not independent from each other, also the envelopes are very rough. But this doesn't prevents you from creating some nice grooves :) Moebius: I will check the request for a multistage EG once I know how much parameters are free after the planned features are implemented. Live editing: I've already an alternate view for the most important parameters in mind, maybe I can extend this idea by a set of full assignable parameter pages, where the parameter number and adjustable range can be specified. :) Granular synthesis: hold the line until I will start with FPGAs (just kidding - or not? ;-) Best Regards, Thorsten.

Fixed - the other three chips are TL074 (a common operation amplifier) Best Regards, Thorsten.

Well, one month has passed after the last update, here is the current status: D2k has created a PCB layout for the MBHP_OPL3 module which is perfectly working: Not visible: the 3 SMD chips at the bottom (one YMF262, two YAC512). The second YAC512 is optional for two additional audio channels. The firmware is ca. 75% completed: the synth architecture is defined, all implemented features are working (hopefully ;-)) without failures, the first two JSynthLib editor panels are running. The Patch Editor: Full view: http://www.ucapps.de/midibox_fm/mbfm_patch_panel_pre1.gif The Drum Editor: Full view: http://www.ucapps.de/midibox_fm/mbfm_drum_panel_pre2.gif Missing: the ensemble editor which allows to edit the MIDI channel assignments/keyboard ranges/transpose/audio channels, etc... for the 4 instruments Some new demo samples (no perfect work yet ;-)): A .mid file (Phil Collins, Against all Odds...) played with a Rhodes-like sound. This was to test the polyphony (6 4OP voices are automatically assigned, the longest note will be killed first): http://www.midibox.org/midibox_fm/mbfm_demo3.mp3 Some sound engine tests - note that beside of the hardware EGs, each voice has two additional LFOs and one EG. Each modulation target has an own depth pot, and it's also possible that a LFO or EG modulates the frequency of another LFO (so really wired things ;-)): http://www.midibox.org/midibox_fm/mbfm_demo4.mp3 The third example demonstrates the possibilities of the drum synth, which has it's own voices (it runs in parallel to the main synth engine): http://www.midibox.org/midibox_fm/mbfm_demo5.mp3 Next targets: finalize all planned features, adding the third editor panel for an ensemble, completing the minimal control surface, starting with the full control surface, case, and having a lot of fun :) Best Regards, Thorsten.

Hi Rowan, no, with "LCD_EMU_COL 40" the text output will be cutted after the 40th character. LC doesn't send individual messages for each fader/vknob combination, there is only one message type and one 2x55 screen. Some people (e.g. Axel) customized the display output routine by removing some of the characters within the 2x55 range, so that they are able to use smaller displays. You could ask them for the code... Best Regards, Thorsten.

Hi Rowan, the logic/mackie control protocol supports 2*55 maximum, therefore the screen layouts (-> lc_clcd.inc) are only prepared for this max. number of characters per line. You will notice that the left and right side of the display is filled with some additional informations (e.g. button status of mute/solo/rec, time code, etc...) by MIDIbox LC, so that the whole screen (2 * 2x40) is utilitzed. Best Regards, Thorsten.

Yes, but in reallity you won't regognize such an effect. E.g., the AIN driver still samples the analog inputs in background (interrupt driven), so changes won't get lost. This system behaviour ensures not only the LCD coherency, but it also solves some other issues (e.g. it prevents MIDI protocol violations if an incoming stream is merged with the outgoing stream) Best Regards, Thorsten.

Of course, #2 could be made quickly, but over the years I've learned not to do such quick changes on request anymore, since this mostly means that people start to request even more - with the effect that I'm not able to finish my own plans. I also don't want to change the user interface in a way which is obsolete once the song part functiuon is available... mostly such "redundant" features will lead to a really unwanted complexity. In worst case it could lead to the situation where much more useful functions are not integratable anymore since the code for the redudnant functions fills the memory A general note.: users are always allowed to integrate these functions by themself. But without my support, and propably without the chance to bring the additions into the official release (this is only possible once the project is completely finished from my side...). This is not because of ignorancy to other programmers, but just required to reduce the effort from my side. Best Regards, Thorsten.

Hi Nico, thanks for the compliments! :) First of all I must say that I'm aware of this "problem", but currently I'm totally focused on MIDIbox FM, therefore I fear that I won't find the time to add some new features to MIDIbox SEQ in this year. I've already defined a solution which improves the live handling of multiple patterns which belong together. See also the wish list under http://www.ucapps.de/midibox_seq.html: Especially the "song part" feature will allow you to define up to 16 sets of patterns within one song. You will be able to switch between the parts from the general purpose buttons, or with a keyboard. You will also be able to edit track 5-16 in realtime. Hope this makes sense :) Best Regards, Thorsten. P.S.: no, it is not possible to save the track mute status. Maybe this could be added to song mode in combination with the parts

Hi Skynth, yes, you can do this on a similar way like for the double note events. Just take a look into mb64_meta.inc Best Regards, Thorsten.

They are generated with selfmade perl scripts: http://www.ucapps.de/midibox64_tutor/gen_mb64_screens http://www.ucapps.de/midibox64e_tutor/gen_mb64e_screens http://www.ucapps.de/midibox_cv/gen_mbcv_screens http://www.ucapps.de/midibox_seq/gen_mbseq_screens http://www.ucapps.de/midibox_seq/tutorial1/gen_tut1_screens http://www.ucapps.de/midibox_sid_cs/gen_mbsid_screens Best Regards, Thorsten.