TK.

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:

Hi Joente, the application has to send a note-off event for the previous note, before the new note is sent. So long the last pot value is stored (this is the case for MB64 for example), the realization of such a feature isn't a big problem. Which application are you using (selfwritten or official MBxx release?) Best Regards, Thorsten.

Thank you for checking this! I still haven't an idea, why the segment pins are reversed, but I will doublecheck this with my own LED digit module soon Best Regards, Thorsten.

thank you! You just have financed the LCD for my next MIDIbox :) Best Regards, Thorsten.

Just one month ago I tried some fresh 18F4620 and 18F4520 samples - they still have the EUSART bug. In the meantime it turned out, that not only the transmitter is affected, but also the receiver (sometimes it gets a frame error). Especially the fails on the 18F4520 prove that this is no configuration problem, since this device is 1:1 hard-and software compatible to the 18F452, where the Bootloader and MIOS are running pretty stable. I gave it up to inform the Microchip support about this issue. I tried it three times, each time I was handled like a newbie, or they confirmed the bug and gave me suggestions which are just totally useless. E.g. one suggestion was, that the transmitting routine has to turn off and on the serial transceiver after each transfer - with the result, that continuous back-to-back transfers are not possible anymore, and that incoming data will be corrupted (no full-duplex anymore). So - don't buy any PIC which includes the EUSART, it won't work with MIDI. Once Microchip releases new chip revisions, I will try it again. Best Regards, Thorsten.

Everything which is possible concerning encoder sampling is already part of MIOS, I really don't know what else could be optimized... How does he achieve 72 pulses with this encoder? What does he understand under doubling? (I want to see the waveforms...) Best Regards, Thorsten.

Could you please ask him, how he did this? (Can he also turn water into wine? ;-) I've no idea how it is possible to create 4 ticks from 3 (or less) transients this would just only left out some ticks (see the .gif file) If KDJ tells you how he realized this? If he has just only used an acceleration detection, then you can do the same by configuring MIOS_ENC_SpeedSet in fast mode Best Regards, Thorsten.

I'm very sure that the algorithm I've developed works correctly, but it depends on the hardware (encoder) if it's possible to quadruple the resolution or not. So, before we continue the discussion, it would be useful to know, if your encoder always sends a single MIDI event on a "tick" (use the MIDIO128 application to determine this), or if it can happen that two MIDI events are sent at the same time. If this is the case, then the quadrature encoded waveforms of your encoder are not like in the mios_encoder_modes.gif, and this means that there is no way for the software to make 4 steps of 1 Best Regards, Thorsten.

Hi, either you've selected a certain speed mode which slows down the encoder (which application are you using?), or after the changes in mios_tables.inc you forgot to re-build the application? Do you notice any change with different encoder types? Btw.: you could use the debug window of MIOS-Studio in order to change the Speed mode on-the-fly (but not the encoder type...) - the appr. function is called http://www.ucapps.de/mios_fun.html#MIOS_ENC_SpeedSet Best Regards, Thorsten.

You could upload the MIDIO128 application and count the number of MIDI events per revolution. Each Note On/Off has to be counted as one pulse Best Regards, Thorsten.

Hi Jeroen, it depends on the encoder type you've selected in mios_tables.inc, see also http://www.ucapps.de/mios/mios_encoder_modes.gif So, only with a non-detented encoder a quadrupled resolution can be achieved Best Regards, Thorsten.

Hi Nico, Donations to j.laan10(at)quicknet.nl are going to TwinX (who pays the MIDIbox server), Donations which are done at https://sourceforge.net/project/project_donations.php?group_id=95206 are going to me Best Regards, Thorsten.

Hi, thats really strange, because based on the source code the schematic and the LC_LEDDIGITS_TABLE are matching. Could you please write down the exact pin mapping that you are using now, maybe this help me to find the inconsistency. Following format is sufficient (just edit it): J3:D7 -> Blue dot J3:D6 -> Blue a J3:D5 -> Blue b J3:D4 -> Blue c J3:D3 -> Blue d J3:D2 -> Blue e J3:D1 -> Blue f J3:D0 -> Blue g J4:D7 -> 3rd digit J4:D6 -> 4th digit J4:D5 -> 5th digit J4:D4 -> 6th digit J4:D3 -> 7th digit J4:D2 -> 8th digit J4:D1 -> 9th digit J4:D0 -> 10th digit J5:D7 -> Green dot J5:D6 -> Green a J5:D5 -> Green b J5:D4 -> Green c J5:D3 -> Green d J5:D2 -> Green e J5:D1 -> Green f J5:D0 -> Green g J6:D7 -> left status digit J6:D6 -> right status digit J6:D1 -> 1st digit J6:D0 -> 2nd digit Best Regards, Thorsten.

Duggle sent me a beta version some months ago, it works fine! Best Regards, Thorsten.

Is this question related to this topic? http://www.midibox.org/forum/index.php?topic=5800.0 As mentioned in this posting, there was a small error in the schematic (normaly very obvious, therefore propably nobody ever noticed this before ;-) --- did you take this into account? Best Regards, Thorsten.

As previously mentioned, there was a mistake in the schematic, did you take this into account? Best Regards, Thorsten.

Thank you guys! :) Nico: I just have shifted the priority of this feature to the top of the ToDo list, so that it won't be forgotten - yes, it's possible without much changes (some functions have already been prepared) Best Regards, Thorsten.

Hi *, I just have released a new version of MIDIbox SEQ, it features an external 24ppqn pin and "Multi-Arp" events. Download: http://www.ucapps.de/mios_download.html ChangeLog: http://www.ucapps.de/midibox_seq_changelog.html There is also a new tutorial session which describes the Arp enhancements: http://www.ucapps.de/midibox_seq_tutorial4.html Have fun! :) Best Regards, Thorsten.

Check the MIDI channel and the selected patch... Best Regards, Thorsten.