TK.

So, everything seems to be on place. Are you working with Win98 or WinME? Then it might be useful to add the PATH extensions into the C:\AUTOEXEC.BAT file, and to reboot the PC Best Regards, Thorsten.

Ich halte es fuer sehr unwahrscheinlich, dass der PIC defekt ist. Die Analyse muss systematisch angegangen werden, deshalb mein Vorschlag, zunaechst einmal die MIDIO128 Applikation aufzuladen, um eine "Bestandsaufnahme" zu machen Gruss, Thorsten.

das geht uebrigens wie hier beschrieben: http://www.midibox.org/forum/index.php?topic=2701.0 Gruss, Thorsten.

Excellent! :-) Best Regards, Thorsten.

Hi George, how many shift registers are enabled by the application? The number is normaly set with MIOS_SRIO_NumberSet It's save to set it to 16 (max value) Best Regards, Thorsten.

Hi, note this error message: [tt] e:\miosc\sdcc\bin\sdcpp.exe: eg.c: No such file or directory [/tt] [tt] e:\miosc\sdcc\bin\sdcpp.exe: mclock.c: No such file or directory [/tt] how and from where are you starting the make.bat? Best Regards, Thorsten.

I don't think that this UI will be enough to meet all requirements. E.g., in MIDIbox-SID, some bitfields within the CC value needs to be handled seperately for good results. It will get even more complicated, once a wavetable patch should be generated. Supporting SysEx is a must, because most synthesizers don't provide a way to edit all sound parameters via CC. However, today I've migrated the perl based random patch generator to C, it can be found here: http://www.midibox.org/forum/index.php?topic=5864.0 This application gives perhaps a good basis for your experiments with a user interface. Best Regards, Thorsten.

