TK.

Build #68 contains a lot of improvements I made in the last two weeks for the song menu page and the phrase/song mode. Phrase mode is the one I prefer to use, as it allows me to prepare pattern sets and to switch betweem them interactively while the sequencer is playing. Song mode is the traditional mode you know There is a slight incompatibility when you've used song position jumps in the past. The target position is now stored in the G0 parameter. But this change allowed me to introduce two new song actions: jump song and dump mixer map. From the ChangeLog: o in song menu page, there is now a better seperation between "Phrase" and "Song" mode. It can be switched between these two different modes by pressing the SONG button multiple times. The SONG LED will flash when the sequencer is in Phrase mode. Definition of Phrase Mode: a song is used as "pattern set storage" You can define a set of 4 patterns (G1/G2/G3/G4) for each song position. You can link one or more mixer maps to a phrase. The sequencer changes to a new pattern set immediately, or synchronized to the beat (selectable in options menu), once a new phrase has been selected. This can be done with GP encoder #2 (Phrase A1, A2, A3, ..., A7, B1, B2, ... -> 128 phrases). In addition, the phrase A1, B1, C1, ... P1 can be directly triggered with the GP buttons when the cursor flashes below the "Phrase" menu item (second item in the menu). Quick selection: press LAYER B button (see below) The usage of GP buttons is propably the most prefered, as it allows you to quickly change between different pattern sets while the sequencer is playing w/o temporary selecting other sets which are between them with a rotary encoder. Phrases can also be combined with one or more mixer maps. In this case the first step (A1, B1, C1, ...) has to be assigned to a Mixer Map Action (see below), whose content will be dumped out. The sequencer will go to the next song position, and check for a Mixer Map again. Once it has reached a position with a pattern set, it will change to the new set and give back control over pattern changes to the user. Definition of Song Mode: similar to Phrase mode, each song position holds a pattern set. In addition, following actions can be defined: o STOP: will stop the sequencer once this position is reached o PLAY (x 1): plays the pattern set for one measure and thereafter jumps to the next position o LOOP (-> x 2 .. x16): loops the position 2 .. 16 times and thereafter jumps to the next position o JUMP POSITION (-> A1 .. -> P8): will jump to the given position o JUMP SONG (-> S 1 .. -> S16): will jump to the given song o SELECT MIXER MAP (-> 1..128): selects a mixer map and dumps the content. Continues with the next song position Shortcut buttons: within the Song Menu Page, most menu items can be selected very quickly with the TRACK and LAYER buttons. o TRACK 1: sets cursor to G1 item - you can now change the pattern with the GP buttons or with the datawheel o TRACK 2/3/4: like above, but for G2/G3/G4 item o LAYER A: sets the cursor to the Song item - you can now change the song with the GP buttons or with the datawheel o LAYER B: sets the cursor to the Phrase/Pos item GP buttons select 1 of 16 phrases/positions in steps of 8 Datawheel selects 1 of 128 phrases/positions o LAYER C: only in Song Mode: selects the Action item o new option: when the sequencer is running in song mode, the edited song position can now automatically follow the song. This optional function, which might disturb an edit session, can be enabled in the options menu (F1->Opt., within this menu, press select button to reach the "FollowSong" option) o there is now a check during the initialisation for the PIC derivative. Execution from any other PIC than PIC18F4620 is gracefully prevented. You will see a message on screen, and a MIDI event "EE <devid[2:0]> <devid2[9:3]> is sent to notify about the wrong PIC [/code] You will also notice, that main.asm has vanished. Now only setup_*.asm files are available anymore - this is to make clear, that main.asm was my own setup with special hardware settings (it's now in setup_tk.asm)

Yes, there is a way - just use the MIDI router project. A firmware for a standalone MIDI merger is not available, however, I guess that you have a PIC18F452 free from your MBSID V1 Best Regards, Thorsten.

