TK.

Hi Alex, yes - MIOS provides a debug interface which allows you to execute any function via SysEx - so, you could call MIOS_DOUT_PinSet to set a single LED, or MIOS_DOUT_SRSet to set 8 LEDs of a shift register at once (which is much faster) MIOS_DOUT_PinSet: F0 00 00 7E 40 00 0D 01 00 59 40 <a> <b> <c> <d> 00 00 00 00 F7 <a> and <b> are the two hex-digits of the pin number. Pin 18 (the 19th DOUT) has the hex value 12, so <a> should be 1 and <b> should be 2 <c> and <d> are the two hex-digits of the pin value. It's either <d>=0 (LED off) or <d>=1 (LED on) <c> is always 0 MIOS_DOUT_SRSet: F0 00 00 7E 40 00 0D 01 00 59 50 <a> <b> <c> <d> 00 00 00 00 F7 <a> and <b> are the SR number. <b> from 0 to F, <a> is always 0 <c> and <d> are the LED values (2 * 4 bits) Best Regards, Thorsten.

Hi gb, first a simple question: once the ID has been changed, did you also change the ID in the .syx file? This can be done with the hex2syx.pl script. Example for MIOS: perl tools/hex2syx.pl hex/mios_v1_7.hex -os_upload -device_id 0x02 for a common application: perl hex2syx.pl main.hex -device_id 0x02 Best Regards, Thorsten.

See this article http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1053942064;start=11#11 Best Regards, Thorsten.

Hi, It's very unusual to control the filter from another MIDI channel, the common way is the use of CCs (like already mentioned by Justin). This has the advantage that only three bytes have to be sent over the MIDI interface. Every sequencer can do that (also MIDIbox SEQ of course ;-)) If you are using Note On messages instead, you would also have to send a Note Off, everything else could lead to problems when another synth is also listening to the second channel. However, if you really want to do this, you could add following code to SID_MIDI_NoteOn: ;; change filter via Note On @ Channel 2 movf MIOS_PARAMETER1, W ; extract channel andlw 0x0f xorlw 0x01 ; compare with 1 (= Channel 2) bnz SID_MIDI_NoteOn_NoFilter SID_MIDI_NoteOn_Filter ;; the note number controls the filter cutoff frequency movff MIOS_PARAMETER2, MIOS_PARAMETER1 movlw 46 goto SID_CCIN_Set SID_MIDI_NoteOn_NoFilter It won't help, because all parameters have to be stored in the SysEx dump structure, and this is also limited. you can connect multiple SID modules to one core module, in this case they always listen to the same control data. But the audible effect isn't really so interesting. If you are having two identical SIDs, then the volume will just be doubled (the oscillators are digital and therefore always output exactly the same waveform). This option can make sense if you want to switch between 6581 and 8580 because of the different filter characteristics. But for really interesting (especially fat) sounds, seperate cores are the best option, so that the SID parameters are modulated independent from each other. The result is much more analog-like(especially when the LFOs are in freerunning mode and the finetune/portamento/ENV parameters are slightly different). Another, very usual method for having fat sounds is the use of external effects, e.g. chorus --- the result is similar, sometimes even better (depends on the sounds you are searching) What do you mean exactly? Saw/Pulse are already available as LFO waveform. Btw.: it is not possible to control the frequency of the LFOs from Note events so that you could use these oscillators as seperate voice. This requires a completely different implementation (and one or two additional PICs ;-)) Best Regards, Thorsten.

Hallo Herbert, am einfachsten geht es mit dem mk_midio128_syx script: http://www.ucapps.de/midio128/mk_midio128_syx.zip Gruss, Thorsten.

Hi JR, a jitter of about 2 sounds very good! The handler picks a value from this table depending on the distance between current and target position and adds this to the calibration value (values > 0x1f will be saturated). Here some pseudo code (hope that it is correct): distance is a 10-bit value distance = abs(current_position-target_position) speed = table[distance >> 4] speed += upward_move ? cali_up_value : cali_down_value; if( speed > 0x1f ) speed = 0x1f Thats difficult, because the PWM is generated from the timer0 interrupt which also handles the AD conversions. If you make this interrupt faster, the conversion results will be too bad (higher jitter). If you make this interrupt slower, the faders will be scanned less times and therefore cannot be positioned correctly anymore However, you could try to increase/decrease the preload value for TMR0L in mios_isr.inc::IRQ_Timer0 Once I've received the P&G fader from Roman I can possibly help you. Best Regards, Thorsten.