For those who feel bored on those dark winter days. This application is just the port of the mk_sid_random.pl script (and TL's patch manager) - if you don't want to use these comfortable PC based programs, but if you are searching for a standalone solution, then this application could be interesting for you: [tt] sid_random V1.0 © 2005 Thorsten Klose (tk@midibox.org) =============================================================================== This application generates random patches for the MIDIbox SID It just requires one core module, a button to "fire" the random patch, and a "true random generator", e.g. based on http://willware.net:8080/hw-rng.html The random generator has to be connected to pin RA0 of the core module (J5:A0) The button to pin RC3 (J6:SI) - a pull-up resistor is already installed there. The MIDI merger is enabled by default, this allows you to connect the random generator between a keyboard/PC and your MIDIbox SID. The additional latency is about 300..400 uS Random constraints can be edited in sid_random.c =============================================================================== A precompiled binary is already part of this package: o project.hex (can be loaded into MIOS Studio) o project.syx (can be loaded into any SysEx upload tool) Following tools are required to recompile the code: o SDCC v2.5.0 o gputils o perl The details are described under http://www.ucapps.de/mios_c.html =============================================================================== Required hardware: o one MBHP_CORE module o one button connected to pin RC3 of the PIC Optional hardware: o random patch will also be generated when any button of a DINX4 module has been pressed =============================================================================== Configuration steps: o check the "general application settings" in main.h if changes are required for your hardware setup (e.g., if no AINX4 multiplexers are connected to the core) o the application can be rebuilt with the "make.bat" file (type "make" in a DOS command shell) o Hint: unused analog inputs must be tied to ground, otherwise the core will transmit a lot of random CC events =============================================================================== Description about the most important files: - mios_wrapper\mios_wrapper.asm and mios_wrapper\mios_tables.inc: The MIOS wrapper code and MIOS specific configuration tables - pic18f452.c: exports PIC18F452 specific SFRs - main.c: the main program with all MIOS hooks - sid_random.c: generates the random patch There are additional .h files for all .c files which contain general definitions and the declaration of global functions/variables These .h files must be included into the program parts which get use of these globals =============================================================================== [/tt] Download: http://www.ucapps.de/mios_download.html Have fun! Best Regards, Thorsten.

To the question "TK - ever considered the VCA leak "fix"? by stopping the OSCs?": yes, I've considered this, but there is no perfect solution, therefore I never spent effort for a workaround and prefered to work on other features. Even your solution is not perfect as you've already noticed, but if you can live with side effects, then you are free to give it a try. So, the waveform has to be changed once the release time of the DCA has been passed. The release time can be derived from the SID_Vx_ENV_SR register (x=1..3). According to the SID datasheet, the highest release rate is 24 s (when the release value is 15). If your timer is part of the SID_SW timer (sid_sw.inc), then the delay counter must have a resolution of 15 bit (24 / 819.2E-6 = 29296). Each voice needs its own delay counter. It can be preloaded in SIDSW_Note_GateClrReq, and decremented at the end of SIDSW_Note so long the gate bit is not set (can be determined with the SID_MODE_GATE_ACTIVE flag) Once the delay counter has reached zero, the SID_SR handler in sid_sr.inc needs to be notified with a flag (for each voice seperately). If this flag is set, you can upload the new value into the control register with: movlw 0x<new-wave-value> movlw 0xe4 ; SID_V1_CTRL (note: reset line must stay 1) movwf MIOS_PARAMETER1 ; address call SID_SR_Write [/code] Value for SID_V2_CTRL: 0x0b Value for SID_V3_CTRL: 0x0c Coding of the control register: see SID datasheet An alternative solution would be to add an external gate like proposed by KD: http://www.midibox.org/forum/index.php?topic=4075.0 Best Regards, Thorsten.

Mir kommt das auch ein wenig seltsam vor. An der Software kann es nicht liegen, aus der Beschreibung geht zumindest nicht hervor, dass die Applikation modifiziert wurde. Warum sollte gerade die Button-Behandlung ploetzlich nicht mehr funktionieren? Gefuehlsmaessig kann es sich nur um ein Hardwareproblem handeln. Von der Hardwareseite her gesehen finde ich es seltsam, dass der Encoder funktioniert! Daraus folgt, dass zumindest zwei digitale Eingaenge erfolgreich eingelesen werden, und somit die Verbindungen zwischen Core und DIN Modul intakt sind. Waere die SCLK oder RCLK Leitung defekt (Kurzschluss oder kalte Loetstelle), so wuerde nur ein Pin (D7) funktionieren. Hinzu kommt, dass der 74HC165 bereits ausgewechselt wurde. Auch die Spannungen scheinen korrekt zu sein (der 74HC165 arbeitet auch noch bei 4.5V) - eigentlich *muessen* die Buttons einfach funktionieren. Koenntest Du mal die MIDIO128 Applikation aufladen? Welche MIDI Events werden gesendet, wenn Du am Encoder drehst/auf die Taster drueckst? Gruss, Thorsten.

Random: The challenge is to find an erconomic user interface - this doesn't require programming skills, just only the right intuition at the right time. So: how should parameters (CC/SysEx) be specified, how should the constraints be entered? How many buttons and encoders are ergonomical enough? Compare it with the already existing PC based solution - will it really make more fun? Is it really worth the effort? Morphing: I'm normaly using the MB64E for such experiments... Best Regards, Thorsten.

A serious random function requires constrainable parameters, and this would blow the memory consumption of MBSID (and MBFM) too much. Also the menu interface would be very complicated. Note that the PIC18F452 contains only 32k of flash memory! However, the perl scripts as well as TL's patch manager allow you to generate a single --> constrainted! <-- random patch, as well as a whole bank of 128 random patches on-the-fly. The results are great, and you are able to change the constraints in order to force the results into a certain direction. This leads to very serious random patches, much better than you know from those freeware synths, it's even better than the random function of the Yamaha AN1x! It seems that nearly nobody has notified this "hidden treasure" yet? Just check the examples: http://www.midibox.org/midibox_sid/mbsid_demo_random_patches.mp3 http://www.midibox.org/midibox_fm/mbfm_demo_random_patches.mp3 Best Regards, Thorsten.

Here comes the next great MIDIbox SEQ design: Michael wrote: I asked him for the source of the rectangular buttons, they are from www.segor.de

Hi Joente, could you please do me a favour and describe, what is wrong with the make.bat? Which messages are print out? (I would like to improve the documentation) Best Regards, Thorsten.

You could map the analog value to a new value, similar to the way how it is done in analog_toolbox. But in general the results won't be good enough for serious work, because you will miss some values! Best Regards, Thorsten.

Hi, the ground area is not visible by default - it will be visible once you type the "rats" ("ratsnest") command. Changing diameters: type the "change" command Best Regards, Thorsten.

In short: C7 is configured as MIDI In, you can use it as common GPIO pin by removing the access to RCSTA in init.inc Shift register processing: possibily the registers are not shifted often enough? Check the loop counter Best Regards, Thorsten.

Unfortunately these devices are still not available, I'm waiting for a customer release since months... I guess that the PIC24HJ256GP206 or PIC24HJ256GP210 would be a nice successor of the PIC18F based MBHP, but there are also drawbacks: SMD package and 3.3V techology... (it will cost some additional hardware to interface a common LCD) However, a MIDIbox SID and MIDIbox FM with a 16bit controller would open a lot of new possibilities, but I fear that we have to wait months or years until this dream comes true! Best Regards, Thorsten.

Hi Joente, nice to hear that it works! :) No, there isn't a tutorial available yet. Currently I'm trying to focus on C based examples, since they are easier to handle for people who are not so much into assembly programming and the MB64 application. I think, that the benefit is higher. E.g., there is a ain64_din128_dout128_v2_0 template available, which is preconfigured for up to 64 pots, 128 buttons, 128 LEDs. MIDI events have to be customized in the program itself, and such special behaviours like for your theremin can be realized with much less lines of code. So, here the same in C (the AIN_NotifyChange function can be found in main.c) // global variable which is declared at the top of main.c: unsigned char thermin_value; ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { // thermin is connected to pin #0 if( pin == 0 ) { // send Note Off at channel 1 for last value MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(thermin_value); MIOS_MIDI_TxBufferPut(0x00); // send Note On at channel 1 for new value thermin_value = MIOS_AIN_Pin7bitGet(pin); // don't use 10bit pin_value, but 7bit value MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(thermin_value); MIOS_MIDI_TxBufferPut(0x7f); } else { // do anything else with the other AIN pins } // notify display handler in DISPLAY_Tick() that AIN value has changed last_ain_pin = pin; app_flags.DISPLAY_UPDATE_REQ = 1; } [/code] With this code, modifications should be much easier. E.g., with following extension: [code] // thermin is connected to pin #0 if( pin == 0 ) { // send Note Off if Thermin value is valid if( thermin_value != 0xff ) { MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(thermin_value); MIOS_MIDI_TxBufferPut(0x00); } // only send Note On when Button DIN#0 is pressed if( MIOS_DIN_PinGet(0) == 0 ) { // button value is 0 when pressed // send Note On at channel 1 for new value thermin_value = MIOS_AIN_Pin7bitGet(pin); // don't use 10bit pin_value, but 7bit value MIOS_MIDI_TxBufferPut(0x90); MIOS_MIDI_TxBufferPut(thermin_value); MIOS_MIDI_TxBufferPut(0x7f); } else { // invalidate thermin value, so that no additional note off's will be sent thermin_value = 0xff; } } else { // do anything else with the other AIN pins } Note On's will only be sent when the pedal is pressed, and Note Off's will only be when really required Best Regards, Thorsten.

