TK.

Re-ordering the Event modes wouldn't directly mean, that the old patches are not working anymore. You only have to increase the mode number in the event menu and store the patch again. I think I will go this way - better to earn complaints now than frequently in the next years. ;-) Best Regards, Thorsten.

No, I got them as samples from Microchip. They are available for US $7.78 from Newark - this is the company which collaborates with Farnell. Maybe somebody could ask Mike for a collection order for Europe, could organize it by himself, or ask SmashTV Best Regards, Thorsten.

I've defined my own high-level protocol which is optimized for fast and secure transactions between a MBSID master and MBSID slaves (in theory also MBFM slaves will be controlable - let's test it next year). It doesn't follow a certain standard, as this would only restrict the possibilities. I also don't have plans to replace MIDI (although in theory it would be possible). I neither own a CAN interface for my PC, nor I've plans to program anything into this direction. I can only say, that it is prepared for multimaster accesses, and thats all. Don't know, what you want to say with the links... Best Regards, Thorsten. P.S.: yes, of course, also other MIDIbox synths or compatible devices could be controlled from the same master device. But just don't forget, that somebody needs to program the control surface software. This sometimes isn't a 1-2-3 task, a really good control surface is a work of months! And this fact seems to be overlooked by a lot of newbies here.

Just write me a mail to get a temporary version Best Regards, Thorsten.

Up to 16 different modes can be realized, problem is only the order of listed modes in the menu. 1) I could either add it behind Note/CC/Len, but this would make existing patches incompatible if they are using modes behind this new one. People could complain about this 2) Or I could add it to the end of the list, but in this case some other people could complain about the strange order of event modes. So, what would you prefer? Best Regards, Thorsten.