Hi Bret, to disable the menu buttons you have to edit the main.asm file: #define DEFAULT_DIN_MENU_EXEC 0xff ; disabled #define DEFAULT_DIN_MENU_RIGHT 0xff ; disabled #define DEFAULT_DIN_MENU_LEFT 0xff ; disabled #define DEFAULT_DIN_MENU_SNAPSHOT 0xff ; disabled thereafter build a new .syx file like described here: http://www.ucapps.de/howto_tools_mpasm.html Best Regards, Thorsten.

I've improved the description. Best Regards, Thorsten.

So long I haven't received the P&G fader in order to check how it is working, I can only warn: don't use them! Best Regards, Thorsten.

In my oppinion this is a typical article from somebody who has gone through the specs of other synthesizers and thinks that I possibly don't know about such goodies and now could easily implement a superset of all these features. You don't know what it technically means. Sorry, no offence, but I think that I have to bring you down to the bottom: 1) note tracking is a minor feature which I will integrate once I'm very sure that no other even more interesting parameter will be programmed anymore. Sounds strange? Here the reason why I'm always very carefully with new features: check the CC list of MIDIbox SID and you will notice that most CC parameters are allocated. Check the content of the SysEx dump (e.g. in the JSynthLib driver) and you will notice that also there most of the memory is allocated (and I already did a lot of tricks). Oh, now you possibly come with the suggestion that NRPN should be used instead of CC --- no chance! One of my focus was always the capability to control all parameters via external sequencers/MIDI controllers (most of them cannot handle correctly with NRPN), and via Velocity/Aftertouch/Modulation Wheel/Wavetable. The assigned parameter numbers are stored in 7-bit registers, this limits the maximum number of parameters to 128 Next suggestion from your side could be to remove some uninteresting parameters from the CC list to make some new place free for new ones. But this is also nearly impossible, since the internal parameter handling relies on CC parameters. A different implementation would consume much more memory (which means: some nice new functions would possibly never fit into memory anymore) 2) see my older postings, an independent mapping function for the AOUTs is planned. Currently the outputs of the modulation targets (O123 Pitch/O123 Pulsewidth/Filter) are directly assigned to the AOUTs, this assignment can only be changed in the source code. Sooner or later I will integrate a solution which allows a re-configuration in runtime (e.g. via CC on a different channel and from the control surface). But this is no job for one or two hours, I think that it will take at least two days. To give you an impression what this means: normaly I don't have more than one or two evenings in the week to do anything on my MIDIboxes. And there are still so much things I want to do for myself that I really have to priorize tasks! I think that the current possibility for the 8 AOUTs are already usable for experiments, everything else is "nice-to-have" 3) the synth engine is very busy, I did my best to put as much as possible into the update cycle, but it still takes ca. 500 uS in worst case to process all runtime states. The engine is called each 819 uS (see MIDIbox SID mainpage), this means in other words that there is no time for a second engine Now you could say, that I just should remove some features which take too much time (e.g. 2 instead of 6 LFOs). My answer: no, because this makes the basic sound of the MBSID less interesting and it especially makes the soundpatches incompatible. Something what is in my ToDo list are "Super-Poly, Super-Arpeggiator, Split, Layer, Unisono" modes for the master SID, which then directly controls the slaves. But the implementation won't be that easy... in the meantime people are already able to do some nice stereo experiments then they just spent more effort on the sequencer side. The functions mentioned before are just for more comfort. 5) see 1) --- they cost entries in the CC list. But by the way: MIDIbox FM provides a ALDLDSR envelope (see JSynthLib snapshot on the MIDIbox FM page) --- here I spent the parameter RAM since only one software-EG is available 6) did you ever do any experiments with the existing wavetable implementation? Btw.: the update rate of the MBSID wavetable is 1220 Hz, so you can do even more cool sounds than with the slow 50 Hz solution of old C64 sequencers There are 128 bytes allocated within the patch for the wavetable, there is no way to handle more in parallel (due to the execution time and the high update cycle) Everything else won't be discussed before you don't deliver the first 128 patches for the community ;-) 7) no 8 ) it's software and it's limited by the (already very very --- really --- incredible high!!! --- update frequency of 1220 Hz. This means that one period of a sine curve has ca. 36 sample points. With less it doesn't really sound like a sine anymore (also 46 Hz already sounds very... uhm... digital) 9) 2 slots for additional waveforms are free and will be implemented once I find the time... more are not possible, but can be emulated by controlling the waveform selection from a wavetable 10) typical question from somebody who things that if other synths have a depth pot for each modulation target, MBSID must have the same. Some technical background: I started MIDIbox SID ca. 3 years ago on a PIC16F877 which doesn't provide a hardware multiplier. Software multiplication takes so much cycles that I had to search for an adequate solution. And the solution was to spent much more LFOs/EGs than common synths and to forward the output values directly to the targets. The result is the same. Not exactly, because common synths mostly don't provide 6 LFOs and two envelopes for a mono voice, they provide seperate depths instead just as a workaround for this limitation. This means also, that there is more live in the sound of MBSID when you just use the existing the modulation possibilities 11) morphs require a mirror of all parameters --- impossible, not enough RAM anymore (see app_defines.h of the MIDIbox SID package) 12) modmatrix costs a lot of execution time, therefore Aftertouch/Velocity/Modwheel are only assignable to a single target. Using analog inputs is an interesting idea, but I'm not sure if this feature is important enough to disable other functions (see 1 -- CC problem) Btw.: you are always allowed to change the source code for your needs. Let's call it software bending (in distance to circuit bending ;-)) 13) Did you ever sweep the resonance of the SID? You won't notice such a big difference. Build and play with the MIDIbox SID before thinking about such features ;-) 14) As always I have to define such specs before beginning with the implementation. First I thought that controlling two SIDs from one control surface is sufficient for stereo effects. Then I was possibly in such a volatile temper that I decided the incredible: controlling 4 SIDs from a single PIC, which is doing the sound engine of one SID in parallel! Hard to believe that this works without affecting the realtime capabilities too much. I'm really proud that it works without trouble. And now you are speaking about controlling 8 SIDs from one master... people never can get enough. No, not with me ;-) However, you could build two 4*SID systems... this will possibly cost you 50 EUR more, but what are 50 EUR compared to my unpayable sparetime ;-) Best Regards, Thorsten.

