TK.

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.

For programmers like us this is easy to handle after a short learning phase, especially because these are general concepts which are used by many projects today, so it isn't wasted effort to get familiar with such generic approaches. But IMHO, you still see the whole thing too much from the programmers perspective, and it seems that you expect from every MIOS user (even if he doesn't want to get into this topic, and only wants to change little things to customize the application) to spend some hours or days (maybe also with additional support from the forum) before beeing able to rebuild a .hex file, something which can be done today within a couple of minutes, and without the danger for incompatibility issues. I will give an hypothetical example: (1) Programmer A releases a quite useful library element (2) Programmer B uses this element in his application, his release package only contains his own source code. (3) Programmer A is doing changes in his library element, but Programmer B doesn't find them useful, as they slowdown his application, therefore stays at the old version. (4) Programmer A is doing even more changes. Parameter lists in functions are enhanced, so that the lib can even not be compiled anymore with the app of programmer B (5) after one year, a user has to recompile the application of programmer B. The compiler fails since he only owns the latest lib release (6) after some postings in the forum we find out, that he is using an incompatible release (programmer B wasn't aware of the funky autoconf checks, therefore the user wasn't warned about this) (7) programmer B doesn't respond to emails. With help from the community we find an older library version which could be compatible. Unfortunately the application is slowed down, realtime conditions are not met anymore (see 3.) (8) user is unhappy about his MIDIbox project, since it's so slow and buggy. Nobody can really help him, since only he and unreachable programmer B own exactly the hardware which is required to reconstruct issues. Something what is working quite well in the unix world meanwhile, cannot be 1:1 adapted to a project like MIDIbox. When somebody releases a complex application, he is the only one who can test it with his dedicated hardware for a long time, until other users build the same. Mostly he stays the only programmer who knows how to maintain the project. and he is the only guy who can qualify library changes with his hardware. Instead of beeing able to release a snapshot of all sources he was using during the programming period (like in he current approach), he releases only his own part. If he doesn't consider all the required compatibility checks due to lack of knowledge with the toolchain, and if the external parts he was using are not properly released, nobody will be able to reconstruct the .hex file after one or two years, especially when the programmer is not available anymore. Another issue for which I don't see a solution in your current implementation: how should a common user without programming knowledge recompile different MIDIbox projects which where created at different times (we are speaking about years), and which require different library or SDCC versions? Should he overwrite the /usr/local/mios files each time with older versions whenever he wants to create a new binary, or should he create parallel path structures? At least then we have reached exactly the state as today -> directories with many files... ;-) Sorry for the long posting before christmas (I will make a break as well) - just take it as inspiration for improvements. :) Best Regards, Thorsten.

Great that it is working now (because I had no other explanation for such issues) You can always overwrite an existing application, it isn't required to re-install MIOS The help files have been transfered into the Wiki, so that they are easier to maintain: http://www.midibox.org/dokuwiki/mios_studio and http://www.midibox.org/dokuwiki/using_mios_studio Best Regards, Thorsten.