I still cannot figure out why the second SID should be silent in this case, regardless how many times I ready your description. Either you forgot to mention an important point, or your temporary wiring is not doing what it should. Normaly there is no trick behind these buttons. Especially when you've stuffed the (strongly suggested) LINK and SIDx LEDs, so that it is very clear, when a certain function is selected or not (read above, why I decided to realize this in this way and why I don't provide alternatives) To sumarize the functions: the LINK button enables the MIDI merger, so that incoming MIDI events to the master are merged with internal generated events. Both streams are forwarded to the slave - there is no filter mechanism, no trick behind this... the function should be really obvious This means, that once LINK is enabled, the slaves will receive everything which is sent to the master. It works like if you would send it directly to the slaves (and not through the master). SIDx buttons: they are used to tell the control surface, which SID(s) should receive parameter changes. This is not related to the incoming MIDI stream, therefore I've absolutely no idea, why "it" (what exactly?) should work when both SIDs are selected. Could you please doublecheck, if the slave SID still works when your PC (or keyboards) is directly connected to the MIDI In of the slave, like you've tested it before? If this still doesn't work, could you please try to explain the problem in different words? I've a SID which behaves similar - filter is nearly not working, output is distorted. It's a MOS6581 4084 (CW 40/84) - I guess it's an production error, 84 seems to be a bad year... There are "good" SIDs and "bad" SIDs. Maybe different caps at Pin 1-4 could improve the sound a little, but in general these chips just got some damage over the past 20 years... it's analog stuff! Best Regards, Thorsten.

Hi Robin, it's better to re-write this in C, because this improves the flexibility. Yes, the long table is just an constant array, all the pointer calculation stuff will be done by the compiler. In general the code looks like this: const unsigned int dump_table[] = { // BS Addr Count 0x0000, 0x0000, 0x04d4 - 1, 0x0000, 0x04d4, 0x04d4 - 1, // etc... }; void SendDump(unsigned char dump_index) { unsigned int addr = dump_table[dump_index*3 + 1]; unsigned int count = dump_table[dump_index*3 + 2]; MIOS_BANKSTICK_CtrlSet((unsigned char)dump_table[dump_index*3 + 0]); // converted int -> char do { __asm clrwdt __endasm; MIOS_MIDI_TxBufferPut(MIOS_BANKSTICK_Read(addr++)); } while( count-- ); } [/code] As you can see, the special clrwdt instruction has to be inserted inside a __asm block Best Regards, Thorsten.

