TK.

Hi Didier, I don't take this as offence, and hope that you don't take it personally when I'm saying, that I still have the impression that you are trying to apply methods evolved in computer world to the embedded world, regardless of the facts that PIC microcontrollers have very limited resources which don't allow to use all those nice programming techniques like soft-configuration, sophisticated APIs, complete modularity, etc... Of course, in small embedded applications your suggested approach will work in it's whole beauty, but once resources should be shared between complex applications created by different people, it won't work anymore, or you will loose so much performance that general programming rules have to be violated again and again (and exceptions make it even more worse). I want to highlight: I'm speaking about projects for 8bit controllers. It's almost the same for 16bit controllers, it has changed for 32bit controllers due to enhanced instruction sets which support C and C++ programming, and the huge amount of memory. I for myself use a totally different programming style on 32bit controllers, which goes into the direction you are suggesting here. Based on my experiences you cannot reach the same performance on 8/16bit controllers with a full modular approach (where sources are completely statically released in libraries) In addition, your approach can only work when program sources are released in a version management system. @Work I'm using Clearcase to share sources with other team members, in open source projects CVS is prefered. Such a system is at least required to make changes smooth, e.g. giving somebody the possibility to incorporate library changes made by other people, and to label/tag a working version. It also gives the possibility for users, to get a released version view with "known working" modules which have been tested by the maintainer (what I called "qualified" release before) I think that it isn't required to give a comment on all your statements. Many of them are true and I know them from other parties as well, I even apply them by myself in other projects. Some others are realstic for MIOS projects, they just don't exist because nobody have implemented them yet. Some others are over-engineered, or just go into the wrong direction, which you will probably notice two or three years later once you made your own experiences with 8bit programming, and especially with the people who are programming! I will give you three examples and I would like to know how you would handle them: 1) http://www.ucapps.de/mios/midibox_lc_v2_0_alpha1.zip: how would you implement the "hard-options" in main.h in a configuration layer without consuming more memory than available on a PIC18F452? Note that the same source code is used to create a .hex for MIDIbox LC and MIDIbox SEQ - two totally different hardware variants, therefore so many #define statements are used. 2) http://www.ucapps.de/mios/midibox64e_v2_2.zip: similar question: how would you handle all the options in setup_*.asm for all the different variations without loosing too much memory? And how much programming effort do you estimate for an additional configuration layer (and tools which handle the configuration) compared by using simple #define statements? Who should maintain the configuration tool? How should the configuration layer be structured, so that it's flexible enough for future expansions? Where should configuration data be stored? In RAM, internal Flash or external EEPROM? (Sidenote: we already had this situation in PIC16F projects - a single firmware and a configuration tool called "vmidibox64" - using #define's was the next step, learned from the limitations and additional efforts of this approach) 3) http://www.ucapps.de/mios/midi_router_v1_1.zip: how would the configuration layer for router.c look like without loosing flexibility. And how would you make a library element of iic_midi.asm without static pin assignments PORT_RI_N_SLAVE_* (again: without loosing too much performance) Best Regards, Thorsten.

...but I think that a workaround is possible. Some SID players don't send the "start" command, which would clear the lower line. I could also clear the line whenever the "LCD" command is sent, under the assumption that this is only done once per song Best Regards, Thorsten.

Hi Karl, yes correct, it's a parameter of the generic MIDI_EVNT_Send routine, which is located in midi_evnt.inc (see the comments there) the configuration data is part of a SysEx stream, and within such a stream it isn't allowed to use values >= 0x80. Therefore I proposed 0x01 (or any other value which you don't use in your configuration). Alternatively you could use meta events - thats a proper solution, but it requires better programming skills. Best Regards, Thorsten.

It's probably a bug in your SID file player Best Regards, Thorsten.

Ha!!! :) FAQMARKER (damit ich den Artikel einfacher wiederfinde) Gruss, Thorsten.

Hi Karl, here is a quick&dirty solution: just overwrite the velocity with the 7bit value of the analog input whenever a MIDI event is sent. In order to differ between "foot controlled", and "hardcoded" velocity, you could use an unused value (like 0x01) to differ between the two modes. Events are sent from the MIDIO_MIDI_SendDINEvent function in midio_midi.inc, it has to be changed the following way: ;; -------------------------------------------------------------------------- ;; This function sends a DIN event ;; Input: number of DIN in MIDIO_CURRENT_DIN ;; -------------------------------------------------------------------------- MIDIO_MIDI_SendDINEvent rcall MIDIO_MIDI_PrepareDINEvent ;; check for velcocity == 1 movf MIDI_EVNT_VALUE, W xorlw 0x01 bnz MIDIO_MIDI_SendDINEvent_NoPot MIDIO_MIDI_SendDINEvent_Pot ;; get current 7bit value of first pot movlw 0 call MIOS_AIN_Pin7bitGet ;; and copy it into MIDI_EVNT_VALUE movwf MIDI_EVNT_VALUE MIDIO_MIDI_SendDINEvent_NoPot ;; if meta event: branch to meta handler, else to MIDI sender movf MIDI_EVNT0, W andlw 0xf0 xorlw 0xf0 skpnz goto MIDIO_META_Handler_DIN goto MIDI_EVNT_Send [/code] Now you only need to enable the AIN handler in USER_Init (-> main.asm) Just add following code below the USER_Init label: [code] USER_Init ;; initialize the AIN driver movlw 1 ; pot call MIOS_AIN_NumberSet call MIOS_AIN_UnMuxed movlw 7 ; +/- 7 is recommented for 7bit values call MIOS_AIN_DeadbandSet Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=10426.0[/iurl]

Great result! :) Best Regards, Thorsten.

