TK.

Sorry, I can't help here, I'm not a Windows user. Best Regards, Thorsten.

There wasn't an issue with Microchip EEPROMs (24LC), but with others so far I remember. Best Regards, Thorsten.

Hi, To read the tutorials step by step: http://www.ucapps.de/mios32_c.html We are using different toolchains, they depend on the OS (Windows/Mac/Linux). It's explained in the MEMO You won't get in touch with FreeRTOS so long you don't want to start timed/independent tasks. The big advantage of FreeRTOS is the preemptive multitasking and synchronisation mechanisms (mutex) - if you don't see an advantage with such methods (as explained in the tutorials), just ignore them. But I wouldn't program an application without the provided features anymore. If you want to see the differences, just compare the PIC assembly based MBSEQ V3 code with MBSEQ V4. Check especially how difficult it was to run slow LCD output "in parallel" with timing critical MIDI output - no problem with a RTOS I gave you access to the hidden programmers section. Best Regards, Thorsten.

Hi, I've enabled the "brown out" reset circuit and set it to 4.5V to ensure that the PIC will be reset if the voltage drops below this level. This ensures (for example) that IIC EEPROMs (BankSticks) are only accessed under proper working conditions - with lower voltages data stored in a BankStick could be unintentionally erased or overwritten. So long you are not using devices which rely on this voltage, you can disable the Brown Out reset feature - this can only be done with a PIC programmer (see options screen of your PIC programming software) Best Regards, Thorsten.

Thats a nice idea! :) Do you have C++ knowledge? I could prepare an empty stub for a new MIOS Studio 2 tool where you could insert your code. Advantages: proven MIDI handling, platform independence, and reusable for similar tools in future. Best Regards, Thorsten.

Please write a separate announcement in this section, I will make it sticky. Best Regards, Thorsten.

It's explained in the CHANGELOG and in the src/sid_filter_table.inc file - what detail are you missing? Best Regards, Thorsten.

