TK.

The intention of this thread is to inform you early enough about a new decision I made for the MBSID V2 hardware. As mentioned in the wishlist thread (http://www.midibox.org/forum/index.php?topic=6564.0), I've evaluated the usage of a CAN interface for MIDIbox SID V2. More informations about this interface can be found here: http://en.wikipedia.org/wiki/Controller_Area_Network The big advantage for MIDIbox SID is, that the master can not only send data to the slaves, but also receive data from any slave. Accordingly, it will be possible to share resources over multiple microcontrollers w/o the need for mirroring the data. This ensures data consistency, and frees some memory for nice features, e.g. double buffering of parameters for non-destructive modulations, an UNDO function for patches, large bassline and drum sequences, etc... Another advantage is the speed of course, it's 1 MBit/s, and the ECAN peripheral handles most of the transactions (e.g. message filtering, checksum calculation, data buffering via FIFO), which leads to a very good performance and stability compared to other network solutions like MIDI or IIC. With the PIC18F4685, Microchip provides a Microcontroller which is pin compatible to PIC18F452, almost SW compatible (with only one exception: RAM between 0x60-0x7f is not directly accessible), which contains 96k flash (3 times more than the PIC18F452), 3328 bytes RAM (ca. 2 times more), and a 1k EEPROM (4 times more). It seems that the EUSART bug has been solved on this new derivative (an advantage compared to PIC18F4620), accordingly no MBHP_IIC_MIDI interface will be required as a workaround anymore. So much about the reasons for the decision. For all users who already purchased a PIC18F4620: at the beginning of the project it can propably be used for a master-only MIDIbox, but once the application is bigger than 64k, you will have to switch to PIC18F4685. A possibility is maybe to sell the chip to users who are building a MIDIbox SEQ V3, because this application still needs a PIC18F4620 due to the RAM requirements To give you an impression about the hardware changes, here a schematic for the MIDI/CAN wiring: (PDF: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf) All CAN Rx lines are connected together to a single wire, which is pulled to 5V via a 1k resistor. The CAN Tx lines are connected via 1N4148 diodes to the wire, which forms a "wired-AND" The Master Core has a MIDI In/Out pair, the MIDI In is directly forwarded to the slaves for an optional "direct control", and for MIOS code upload (in MBSID V1, the MIDI Ins of the slaves were connected to the MIDI Out of the master, this is not required anymore, as the master can send data to the slaves via the CAN interface) Since two data pins of the LCD are allocated by the CAN peripheral, the LCD has to be used in 4bit mode. This is no performance loss, as the LCD benchmark turned out. The 18F4685 variant of MIOS always accesses the LCD in this mode During this weekend I adapted the bootloader and MIOS for PIC18F4685 and PIC18F4682 (a similar derivative, but with smaller flash memory), and I changed the MBSID V1 firmware, so that the master sends patches and parameter changes to the slaves via CAN. The results are already very very promissing, in fact there is no difference anymore, if a sound is played from the master or from a slave, it "feels" like a big microcontroller is running which controls all SID chips directly (quad-core). :) Since resources are shared, it would even be possible to attach more microcontrollers and to control them from the master. Not only MIDIbox SID's, but also MIDIbox FM's... thanks to the 96k flash, there should be enough room for CS variations. This as an outlook for next year (2008) or later ;-) Best Regards, Thorsten.

Here a quite impressive snapshot from my scope: Master receives a MIDI Note and forwards it to a slave via CAN Bottom (Channel #2): 3 MIDI bytes Top (Channel #1): the CAN frame with 10 bit ID (used to address the MIOS core and to notify the MIDI package type), the control field, the data field with 3 bytes, the CRC checksum and the acknowledge Sorry for the bad resolution, but CAN is soooo fast (and transfers are still extremely stable :)) Best Regards, Thorsten.

Yes, this is possible. BankSticks can be changed on-the-fly during runtime (hot plugin) Best Regards, Thorsten.

currently yes. It could be, that I will provide an option for using 64k BankSticks for Songs (32 instead of 16 songs), it would be an easy change yes, but the maximum number of IIC EEPROM devices is 8. They could be located at different PCBs, but each device needs a unique address on the IIC bus Just order 8 x 24LC512 (Mixer: only 32k are allocated, but you can use a 64k device which doesn't hurt) Best Regards, Thorsten.

Hi Dauwige, the LEDs shouldn't be on at power up. Maybe they are connected to the wrong shift registers? Note that the common LED lines are mirrored between v2.4 and v3.0 - which changes did you made in the source code? No, there isn't a routine for system info, but there is a memory usage map in the *.lst file which is useful. When you assembled setup_mbseq_v3.asm, the map will be at the bottom of setup_mbseq_v3.lst The wrong processor type in the setup_* files of MBSEQ V3 is an error, I will change this. But it doesn't cause a problem, since the correct type is defined again in mios.h, and this definition overwrites the last one. Nevertheless, consistency always makes sense :) Best Regards, Thorsten.

:) Best Regards, Thorsten.

Hi, yes, the resonance cannot be interpolated. Internally it works with 7bit resolution (128 steps) as you assumed. The SID itself has only a 4bit register for resonance. CutOff has internally 16bit resolution (65536 steps), the SID provides a 11bit register for CutOff. yes, you could even combine 3 shift registers instead of 2 to output 16/8 bit resolution, the changes have to be made in sid_aout_lc.inc the output curve is linear, don't know if we can speak about V/Oct when no oscillator frequency is controlled by the CV Best Regards, Thorsten.

To which value did you set the AOUT in the source code? (ENABLE_AOUT switch) Best Regards, Thorsten.

I wanted to wait with this message, but it seems that it's time to tell you more about the current planning: Something which is in my "evaluation queue" is the PIC18F4685 - it's pin compatible to PIC18F4620, but provides a CAN interface. Accordingly, bidirectional transfers between master/slave would be possible with 1 MBIT/s CAN could be easily used to communicate with other MIDIboxes as well w/o loading the MIDI interface. And propably on these devices the EUSART bug would also be fixed, which is another advantage. To highlight this again: this idea is under evaluation! I thought about the usage of a CAN interface several times in the last months, now some really interesting new derivatives are available (with 96k flash!) which could be perfect. For MBSID V2 this would make direct resource sharing possible, and other devices could interchange parameters as well superfast. Another point is, that stryd_one found an interesting link to another MIDI/CAN synth project some days ago (http://wiki.netsynth.org/index.php?title=Main_Page), which shows me, that I'm not alone with this idea. But from my point of view, I will definitely not seperate parts of the synth in this way (oscillators, modulators, etc... as seperate devices), but just try to improve the communication between MIDIboxes to achieve best performance. Best Regards, Thorsten.

Die alten Bilder befinden sich hier: http://www.midibox.org/midibox_sid_photos Die neuen (fuer Anfaenger absolut nicht empfehlenswert, da Buttons/LEDs zu einer platzsparenden, aber schwer debugbaren Matrix verschaltet sind!), hier: http://www.midibox.org/midibox_sid_blm_photos Gruss, Thorsten.

Hi Dave, in the encoder driver of MIOS I'm doing plausibility checks in order to overcome this problem. The idea is, to measure the delay between two "encoder ticks". If it is shorter than 16 mS, an increment event won't be forwarded to the encoder handler if the last one was a decrement, and vice versa. The code is located in mios_enc.inc; it works quite well with noisy encoders. I don't know if there are better methods, since this was developed by myself - it was the result of many experiments with different encoders :) Best Regards, Thorsten.

With the scaling routine (http://www.ucapps.de/mios_c_send_range.html) it would be very simple... Here a special adaption of the programming example for your use case: ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS after startup to initialize the // application ///////////////////////////////////////////////////////////////////////////// void Init(void) __wparam { // initialize the AIN driver MIOS_AIN_NumberSet(8); // 8 pots are connected MIOS_AIN_UnMuxed(); // the AINX4 modules are *not* used MIOS_AIN_DeadbandSet(7); // should be 7 when 7bit resolution is used } ///////////////////////////////////////////////////////////////////////////// // This is an assembly optimized function which scales a 7bit value between // a minimum and maximum value ///////////////////////////////////////////////////////////////////////////// unsigned char Scale_7bit(unsigned char value, unsigned char min, unsigned char max) { // scaled value is (<8-bit random> * ) >> 8 PRODL = value << 1; // 8bit value PRODH = max-min+1; // range __asm movf _PRODL, W mulwf _PRODH, 0 __endasm; return min + PRODH; } ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { unsigned char value; // scale 7bit value between min and max boundary value = Scale_7bit(MIOS_AIN_Pin7bitGet(pin), // converted to 7bit 0, // min value 8); // max value // send scaled CC value over channel #1, CC Number 16..23 MIOS_MIDI_TxBufferPut(0xb0); MIOS_MIDI_TxBufferPut(16 + pin); MIOS_MIDI_TxBufferPut(value); } [/code] Best Regards, Thorsten.

This is nothing which needs to be built into MIOS, instead everybody is free to add routines for a MIDI controller to the existing application hooks. But of course, there will always be memory limitations, and for MBSEQ you would have to decide, if you prefer more sequencer, or more MIDI controller features. I think that even a simple button sending routine doesn't make much sense (all or nothing?), and wouldn't really be used. So I reject this feature request. Best Regards, Thorsten.

I will build in either a very primitive button sending routine with an exactly defined behaviour, and which will propably only be used by Matteo, or no button sending routine at all So, here the question again: should they send different notes, or the same note over different channels? If somebody searches for a flexible controller, have a look into the MIDIbox64E package, or MIDIbox LC V2 alpha (where you can turn your sequencer into a Logic Control ;-)) - I won't do all the effort again, just because somebody had a quick idea what could be missing in the sequencer firmware... Best Regards, Thorsten.

Sieht gut aus! :) Der MBSEQ V3 Code ist bereits mehr oder weniger freigegeben, es fehlt eigentlich nur noch die dokumentation. Einen Update kann ich nur waermstens empfehlen (dem Patternumschaltproblem kann ich leider nicht mehr nachgehen), den PIC18F4620 gibts bspw. bei Farnell, bald auch bei Mike. Ausserdem benoetigst Du noch mindestens ein MBHP_IIC_MIDI Modul (bis zu 4 unabhaengige MIDI Outs werden unterstuetzt) Gruss, Thorsten.

Nice work! :) I gave the MBFM source code a try; some gpasm errors are related to the reason, that the converter doesn't ignore comments. E.g., if a comment contains "IFSET", a new line will be generated with a propably wrong (or unwanted) instruction. When you replace: # search for macro occurences if( $_ =~ m/$macros[$m]/ ) { [/code] by: [code] # search for macro occurences if( $_ =~ /^\s+$macros[$m]/ ) { it will work better, as only valid macros will be replaced. Thereafter we have only a few number of errors: cs_menu_print.inc:714:Error [103] syntax error cs_menu_print.inc:715:Error [174] Unknown opcode "print" cs_menu_print.inc:738:Error [103] syntax error cs_menu_print.inc:739:Error [174] Unknown opcode "print" [/code] appr. replaced code: [code] btfss TMP1, 6, movlw '-'; (if value <= 0x3f (6th bit cleared) print "-" means: we still have a problem with comments. A quick&dirty solution: # search for macro occurences if( $_ =~ /^\s+$macros[$m]/ ) { s/;.*//g; # remove comments [/code] There is still one error thereafter: [code] cs_menu_io_tables.inc:75:Error [108] Illegal Character (,) but this is a syntax error from my side which was ignored by MPASM - remove the "," at the end of the line. Code can be assembled with "gpasm main.asm", there is no linker script required, w/o the "-c" option you will get a .hex file (main.hex) by default Best Regards, Thorsten.

Hi Hans, yes, with the new C version it's much easier to map the LC characters (2x55) to different LCD positions, search for large_screen_cursor_map in lc_lcd.c Best Regards, Thorsten.

I could add a very primitive support for using the 16 GP buttons as Note Triggers, only question: should they send different notes, or the same note over different channels? Best Regards, Thorsten.

I will take this as inspiration, but currently don't have enough time to give you detailed answers (sorry!) (I still haven't started with MBSID V2, or even with finalising MBSEQ V3, but I will do my best to make a first official MBSID V2 release real mid of this year :) Some quick comments: An direct UI control of MBFM is not possible due to various reasons, but a generic control possibility for any external synth could be realized. E.g., selected CC's which are in-sync with MBSID parameters (scalable of course), Note or CC events which are forwarded to sync Envelopes, LFOs, Wavetables, etc... of another synth, etc... AOUT extensions: noticed and found as useful More flexible patch format: already planned :) The SE options in MBSID V1 was the first step, reserving a number of bytes for flags and 7-bit values is the next step. Flexibility: how about a plug-in concept for user-coded effects? Possible Plug-Ins: - AOUT Maniac - Fancy Arpeggiator - Random Sequencer - Stereo Widener - 5.1 Surround Delay - Pseudo FM - SpeakJet Controller - etc. etc. etc. (all routines have to be programmed by users for users) Best Regards, Thorsten.

Hi uneksija, the SID module uses the same transistor circuit as the C64. I made a lot of experiments in the past (e.g. connected the SID to various filter circuits, to different mixers, as audio source for small amplifiers, etc) and never fried a chip. So, it seems to be sufficient at least for DIY purposes. However, an additional OP amp doesn't hurt, and this seems to be a good idea to realize a double protection, just for the case... it could amplify the signal as well, as the SID output is not so loud like common synths. I wouldn't use diodes, since they could affect the sound, and I'm not sure if a transformer really helps, since there is still a direct galvanic connection. Best Regards, Thorsten.

see above - fantastic work! :)

Hi Sebastian, the MIDI event filter is the Link Option, only devices which can handle the MIDIbox Link can send "tunnled events" like described here: http://www.ucapps.de/midibox_link.html Which device is exactly connected before the MIDIbox, and which events does it send? Maybe there is an easy to implement solution for your special case Best Regards, Thorsten.

Yes, but as mentioned above, the problem is that the port appears as COM interface under Windows, and not as MIDI interface. So, somebody would have to program a driver which redirects COM to MIDI, and (something I find really important), which allows multiple clients (e.g. MIOS Studio and your favourite MIDI sequencer) to access the MIDI interface the same time. Best Regards, Thorsten.

IFSET and IFCLR were the first macros I ever wrote in PIC assembly (anno 1998), because I always mixed the btfss/btfsc instructions, and I wanted to have the branch in a single line. I'm not sure if it is worth the effort to change my own coding style (as it has to be done for all projects - it's really hard work), but in general I think that it can be easily solved with a small perl script which search/replaces the macros, instead of a bash script which uses sed. Advantage: every MIOS user has to install perl anyhow, no need for additional tools. Best Regards, Thorsten.

Hi Hans, I don't know if any host allows to use additional encoders (I don't think so) Concering SysEx in C: some time ago I started with a MBLC implementation in C, but I never finished it. Only thing which is missing (so far I remember) is the support for the MTC LED digits. The alpha version is located here: http://www.ucapps.de/mios/midibox_lc_v2_0_alpha1.zip The SysEx handler can be found in lc_sysex.c Best Regards, Thorsten.