TK.

Hi Rutger, I can reproduce this, but from my point of view it works like expected. You haven't released the sustain pedal, accordingly all played notes will be held. Especially B: I expect that all notes will be held until the sustain pedal has been released. Once the pedal has been released, only notes should stay active which are still played on the keyboard. Best Regards, Thorsten. Update: this handling is important for arpeggios. On the other hand I see, that for a mono synth it could be more advantageous if the sustain pedal would only ensure that at least one note is played, regardless in which order keys have been released. This behaviour can be easily implemented, but I don't know how to differ between this and the current one (which is important as well) - the high flexibility is a desaster!

Sounds like the SC or RC line is not connected properly. Or maybe the output of SR5 is not connected correctly to the input of SR6 The SRIO interconnection test helps to check the SC/RC lines, see also http://www.midibox.org/dokuwiki/din_module (although the page is named "din_module", it contains some debugging infos for the DOUT module as well) The connection between the O8 output of SR5 and the SER input of SR6 has to be checked visually Best Regards, Thorsten.

A VST wouldn't be helpful for myself - I never got the "SIDControl" VST running with my PC based Logic5 release, and in future I'm planning to use Logic8 on a Mac, where a VST would probably also not work so long MacOS is not explicitely supported? Best Regards, Thorsten.

Looks ok Did you already check the second DOUTX4 module, e.g. with the MIDIO128 application where you can control each individual LED with Note On/Off events? Best Regards, Thorsten.

I think it would be nice to have a SysEx librarian for all MIDIboxes integrated into MIOS Studio, and seperated editors which may use the core components of MIOS Studio, or JSynthLib, or something similar. Best Regards, Thorsten.

Ok, I mixed this with another circuit - let it like it is. Best Regards, Thorsten.

All MIDIbox users have Java installed, otherwise they wouldn't be able to upload code with MIOS Studio ;-) Please consider to use Java, so that MacOS and Linux users are able to execute the application as well. Best Regards, Thorsten.

It's better to generate the sine wave table-based The analog toolbox has some code for this, you can easily create any periodic waveform (just have a look into lfo.c and map.c) Best Regards, Thorsen.

I'm glad that you like it - note that this was the quick&dirty implementation ;-) Last discussion was here: http://www.midibox.org/forum/index.php?topic=9855.0, but I guess that nobody has really started yet It is implemented :) Banks are switched via CC#0 Some synths are sending/receiving bank changes with CC#32 (Bank LSB) instead, maybe this is the reason? Does your keyboard allow you to change the CC number for bank changes? (you can use MIDI-Ox to check the used CC number) currently superpoly is only supported for the lead engines, which means: 4 note polyphony (stereo) with a trick it's possible to play 6 notes with 4 oscillators, in this case the multi engine has to be used (runs on 1 core with 2 SIDs -> 6 oscillators), and it has to be played unisono (so master and slave assigned to the same MIDI channel). But in this case, the capabilities for using the filter are very limited. If you want to get an individual demo: just record some tunes into a MIDI file and send it to me :) Best Regards, Thorsten.

This really helped to understand what is going on - you routed the audio signal through the mixer and VCA stage - in this case it's obvious that the CV inputs for these components have to be supplied. The datasheet says that the voltage range is between 0V and 5V for these inputs, so just take 5V for maximum volume and full-channel B In addition the TL072 based output buffer circuit looks strange, I would expect a resistor between the CEM3378 output and the positive input here. You can take the OPamp stage of the MBHP_OPL3 board as inspiration. I would propose to do the first checks by connecting your amp/mixer or soundcard directly to the VCA or VCF output of CEM3378 10k trimpots: on all CV inputs which are controlled via AOUT module Best Regards, Thorsten.

True words - you don't know, how much trouble I had with computer keyboards in the last days! Currently I've to practice the usage of a Mac keyboard - if you are missing some characters in my postings, you know why ;-) RC8 is available; changes: o there is now a new EXT page within the ensemble menu which contains following options: - F2A (Filter-to-Analog): was previously located in SID menu - V2A (Volume-to-Analog): was previously located in SID menu - Iv1..Iv8: inversion of output voltage at channel #1..#8 [/code] Best Regards, Thorsten.

RC7 is now available with following changes: o possibilities to select a patch: - moving datawheel in main screen (as before) - using Page Up/Down button in main screen and patch main menu - selecting bank and patch in the ENS->SID menu o possibilities to select an ensemble: - pressing MENU + moving datawheel in main screen - using MENU + Page Up/Down button in main screen - using Page Up/Down button in ENS menu o ensemble can now be initialised with preset (-> go into ENS menu, press SHIFT button, select "Ini.Ens" option) Note that Patch and Bank settings won't be touched by this initialisation! [/code] One of the last function I'm planning to add for v2.0 is the possibility to invert AOUT outputs (based on a proposal from Seppoman, it can save external inverters). I think that the best solution is to add 4 * 8 inversion flags into the ensemble configuration, so that they won't be touched when a new patch is selected, and that the firmware doesn't need to be recompiled if the external circuitry is changed. Best Regards, Thorsten.

As I wrote: this was not personally against you, it's just my personal impression about the strange things which happened in the last months. For example: recording MIDI data directly into a BankStick: I could tell you the technical details how to do this within 5 minutes (ok, writing this down into understandable english takes one hour) - the method would even work without RAM buffering, just only a non-blocking IIC handler is required. There are also people who already talked about the usage of a compact flash in this forum, which is the prefered way to go in my eyes for such a high amount of data - especially because you are able to exchange files directly with a PC (when it is stuffed with a card reader) But if we discuss such approaches in the forum to find the best solution, has anybody the right to claim that now this is his own IP? Even if he maybe had the initial idea (or was inspirated from ideas which have been discussed by other people before?). Is anybody still allowed to help you, or would this lead to unwanted complexity when sharing the profit? Best Regards, Thorsten.