Hi, when you take a look into the app_defines.inc files, you will notice that both applications (MIDIbox64 and MIDIbox CV) allocate so much memory that they cannot be combined to a single application. So, it won't be so easy to merge the projects without some programming knowledge. On the other hand: if you don't need all the features of MIDIbox64, but only the possibility to send static (predefined and not changeable) MIDI events with 64 pots and up to 128 buttons, you could add this to the MIDIbox CV application without much effort. It would only require a small number of code lines (initialize the MIOS drivers and send the events from the AIN/DIN hooks) Best Regards, Thorsten.

You could also use the premade midibox64_generic.syx file of the mk_syx.zip package which already contains the configuration for dedicated CC's for each pot/button on a single channel Best Regards, Thorsten.

Hi Schoko, Yes, try it on a breadboard step by step, this should give you a feeling which components are working (and which not) Best Regards, Thorsten.

Hi Dave, it's not really multiplexing, but just a long serial chain. This means: MIOS shifts the data through the serial chain very quickly (within ca. 100 uS, this is hard to notice without a scope). With 16 shift registers the serial clock (SCLK) will toggle 128 times. Once each shift register has it's new state, the RCLK line will be toggled so that the new values will be transfered to the output registers. This means also: if all LEDs are changing at the same time to the value of the first register output, then this possibly means that the shift clock line (SCLK) is not connected correctly How about the SCLK/RCLK line? Is it connected to all ICs? Best Regards, Thorsten.

Hi, the MBFM application is implemented in a way which allows to reuse most parts of it for other synths. The low-level layer which accesses the OPL3 registers is strictly seperated from the voice/instrument layer, which allocates and initializes the voices. Parameters are listed in a table which can be extented if required. The number of voices/instruments can be changed with single constants (but the RAM allocation has to be adapted by hand). LFOs/EGs/Wavetable, etc (-> the sound engine) is seperated. The menu interface handler is very flexible and can also be adapted very easily by people who have studied the code intensively --- and thats the point. Plug&Play is not possible, it always requires some programming knowledge to adapt the application to a new synth chip. Don't think that I will do this for you, I've already a lot of fun with the OPL3 - the possibilities will keep me busy for the next months :) For the case that somebody wants to implement a synth based on another chip, here a short checklist for things which have to be taken into account: datasheet free available? (it's not allowed to publish code which is based on NDA informations) availability of synthchip? (think about the case that you destroy one or two chips during the first experiments) has the PIC enough memory to store all the sound parameters? (if not, you must plan with much more expensive microcontrollers --- and you have to develop a new operating system) is it worth the effort? (or can a virtual sw synth do the same?) Best Regards, Thorsten.

Hi Roger, it has nothing to do with BankSticks, the host application handles the banks, and this can be in a very different way. For example, Logic provides a normal and global mode. In normal mode you select the track view (in the same order like visible in the arrange window) in +1/-1 or +8/-8 steps. In global mode you can select the channel strips like visible in the mixer window... Best Regards, Thorsten.

My suggestion: don't solder the LEDrings on a board, otherwise it will be very very difficult to attach them on the frontpanel. It already took me more than 1/2 hour to mount this 32-led board: http://www.midibox.org/midibox_lc_photos/20.html - still not every LED fits perfectly. Therefore I prefer to glue the LEDs into the frontpanel like shown here: http://www.midibox.org/midibox_lc_photos/10.html I don't know a source, but from my experiences it's easier to work with 200x100 boards maximum to simplify the mounting. The frontpanel will hold the boards together. Best Regards, Thorsten.

Hi Jon, it's impossible to edit the patch name with only one menu button. Who knows which other features will be added in future which rely on the select buttons --- therefore I cannot suggest this design change Best Regards, Thorsten.

Hi all, I'm off till January - but before I want to wish everyone a merry Christmas and a very happy New Year Best Regards, Thorsten.

This week: the chrome-plated MIDIbox Plus of George Aggelides Link to his homepage: www.vgo.w-d-n-c.com

A new MIDIbox SID version is now available. It not only comes with a lot of minor bugfixes and improvements, but especially (and finally) supports multiple BankSticks. http://www.ucapps.de/midibox_sid_changelog.html A nice christmas present for all users is the new collection of 128 preset patches: http://www.ucapps.de/midibox_sid/preset_patches_v1.zip (thanks to Bosone and RadicalAns who gave us their creations!) We've now two preset banks for 6581 and 8580. The patches within the bank are the same, but optimized for the appr. SIDs Here the list of the presets: Patch 001-107 made by Thorsten Klose (2002-2004) Patch 108-125 made by Matteo Bosi (2003-2004) Patch 126-128 made by David Panseri (2004) Since MIDIbox SID now can store up to 1024 patches, you are always allowed to send me your own sounds for the next release Best Regards, Thorsten.

Hi Nikolai, before I spent one or two hours to think about how to describe the required programming steps especially for you, one question: Did you ever try the ID_MBLC_HOLD_LAYER function which switches between the two layer tables? It works like a shift button, and the implementation is a little bit more advanced than the way how you are planning to do this. Because not only the button functions, but also the LED functions are switched. And if the LED status is changed from the host application although it's located in the not-active layer, the status will be saved in RAM so that this information doesn't get lost. I think that you want to have something like this, but should I really describe all the details? If you want to have more than one "shift" button, you could also use smaller tables. But before you are trying this, I would highly suggest to begin with a simple DIN example from the MIOS download page. Try to understand how the programs are working, this should enable you to understand even more compilcated implementations sooner or later. And once you've reached this level, it will be much easier for me to give you hints which really help Best Regards, Thorsten.

Hi Artesia, I've prepared a very generic solution for the CV OUTs: the EG5, the two LFO and the wavetable outputs of each voice (makes 36 signal sources) can be assigned to 8 AOUTs. So, you can not only control a stereo VCA, but also filters, distortion, or whatever you want. But I won't provide special schematics, because there are a lot of webpages from Synth-DIY specialist which cover these topics. However, you can start a collection of useful links if you want. 64 voices: this suggestion can only come from people who don't know how busy the PIC18F already is to handle the 6 4-operator voices (+5 percussion voices) of the OPL3. Here the register allocation list to give you an impression. Note that nearly the whole RAM is allocated. I did my best to give each RAM cell a special purpose, most of them are used for very interesting features (most of them are not part of the OPL3 itself, but unique for MIDIbox FM :-)) So, take MIDIbox FM as a synth with a special sound which cannot be achived with a common (software) synth (partly due to the "nice" and not-emulatable distortions which are caused by the limited resolution of the OPL3 internals - lets call it "crispy" ;-) ), but don't take it as a high-end synthesizer with a nearly unlimited number of voices and always perfect sounds. This area is covered by synth manufactures and not worth the effort from my side. Note also that each additional feature would mean that I have to downstrip already implemented features. The resources of the PIC18F452 are tiny compared to state-of-the-art microcontrollers (see the News section for oppinions on this topic) Best Regards, Thorsten.

Hi Nikolai, the best place is in lc_buttons.inc - here you can modify the LC_BUTTON_Handler so that one button is not forwarded to the common code, but sets/clears a flag of any free register (see app_defines.h for the memory allocation, some addresses which are not used yet are 0x24-0x3f) Thereafter you could select between different button tables depending on the flag state. You could do this for all buttons at the same time, or only for a small range - it's on you. Best Regards, Thorsten.

I purchased two touchpads from cannibalized laptops. They have a lot of pins, but no documemtation. I guess that some pins are for the PS2 interface, but I don't want to do identify the IOs with the mouse/keyboard port of my PC (to avoid any damage) So, I'm just waiting for the first release of Duggle's PS2 project. Currently both of us have other things to do ;-) Best Regards, Thorsten.