The filter calibration table is now part of RC36 (yes, I know that it's cumbersome to find the best matching values, since the firmware will be reseted after each .hex file upload...) I avoided to call this effect NMFP ;) Best Regards, Thorsten.

RC36: o Bassline engine: detune parameter now mapped to Parameter #003 o a table based calibration table is now provided for the SID filter. It has to be adapted under src/sid_filter_table.inc and can either be uploaded together with the firmware build, or separately if by uploading "sid_filter_table.hex" after the "make" command (type "make sid_filter_table" to build only this file) The table can be used to compensate technology related non-linearities of the 6581 R-2R DAC o various minor bugfixes [/code] Best Regards, Thorsten.

No, thats wrong. If the descriptions in the MBSEQ V4 manual are not sufficient, have a look into this (expired) tutorial for V2: http://www.ucapps.de/midibox_seq_tutorial1.html You could help me to find an explanation which is better understandable for people who never worked with such an arpeggiator mechanism before. Best Regards, Thorsten.

I tried USB1 and IN1 Did you ever use the arpeggiator? I mean: do you know how it is working? Best Regards, Thorsten.

There is no STM32F105 derivative (which allows to use CAN and USB in parallel) with 512k flash available yet, therefore it can take a year until a complete solution is possible. On the other hand I will be able to prepare the firmwares until then on a STM32F103, but either w/o USB or w/o CAN... Java: yes, JSynthLib is incomaptible to the latest (buggy) Java changes done by Apple. Best Regards, Thorsten.

This is a very interesting page: http://www.bel.fi/~alankila/c64-sw/index-cpp.html (btw.: wouldn't it be nice to use the improved filter models for the MBSID V3 VST/AU emulation? :) It gave me the keyword R-2R ladder DAC. As you can read in Wikipedia: I don't think that the Rs were laser-trimmed in those years ;) So, how to solve this: I could add a fast accessible calibration table so that the "bad steps" can be excluded or smoothed out. It would consume 4k (not sure if so much is still available), but everybody would have to adapt it manually for his SID by editing the table and rebuilding the application. Best Regards, Thorsten.

Now I tested it with a 6581 marked with 2584, another one marked with 4084 Both have a different filter response - but the interesting point: with both chips I can hear this unbalanced step as well (on the 4084 much more noticable than on a 2584) Time to search in the internet for similar observations. Best Regards, Thorsten.

Btw.: are your 6581's from the same batch, resp. produced at the same time? Best Regards, Thorsten.

It won't help to bring the voltage even closer to 12V For me this case is open until anybody else was able to reproduce this - as mentioned above, it's easy to verify that the software writes the correct values into SID registers. It could make sense to check this with 8580 or 6582 if available (but this will require to change the voltage/filter caps) Best Regards, Thorsten.

Thats an intensive effect and I cannot believe that nobody discovered this before (I wasn't able to reproduce this) For me it sounds like the internal SID filter stage isn't balanced This can happen if the 6581 is supplied with a voltage (much) lower than 12V, e.g. 9V - or if you are using the wrong (or unequal) filter caps Please check this first. If you want to check the software, you could read out the filter values which are written into the two cutoff registers by sending F0 00 00 7E 40 00 0D 02 00 06 15 00 00 00 02 00 00 00 00 F7 with MIOS Studio as illustrated in this snapshot: It also shows the corresponding assignments of the filter values with the register readout. In this example, I changed cutoff from 7FE to 805 and requested the cutoff values after each step by sending the sysex string described above. Note that the SID filter works at 11 bit only, but MBSID uses 12bit. Combined with the calibration routine the next MSB will be reached at 801 and not 800 - thats no bug (correct by construction), and under proper conditions it will never result into an audible effect (like on your MP3s) Best Regards, Thorsten.

Please post: - a patch in .syx format (just open the SysEx tool of MIOS Studio, enable receive mode, press SHIFT+Dmp on your MBSID to send the patch) - an audio sample in .mp3 format - the exact filter settings in ensemble FIL page Best Regards, Thorsten.

I just have noticed, that the arpeggiator doesn't work with Input ports set to "All", you have to select a dedicated port. I will fix this in the next release It works when a dedicated input port is selected, with and without T/A split Yes, you will have to activate T/A split and send the root note with the lower keys (either from a keyboard or from a second loopback track), and the chord with the upper keys. Use track transpose to correct the octaves. The "loopbacked chord track" should be in transpose mode Alternatively you could transpose the "loopbacked chord track" from a second loopback track via CCs. This makes sense if you prefer an independent transpose. You could play certain tracks on Bus2, 3 or 4, and use the MIDI router to forward the MIDI stream to a physical MIDI device. This gives you more flexibility, e.g. you can change your MIDI wiring without changing the track configurations, just adapt the global MIDI router settings. It's an expert feature only. Best Regards, Thorsten.

The upgrade path is simple: build a MBFM w/o control surface (MBHP_CORE and MBHP_OPL3) only, and control it from the Java editor until the "remote access" solution is available. You can already use a PIC18F4685 instead PIC18F452 with the existing firmware w/o changes. Later two data lines to OPL3 (D2 and D3) have to be connected to some other IO pins, since RB2/RB3 will be allocated by CAN. But no other changes will be required (no additional devices, etc) Best Regards, Thorsten.

It's very likely that MBFM V2 will run on a STM32F05 based core, and that it will provide a more modern sound engine + UI (e.g. with graphical LCD option, perhaps also with touchscreen) It's likely that it will be controllable from the MBSID V3 CS and VST/AU It's even likely that for an easy adaption the OPL3 will be controlled via PIC18F4685/CAN like the SIDs It's unlikely that I will provide an option which doesn't rely on a STM32F105 based core. Best Regards, Thorsten.

Aha, Du bist also ein Flachloeter. ;) Das klappt mit meiner ERSA Loetspitze 832SD (Bleistiftform) uebrigens definitiv nicht, und schon gar nicht wenn sich die Pads nicht direkt am Rand befinden. Da braucht es schon ein paar Minuten, bis die Bauteile (vor allem MIDI Buchsen und VRs) sauber verloetet sind, und sie werden dabei sehr heiss. Mit einer breiten Loetspitze muss man nur mal eine Sekunde lang antippen, schon ist das Loetzinn sauber verflossen. Ich berfuerchte ja, dass viele Leute dieses Problem haben, und dass es deshalb sehr oft zu verkohlten PCBs oder kalten Loetstellen kommt. Gruss, Thorsten.

Zu den vollflaechigen Loetpads ein Kommentar: ich fand das beim Loeten auch immer aergerlich, doch es gibt hier eine Fraktion, die sich vehement dagegen wehrt, sog. Thermals in das Layout einzubauen. Doch dann ist mir neulich eher durch Zufall aufgefallen, dass sich die Massepads supereinfach verloeten (und auch wieder entloeten) lassen, wenn man da einfach mal mit einer breiteren Loetspitze rangeht. Mittlerweile vermute ich, dass die besagte Fraktion zu den heimlichen Breitspitzloetern gehoert, und dass es deshalb angeblich "nie probleme beim Verloeten" gibt. Gruss, Thorsten.

Ich finde die Idee genial! :) Gruss, Thorsten.

Roger's proposed solution is attractive, because it doesn't require a PIC programmer. On the other hand using a small PIC16F88 would be better for those DIY people who prefer easy to handle DIL packages. Djamon: your proposal to use a "discrete circuit" sounds simple, but it's much more complex (and therefore more error prone) than using other solutions I had in mind. E.g., instead of a NE555 timer, I could simply use a timer output pin of STM32 to generate a pulse. By using a transistor it could be easily converted to 5V in push-pull mode. The pulse has to be generated before DIN inputs will be captured. This backup solution will allocate some resources of the STM32, such as one GPIO pin and a timer. It will require some SRIO driver changes (pulse has to be triggered before DIN values are captured, implementation should be completely interrupt driven), and it will be difficult to identify a GPIO pin which isn't used yet (at least by MBLC), and can be controlled by a timer peripheral which isn't used yet and won't be used by future enhancements. This backup solution will require some conceptional work at my side, for which I don't have the time yet (project overflow). Using a PIC16F88 would be a solution where I could already say today, that it will perfectly work without conflicts. Therefore this is the only solution today where I could say: yes, I can do it this way without much effort (especially since I've enough spare PICs) Best Regards, Thorsten.