(topic splitted, as this is not MBSID V2 specific)

Just 12 hours before Wilba wrote something about this topic: http://www.midibox.org/forum/index.php?topic=9975.msg74560#msg74560 It isn't a SW related issue if the filter don't work. I would propose to check the filter cap connections, the filter cap values, and if this doesn't give you a hint, check the SIDs on an original C64 just to ensure that it isn't related to your MBHP_SID module Best Regards, Thorsten.

It's really difficult to help you when you don't exactly describe, how you've connected the CEM3378. You could draw a schematic to demonstrate, what you did. Maybe this give somebody the right hint what could be wrong. And in addition, it would be a useful documentation for other people who are interested in connecting such a filter chip. It makes sense to start with the highest gain, and the middle offset, and thereafter to reduce these settings until you can sweep over the whole range. Yes, for the fineadjust I used 10k trimpots What do you mean with "if I let them opened"? Did you already connect the additional trimpots, and how? Maybe a wrongly connected trimpot is the reason why it doesn't work? Best Regards, Thorsten.

Thinking that nobody would ever pay more than $500 for an ebay auction is a little bit naive. It always hurts my heart when I see that there are people who are selling even cheaply built and unattractive looking MIDIboxes for a lot of profit. And those people never asked me for permission, which hurts me even more, as the copyrights are clearly stated at many places of my website. I think it would be better for the community if you would sell your MIDIbox via the Fleamarket of this forum. This would be a fair deal, because you will offer it to people who already know the projects (mostly), and it should result into a realistice price w/o profit. To your project: as mentioned in other topics, I don't understand why people are asking for a commercial option before presenting a finished project to the community. This statement is not meant personally against you, I only want to highlight, that something is going wrong when people are only motivated to contribute, when they know that they could earn some money. If this would be my own motivation, the projects wouldn't exist! Therefore my offer for a commercial option is mainly directed to people who have the same spirit like me (and the majority of the community) Best Regards, Thorsten.

And please use smart mode! Even when MIOS has been installed, it could happen that code blocks will be missed or refused due to a bad MIDI connection or a strange working PC Best Regards, Thorsten.

Yes, when I read your description today, it sounds more like a configuration issue. It makes sense to have a proper conditions when debugging this after so many months - means: reinstalling MIOS and the application. I guess that you are using a very old MIOS version, uploading the current MB64 release would crash the core. Therefore just upload the pic18f452/midi/update_with_old_mios.hex of the MIOS update package first, and thereafter the most recent release of MIDIbox64 Thereafter the internal bank should be properly initialized again (btw.: the S in "Snternal Bank" has maybe be changed manually, this can be done in one of the configuration menus...) As doc mentioned, it really makes sense to test all button functions with the ain64_din128_dout128_v1_3 application. Buttons should send notes independent on how the application handles the button events. Best Regards, Thorsten.

The easiest way is to add the code which handles the delay into an existing timer hook. Normaly I'm using the SRIO hooks (USER_SR_Service_Prepare or USER_SR_Service_Finish) for this, as they are called each mS independent from the other timers. Even the names indicate, that they are used for SR operations, you can also use them for other tasks w/o conflicts. Best Regards, Thorsten.

Please read in my first posting, how the encoder handling should be changed Having the alternative to change ensembles with encoder is very useful, I don't know, why you don't like it (however, it doesn't matter - so long you don't press the menu button within the main page, you won't notice it anyhow ;-) Best Regards, Thorsten.

Using PAGE_UP/DOWN buttons in addition is a great idea - it ensures, that users will find an uncomplicated way w/o searching for details in the documentation. Consequently, PAGE_UP/DOWN should select the patch within the "normal" patch menu. Ensemble Init: could be put into the SHIFT page when you are in one of the ENS menu pages as replacement for "Patch Init" Best Regards, Thorsten.

Hi Julien, no problem - the only difference between 6581 and 8580/6582 is the filter calibration range - you can edit this manually within the ensemble for each SID seperately. Recommented range for 6581: 000-FFF, for 8580/6582: 000-600 An auto detection is not possible Best Regards, Thorsten.

Thanks for the hints! and it could add even more confusion if the quality of the select button is so bad, that it double-triggers sometimes (I know that some people are using very cheap miniature buttons with limited debouncing) I like this option, but unfortunately it makes the SHIFT button handling inconsistent, as the SHIFT function speeds up all encoders, not only the datawheel :-/ Best Regards, Thorsten.

Currently the ensemble has to be selected within the ENS menu by moving the datawheel. Normaly the datawheel is used to scroll the menu items The special behaviour of the dataweel within the ENS menu leads to problem, that the 5th menu item of the ENS menu (Save) cannot be selected when only a 2x16 display is connected to MBSID V2. In addition, it doesn't allow me to add more menu items to the ENS menu in future, since this would lead to the same problem for 2x20 displays My proposal is to change the ensemble selection, so that it can be done within the main menu (where ensemble number, patch name, etc... is visible). Within the main screen, the datawheel changes the patch; by pressing SHIFT button in addition patches will be incremented faster. The ensemble could be changed by pressing the MENU button while moving the datawheel. Since this isn't really an intuitive usage, I would like to know, if somebody has an alternative idea. Best Regards, Thorsten.