I've added the code, it's available in RC15 Unfortunately I had no possibility to check all the new functions with analog synths yet (vacation time...), however the waveforms are looking good on the scope. Channel assignments for K2A and/or O2A + the gates have to be done in setup_*.asm, please read the comments In addition, the appr. function has to be activated in the ENS->EXT menu to get it working If you find the configuration too complicated, just let me know about your usecase. Example Configuration: two analog synth modules should act as two basslines. They don't offer a special glide input, therefore the O2A function is used for a digital glide/slide/portamento function. In addition to the frequency, Filter CutOff, Resonance and Pulsewidth should be modulated from MBSID Recommented Configuration: [tt] #define DEFAULT_J5_FUNCTION 3 #define ENABLE_AOUT <number of your AOUT module: AOUT=1, AOUT_LC=2, AOUT_NG=3> #define DEFAULT_F2A_CUTOFF_L_AOUT 1 #define DEFAULT_F2A_RESONANCE_L_AOUT 2 #define DEFAULT_F2A_CUTOFF_R_AOUT 3 #define DEFAULT_F2A_RESONANCE_R_AOUT 4 #define DEFAULT_P2A_OSC1_L_AOUT 5 #define DEFAULT_P2A_OSC1_R_AOUT 6 #define DEFAULT_O2A_OSC1_L_AOUT 7 #define DEFAULT_O2A_OSC1_R_AOUT 8 #define DEFAULT_GATE_OSC1_L_OUT 1 #define DEFAULT_GATE_OSC1_R_OUT 2 [/tt] Ensure that all other assignments are decactivated (= 0) After the firmware has been uploaded, go into the ENS->EXT menu, and activate F2A, P2A and O2A Adapt the Min/Max range of the filters in ENS->FIL Thereafter store the ensemble Best Regards, Thorsten.

RC15 is now available, from the ChangeLog: o improved FIP function (linear interpolation of filter cutoff) - it is working now the same way as implemented in MIDIbox CV o F2A and V2A flags moved to new storage position in ensemble - old ensemble setups (where F2A and/or V2A was set) have to be adapted! o added new AOUT forwarding functions: - P2A (Pulsewidth-to-AOUT) - K2A (Key-to-AOUT) - O2A (Oscillator Frequency-to-AOUT) Channel assignments have to be adapted in setup_*.asm - all channels are disabled by default o added functions to forward the 6 gates/slide/accent signals to the digital outputs at J5. Assignments have to be configured in the setup_*.asm file. Note that DEFAULT_J5_FUNCTION has to be set to 3 in order to enable the digital output function of CORE:J5 [/code] Best Regards, Thorsten.

This seems to be an error in the PCB silkscreening, the labels which can be found in the original schematics are still valid, and it doesn't make sense to change them. Best Regards, Thorsten.

Why should I repeat something what I did 20 years ago? -> http://utenti.lycos.it/ice00/HVMEC/CONTROL/Tracker/Soundwriter/v2.0/index.html However, PCM playback has ultra-low priority - just for the case that I feel boring ;-) Best Regards, Thorsten.

Good input! I suggested this MIDI interface multiple times in the past, good to know that it works reliable :) Best Regards, Thorsten.

(contacted via email) Best Regards, Thorsten.

Just remove the "#if/#endif" below the USER_ENC_NotifyChange label in main.asm, remove it in mios_tables.inc as well and adapt the encoder entry Best Regards, Thorsten.