Vielleicht haben noch andere Leute einen PIC18F4620 herumliegen, den sie sich urspruenglich fuer die MBSID V2 besorgt haben. Ansonsten bietet Mike einen vorprogrammierten PIC18F4620 in seinem Shop an. MBSEQ V3: die laeuft ja schon seit ca. 3 Monaten bei ein paar Leuten, alle geplanten Features sind implementiert, ein paar neue Requests von Anwendern sind noch unter Diskussion, Bugs gibt es keine Siehe auch http://www.midibox.org/forum/index.php?topic=7805.0, dort steht ein Link zur Firmware Gruss, Thorsten.

My comments this weekend (I've already prepared an update of MBSEQ, e.g. the song menu page has been overworked, but its not complete yet) Best Regards, Thorsten.

V2.4 kann nur einen einzigen MIDI Port adressieren. Es ist moeglich, das Modul bereits jetzt zu verwenden, indem Du die MIOS ID auf 00000000100000 aenderst. Im change_id Package gibt es hierfuer bereits ein vorgefertigtes .hex File (iic_midi_10.hex), dass Du einfach nur aufladen musst. Danach wird der MIDI Out ueber das MBHP_IIC_MIDI Modul mit Adresse 10 geroutet Danach wieder die MBSEQ Firmware aufspielen jep, kein Problem Uebrigens: in der Fleamarket Sektion werden gerade PIC18F4620 mit aufgespieltem Bootloader angeboten! (8 EUR + Versand) Gruss, Thorsten.

Hallo, wuerde mich ebenfalls interessieren. Ich habe noch kein Programm gesehen, das ohne Neustart die Liste der MIDI Interfaces aktualisiert, und diese dann auch noch automatisch verroutet Gruss, Thorsten.

as my boss says to such questions: today we will solve the problems of today, tomorrow the problems of tomorrow ;-) However, the two allocated pins RB2 and RB3 have to be duplicated at a free port, e.g. Port RA2 and RA3. This doesn't cost much performance Currently I would prefer a compile option here, since it's a very special case. I've already changed MIOS, so that derivative specific settings can be made at a single place (mios.h), thereafter you need to build a new mios binary. #if PIC_DERIVATIVE_TYPE == 4 LIST P=PIC18F4685, R=DEC #include <p18f4685.inc> #define PIC_DERIVATIVE_CODE_SIZE 0x18000 #define PIC_DERIVATIVE_RAM_SIZE 0xd00 #define PIC_DERIVATIVE_EEPROM_SIZE 0x400 #define PIC_DERIVATIVE_IRQ_WORKAROUND 0 #define PIC_DERIVATIVE_T08BIT_INVERTED 0 #define PIC_DERIVATIVE_SET_LCD_4BIT 1 #endif [/code] Please note that I found out, that the 4bit initialisation sequence doesn't work with all LCDs (it didn't work with my displaytech 2x20). In the meantime I solved this, the fix will be available with the next MIOS release I will make it available next weekend. My priority was on CAN setup at the application side, I haven't updated MIOS yet to support addresses >= 0x10000, this will require some changes at places where the table pointer is initialized, and the ISR needs to store/restore TBLPTRU in addition CAN is an ISO standard, there are many microcontrollers available which support this interface, especially 16bit and 32bit microcontrollers for the automotive range which "bigger" PIC do you mean? Or do you mean another microcontroller family? Yes, of course, it's only a question of implementation effort. yes it will require a small modification in app_defines.inc, some variables which are located to 0x060-0x07f, and which are accessed directly, need to be located to another location (or the code need to be changed). However, a modified MBSID V1.7303 version is available on request. It's 100% compatible, and already gets use of the CAN interface - I won't release this version officially, as the communication protocol is not the best (accordingly this is not a good programming example), it's just a quick&dirty hack that I've used to evaluate the feasibility. In MBSID V2 I will take care that the memory structures are optimized for fast CAN transfers from the beginning Best Regards, Thorsten.

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.