The expensive solution would require seperate CAN tranceivers for each PIC. But the diode/pull-up resistor approach works extremely stable as I noticed, and I think that tranceivers are only required for higher distances (e.g. > 1m or so..), or if you are planning to access the master/slaves from another CAN node like from a PC with CAN interface card (I've prepared this multimaster capability in the protocol). Maximum distance: 40 meters Best Regards, Thorsten.

I would prefer what I've proposed several times: that uCApps turns into a "reference manual", whereas the wiki goes into the direction of a "user manual". I would like to concentrate on the specs and requirements, and the wiki could elaborate it more understandable for common users, who are not so deep into the topic. Example: MIDIbox64 - most people don't know, what cool things they can do with this controller, they don't know, what "Snapshot", "MIDI Merger", "Morphing", "Meta Events" really means. Some people even don't know, what a MIDI controller can do at all, how to setup their software, etc... for myself, this is clearly a part of a user manual, and this is the stuff which has to be documented by the community. Once such a "user manual" exists, I would just reduce the MIDIbox64 page, so that it highlights the features and lists the links to additional informations. And at least one link would go into the Wiki Another example: the bootloader page for newbies is clearly a more user friendly description of that what you can read in the expert page -> Wiki. Also the description of the MIDIbox SID Control Surface needs some extensions, it has been started here: http://www.midibox.org/dokuwiki/doku.php?id=midibox_sid_v1_manual, but it's far from completion. Once this page is complete, I would replace http://www.ucapps.de/midibox_sid_cs.html, but of course, I would never replace the main page http://www.ucapps.de/midibox_sid.html Of course, the wiki can and should never replace ucapps.de, this would be the wrong way. So, please don't discuss about the sense or nonsense of the wiki, just improve it! :) Best Regards, Thorsten.

This idea isn't so new... the problem is, that so many people offered help in the past, but the results were only an overworked layout or re-verbalized informations from my own page with zero advantages for the users. It's the content, that counts! So, my proposal: copy an uCApps page into the Wiki, improve it dramatically, and I will replace the old page by the new wiki page. Please don't do this in hurry, but do this with full dedication. Don't try to revolutionise uCApps.de immediatly and left it as a long-term lot, but bring it slightly into a new direction! Best Regards, Thorsten.

I'm using Wilba's PCB in the meantime and accordingly don't have problems with the space inside the case See http://www.midibox.org/midibox_sid_blm_photos/ Best Regards, Thorsten.

Ok, in this case I'm sure it's an interconnection problem as already assumed by doc. You should try the srio_interconnection_test_v1 to check the control lines to the DIN/DOUT modules. The test procedure is described in main.asm Best Regards, Thorsten.

In the meantime I made some additional experiments, and I think that I will release a last V1 version with CAN support (for PIC18F4685 only) which will include all the communication functions which I will use for MBSID V2 as well. This is to get more experiences about the best protocol handling before I'm starting with V2 Thanks to CAN it doesn't really make a big difference anymore, if the SIDs are connected to the PIC which also handles the CS, or if they are connected to slaves, and accessed from the master remotely. Accordingly, so long only 2x3 SIDs (stereo option) should be used for such a system, just left out the SIDs on the control surface PIC. I've prepared the protocol for up to 127 CAN nodes, but I think that 7 should be the maximum for the internal handling, otherwise it would only be a waste of memory. Makes 1 master + 7 slaves = 16 SIDs ;-) But I want to highlight, that I would never test such a system and cannot guarantee that it will really work. My own configuration is still 1 master, 3 slaves, 8 SIDs Best Regards, Thorsten.

Ok, I see. It could also be useful for myself when I temporary want to disable the loopback in order to control the arpeggiator/transposer directly from a keyboard. Therefore it's implemented now in the new build #69 (F1->PMte) There isn't enough RAM for an effect like the Magic MIDI Delay, and also the complexity of the sequencer engine would kill me - I've already difficulities to add new features w/o looking deeply into the code I programmed months ago... therefore I don't think, that I will add much more complex features, only simple features, into V3 You can send Notes or CCs. Notes will be forwarded to the transposer and arpeggiator, this allows you to realize quite impressing tunes with a small number of patterns (or just with a single pattern set) CC's will be forwarded to the track NRPNs, the Loopback channel correlates to the track number. There is nothing more to say about this, the usage is straightforward. it's the scroll function, it shifts all selected tracks left or right from the step at which you are turning the GP encoder seems that I forgot this combination. From my oppinion it would fit best at the position which is currently used for Note/CC/Len - does anybody use this one? If not, I will replace it A mixer map just allocates a song position, you can dump one or more mixer maps whenever you want, it's part of the sequence. Best Regards, Thorsten.

Build #69 got a new menu page for muting MIDI ports o a new menu page is available which allows to mute the output ports seperately (Def, Int, IIC0-3, AOUT, Loopback). It can be quickly accessed from the Utility page (F1->PMte) [/code]

Thats possible with a small modification in mios_midi.inc, search for "MIOS_MIDI_RxBufferPut" and "prevent overrun" Best Regards, Thorsten.

Am Gameport liegen 5V an, in diesem Fall koenntest Du also auf den 7805 verzichten Gruss, Thorsten.

Yes, it's located in mios_tables.inc, the name is "MIOS_MPROC_EVENT_TABLE", and on matches the USER_MPROC_NotifyFoundEvent function will be called. I must clearly say, that it was a bad idea to add such a feature to MIOS, as most applications need an individual MIDI handling with different data structures. It's also not possible to realize, that a Note Off event will turn into a Note On with velocity=0 w/o duplicating table entries. On the other hand: this is the fastest parser you will find especially for CC's Best Regards, Thorsten.

Two things would be interesting for me: how does the CS behave, when no BankStick is connected? Which BankStick (EEPROM types) are you using exactly, and are there different Chip-Select configurations (Pin #1/#2/#3), so that each BankStick has an individual address? 2: Do you see a "*" marker left to the patch number in the SAV menu? This identifies, that no BankStick has found for the selected bank. Changing Pattern Names: CFG->Nam Best Regards, Thorsten.

So, finally my answers (as I've a little bit more time to read them and to think about a solution) You can already do this by pressing and holding the MUTE button. Now you can select multiple tracks with the GP buttons. All selected tracks will be solo'ed when you activate the SOLO function. I will add a sequencer option for this alternative behaviour sooner or later (not guaranteed to be included into the v3.0, which I'm planning to release soon to get a free head for MBSID V2) MIDI Fx: planned, but not for V3.0, as it will require a lot of programming effort. I'm not sure if I would use this by myself, because most of my synths are voice limited, so that I prefer audio Fx (therefore: low priority) Changed progression: this is already possible by using the Loopback. You can control CC#41, CC#42, CC#43 (see mbseqv3_cc_implementation.txt) from another track. You can use a clock divider on this track to make changes each 16, 32, 64 steps or so.... I want to highlight, that there might be more possibilities available than anybody ever have thought of ;-) It's called "Scrl" (for scroll), as the term "Shift" might be misleading. it's finally available now, after I head to overwork most of the song handling in order to realize such special actions. Therefore it took a little bit longer (it wasn't so simple as expected) Mixer maps can now be dumped within Songs (or Phrases) as well A direct link to patterns is not possible for conceptional reasons (as the content of mixer maps is not directly related to the content of patterns) Best Regards, Thorsten.

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.