Hi, no, the voltage range is calibrated on a different way: c-1 outputs 1V, C-0 2V, C-1 3V, C-2 4V, C-3 5V, etc... So, just play a sequence with C-0 notes, turn the trimpot until 2V will be output, thereafter play C-3, check that the voltage is 5V, play C-0 again, check that the voltage is still 2V... iterate until you are satisfied with the result :) Best Regards, Thorsten.

Hi Ricardo, the frequency mapping can be changed in mbfm_frq_table.inc and mbfm_frq_table_alt.inc - the values have been calculated with the utils/frqtab.pl script. The frequency factor (49715.0) is based on the formula fs=FM/288 of the datasheet, it needs to be adapted (for 16 MHz -> 55555.5) Best Regards, Thorsten.

Thats due to historical reasons. It doesn't hurt when you connect this one on a mbhp_sid_v3 module The first select button should change to the ensemble menu. I would propose to follow the debug instructions on this page: http://www.midibox.org/dokuwiki/din_module Best Regards, Thorsten.

Yes, the ADSR will always raise the VCA to max volume before going into the decay phase. This causes the popping sound. This doesn't really help. Regardless of which method you are using (e.g. clearing waveform register during attack phase), you will always hear unwanted artefacts. However, maybe the filter helps to lower the volume of certain channels. C64 composers had to fight with the same issues, there is no satisfying solution beside of recording and mixing the oscillators seperately, or using more than one SID Best Regards, Thorsten.

Hi Anakin, Thats correct, all MIDI messages which are not tunneled won't be forwarded by an endpoint. You haven't mentioned, that you also want to forward MIDI events of a HW merger - this would only work if the merger is connected *after* the endpoint. Yes, you can ignore this message, it's used as indicator for tunneled events (I misuse an unused event of the MIDI protocol here, but it doesn't hurt). No, the merger project is not prepared for MIDIbox Link. I think that there are two solutions: either disable MIDIbox Link (only enable the merger, don't declare cores as FP or EP) - disadvantage: feedback loop of your MIDI software forwards incoming MIDI events as well - or connect the MIDI merger at the end of the chain. Best Regards, Thorsten.

Hi, fixing the pots is easy: since no AIN multiplexers are connected, you need to set DEFAULT_MUX_ENABLED to 0, otherwise a single pot will send the events of 8 AIN channels. Meta events: it isn't possible to use the learn function for this, instead it is required to adapt the mb64_meta.inc file for your needs. The described SysEx string can be found under the META_Send_AN1x_SysEx label, just modify this one, and the MB64_META_Handler_00/01/02/.. handlers in addition (the comments should say it all). As you were able to send a single meta event, just configure the other ones like you did for the first one. Meta events can be assigned to pots/buttons with vmidibox64 (more comfortable), or the mk_syx script (more flexible) Best Regards, Thorsten.

Sounds like core 3 and 4 are running with an older MIOS version. As stated in the release notes, MIOS V1.9f is required to clock the BPM generator properly. By using the cloning mechanism you can ensure that all cores are running with the same firmware. It's also faster and more secure than using MIDI. But MIOS cannot be updated this way. I would propose to plug the slave PICs into the master socket, and update from there. Advantages: you don't need to change the MIDI wiring, and you can doublecheck the MIOS release message on the LCD Note that this procedure is only required for the MIOS update! (and I guess that there won't be big changes in future, so that this only need to be done once) After this update, you have to upload the MBSID firmware as well - one time! (so that CAN is serviced again) Thereafter you can always use the cloning mechanism via CAN to update the firmware on the slaves. Best Regards, Thorsten.

Does anybody remember the worldwide blackout back in March 1969? Best Regards, Thorsten.

I already considered this, but at the end I came to the conclusion that standard IDs for different applications would only reduce the flexibility. For example, for MIOS uploads it is required to use the same SysEx header, only the device ID makes the difference. But what, if somebody runs two or more MIDIboxes with the same firmware? So, an additional ID would be required anyhow. For configuration data (e.g. MB64 setup, MBFM/MBSID patches, MBSEQ sequences) I'm using a different header, so here we have a clear differentation. A SysEx ID change to a dedicated (confirmed) MIDIbox SysEx ID sounds attractive, but a lot of firmwares and tools would have to be changed. I'm not sure if this is worth the effort... Best Regards, Thorsten.

It would cost me more time to describe the required changes, than doing them by myself (expected effort: ca. 30 minutes) I'm planning to integrate the K2A options this weekend, and test them with the analog synths of a friend to ensure that they are working perfectly before releasing any unusable code. Best Regards, Thorsten.