TK.

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.

Doch, die MBFM unterstuetzt AOUT und AOUT_LC, die Pinbelegung ist auf der MBHP_AOUT Seite beschrieben Wegen des Poti-Problems: evtl. gibt es einen geringen Potentialunterschied zwischen Masse der Potis und Vss (Masse) am PIC. Schliesse die Masse der Potis mal direkt an J5:Vs, das sollte helfen. Gruss, Thorsten.

And with a higher update rate, you can try the "bit angle modulation" concept which is described here: http://www.artisticlicence.com/app%20notes/appnote011.pdf It improves the resolution, and it distance to "normal PWM", the brightness can be controlled in a linear manner. Best Regards, Thorsten.