TK.

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.

I would propose to compare the number of files and complexity again once a realworld project has been setuped and tested ;-) Is it really required to create so many derivative specific links to the wrapper in the bin/ directory? Why not using a generic keyword for the PIC18F family like "pic16" instead of "pic18fxxxx"? What I'm missing is the possibility to change the stack sizes for main task and interrupts (as the wrapper is located in a prebuild library, it isn't possible to change it via define anymore). Solution: the stack pointers have to be defined via external constants How is it possible to adapt the linker file for application specific locations? How should this be handled for different derivatives? See also http://www.midibox.org/dokuwiki/using_pic18f4620#linker_script How is the version control managed? In long term it can happen, that users release an application which is only qualified for a specific MIOS version, or a specific library element, cmios wrapper or SDCC version. The last one is the most important, as the cmios wrapper implementation heavily depends on the way how SDCC passes parameters. Best Regards, Thorsten.

Maybe another MIDI application allocates the MIDI In port and the interface is not multiclient capable. Ensure that no other MIDI program is running in parallel. Another possibility: the MIDI In port is not connected to the MIOS Studio Out Port - both connections (In/Out) are required for a bidirectional communication. Best Regards, Thorsten.

Hi Carl, I haven't tried the configuration via Sysexbox for a long time, it could be that there are incompatibility issues with newer MIDIO128 releases. I will check this soon. I propose the usage of MIDI-Ox instead. The delay between SysEx blocks has to be configured to ca. 750 mS Thats the expected message so long no MIDI event has been received. The LCD displays the last incoming MIDI event at the upper line, and the outgoing event at the lower line. E.g., when a C-3 Note event with max velocity over channel #1 is received, it should display " 1|Note C-3 127*" Assumed that MIOS and MIDIO128 are still working, and that the LCD displays the startup message, thereafter the MIDI monitor screen: could you please try to upload MIOS while the application is running? The "Wait for upload request" function should be disabled, so that MIOS Studio resets the core automatically and starts the transfer thereafter. Best Regards, Thorsten.

ain64_din128_dout128_v2_0 has to be changed manually. Within the Init() function, you have to add MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_EP); // endpoint or MIOS_MIDI_MergerSet(MIOS_MIDI_MERGER_MBLINK_FP); // forwarding point depending on the position in the chain. It makes sense to get use of the MIDIbox Link approach, it doesn't hurt and it prevents feedback loops Best Regards, Thorsten.

It's better to use different IDs, regardless if the MIDIboxes are chained or connected in parallel. This saves you from uploading the wrong firmware. E.g., one time (after a bootloader update) it happened that I uploaded the MBSID firmware into MBFM, as a result all BankStick were reformatted and all my new patches got lost. :-( The probability for such an handling error is lower, when you have to select the right device ID before uploading a firmware. Another point is, that MIOS reply strings won't be forwarded by a MIDIbox which is assigned to the same ID. So, you wouldn't be able to update a firmware without changing the MIDI cabling. Best Regards, Thorsten.

I think that this is more confusing for experts than for newbies - nobody complained about this yet. It was intended from my side to call even the Vcc inputs Vss just to avoid confusion. And as you can see: more than 8 years it was successful (everybody connected the 74HC165 Vcc input to +5V). Best Regards, Thorsten.

The ML303 community still exists, the forum is located here: http://19642.forendienst.de/index.php They also have an english section :) Best Regards, Thorsten.

Mit dem MIDI-Interface musst Du auch den COM Port nicht mehr verwenden - es ist sowieso die bessere Loesung. ;-) Grss, Thorsten.

I remember that somebody else reported such an issue with 7414 (without HC) some time ago, so I think that this could cause the problem. 74HC14 is more tolerant against CMOS drivers, and your PC board is probably stuffed with such ones. Best Regards, Thorsten.

No, you haven't explained it (see your posting history). I found it strange, because you introduced your controller with a single sentence, and one week later you offered it for selling. But as you've noticed, I gave you an ok anyhow (because based on your posting history I assumed that you are not one of those guys with commercial interests), so no need to feel offended! Best Regards, Thorsten.

I've added a comment to the schematic (you probably need to refresh the browser to see the change). Maybe you haven't noticed this yet, but I'm doing such improvements every time I read that a newbie miss-interpreted a circuit... no need to discuss if it makes sense or not, just write a short comment, thats enough. I won't change the naming to GND and Vcc due to consistency reasons. There are hundreds of schematics, and thousand of PCBs where this CMOS naming style has been used in the past, I don't really see an advantage to change this to another naming style, it only leads to confusion. Best Regards, Thorsten.

With 2-lead Duo LEDs, you will get the second colour Best Regards, Thorsten.

Fine! :) Best Regards, Thorsten.