From the README.txt [tt] DIN Velocity UnMuxed V1.0 © 2005 Thorsten Klose (tk@midibox.org) =============================================================================== This application can be used to do some experiments with "velocity buttons" The buttons must provide three contacts: one contact, which is closed with the "middle pin" when the button is pressed, and another contact, which is closed with the "middle pin" when the button is depressed. Such buttons are mostly called "On-(On) pushbuttons", "push-push momentary buttons" or "SPDT buttons (Single Push, Double Throw). The outer contacts have to be connected to a pair of two digital input pins of a DINX4 module, the middle contact to ground. See also http://www.ucapps.de/mios/din_velocity_unmuxed.pdf Note that this application is not able to scan a keyboard matrix, but it could be useful to realize some simple drumpads Velocity measuring works in the following way: so long the "depressed" contact is closed, a velocity counter is preloaded with 127 Once it is released, this counter will be decremented each millisecond until the "pressed" contact is closed (see din_vel.c, DIN_VEL_Tick()) The measured delay will be scaled to the velocity value (see DIN_VEL_NotifyToggle()) The scaling can be changed in din_vel.c, velocity_table[] Currently this table contains an exponential scaling which has been generated with utils\velocity_table.pl Depending on the button you are using a modification of this table might lead to better results. By default 16 buttons are handled by the application, this number can be increased to up to 64 in din_vel.h =============================================================================== A precompiled binary is already part of this package: o project.hex (can be loaded into MIOS Studio) o project.syx (can be loaded into any SysEx upload tool) Following tools are required to recompile the code: o SDCC v2.5.0 o gputils o perl The details are described under http://www.ucapps.de/mios_c.html =============================================================================== Required hardware: o one MBHP_CORE module o at least one DINX4 module for 16 push-push buttons Optional hardware: o up to 4 DINX4 modules for up to 64 push-push buttons o a 2x16 LCD =============================================================================== Configuration steps: o check the "general application settings" in main.h if changes are required for your hardware setup (e.g., number of shift registers) o check the "DIN velocity settings" in din_vel.h o the application can be rebuilt with the "make.bat" file (type "make" in a DOS command shell) =============================================================================== Description about the most important files: - mios_wrapper\mios_wrapper.asm and mios_wrapper\mios_tables.inc: The MIOS wrapper code and MIOS specific configuration tables - pic18f452.c: exports PIC18F452 specific SFRs - main.c: the main program with all MIOS hooks - din_vel.c: the velocity handler - utils\velocity_table.pl: has been used to generate the scaling table There are additional .h files for all .c files which contain general definitions and the declaration of global functions/variables These .h files must be included into the program parts which get use of these globals =============================================================================== [/tt] Download: http://www.ucapps.de/mios_download.html Interconnections: http://www.ucapps.de/mios/din_velocity_unmuxed.pdf Have fun! :) Best Regards, Thorsten.

Amazing, these are true micro tunes! When can we expect the first CD release? :) Best Regards, Thorsten.

Ok, I will give you a short hint which should help for the first experiments, but to make it clear: I won't implement the complete solution. This is on your side (I made the experience, that than more complete solutions I publish here, than more people are asking for even more - this just consumes too much time at my side and prevents the people from learning about how to do this by themself) So - just open mb64_meta.inc and program a Meta Event which sends Note Off/Note Ons, where the note number if controlled from the pot value: MB64_META_Handler ;; Meta Event Fx 00: send Note Off for last value, Note On for new value movlw 0x00 IFNEQ MIDI_EVNT1, ACCESS, rgoto MB64_META_Handler_NotFx00 MB64_META_Handler_Fx00 ;; send Note Off, channel number defined in Fx (right digit) movf MIDI_EVNT0, W andlw 0x0f iorlw 0x90 movwf MIDI_EVNT0 movff MB64_POT_LAST_VALUE, MIDI_EVNT1 clrf MIDI_EVNT_VALUE ; (velocity == 0 -> note off) call MIDI_EVNT_Send ;; send Note On with new value movff MB64_POT_NEW_VALUE, MIDI_EVNT1 movlw 0x7f movwf MIDI_EVNT_VALUE ; (velocity == 0x7f: max) goto MIDI_EVNT_Send MB64_META_Handler_NotFx00 ;; here you could define 126 additional meta events return [/code] (I haven't tried the code - if it doesn't work, it must be a syntax or even more stupid error, but in principle it will work) I guess that you want to gate the Note events with a pedal. This requires a second Meta event which has to be assigned to a button input. This meta event has to switch a flag which identifies the current button status. You have to define a new variable in app_defines.inc, and you have to store this flag there. In addition, this meta event has to send a Note Off if the pedal is released. Problem here: MB64_POT_LAST_VALUE contains the last value of the pot which has been moved the last time. If this wasn't your theremin, then it will contain an invalid information. Therefore the Meta handler F000 should store the new value which has been used to send a note on in an additional variable (-> also has to be defined in app_defines.h), and this can be used in meta handler F001 (assigned to the pedal) to send a note off Hope this helps. If you find assembly programming too difficult, then just try the MIOS C Wrapper first. Once the algorithm is working, you can port it to assembler. Best Regards, Thorsten.

A nice looking MIDIbox SEQ in a desktop case! :) mr_chombee wrote: