TK.

No SSL so far - thanks for the reminder! Best Regards, Thorsten.

Hi, yes, you should read 5V on C3, C4 and J2. But based on your measurements the capacitors don't cause the problem (it would be a short, resulting into 0V at pin 1). Sounds like a bad solder joint or broken track? What happens if you connect pin 1 and 2 with a short wire? Best Regards, Thorsten.

This feature was requested from a user who just wanted to forward MIDI messages to the preconfigured MIDI port/channels of the tracks without further processing, and this is how it's working. Your request goes into a different direction, it's more like a multi channel live/recording function - currently we can only record or play live (+ FX) on a single (selected) track. Allowing more channels would lead to higher RAM consumption, but it could be provided as a MIDIbox SEQ V4+ option, only working on a STM32F4. I'm unsure how Mutes should be handled in this case. I would expect that independent Mute control would be preferable, e.g. to mute the sequence played on a track when the instrument should be played live, but this contradicts with your request. On the other hand: if separate mutes for this forwarding function are provided, where/how should they be controlled? Best Regards, Thorsten.

Yes, this makes a difference, because the ADC channels have to be selected differently in the firmware. Here a build for PIC18F4685 - untested (hope that it works): http://www.ucapps.de/mbhp/mbhp_mf_ng_v1_005_pic18f4685.zip Best Regards, Thorsten.

I found this firmware in my backups, the link is working again Best Regards, Thorsten.

It took a bit longer than expected, but finally we've a new forum software and also the gallery should work again Yes, I'm definitely interested on "reporters" for the wordpress blog; let me update the installation, thereafter I can give you access :) Best Regards, Thorsten.

Very cool transparent case! :) Best Regards, Thorsten.

Hi Richie, in MIOS Studio, MBHP_MF_NG configuration tool, please check the MIDI configuration. E.g. the "operation mode" defines, what kind of MIDI events are sent, and the "touch sensor mode" defines, under which conditions they are sent. Best Regards, Thorsten. P.S.: Don't know where to find the MIDI 3 IN/OUT wiring schematics, maybe the forum search function helps.

Unfortunately gallery rebuild times out, and it requires a forum update: https://invisioncommunity.com/release-notes/ Will check it later this week - updating the forum SW is on my backlog anyhow (since several years ;) Best Regards, Thorsten.

@latigid on some history on this: while previous boards had a pull-up device for this pin, the STM32F4 Discovery Board had a pull-down, therefore I did'n activate an internal pull device to avoid cross-currents. Good that you didn't completely remove the option for an external resistor! :) @Hawkeyegreat demo, I like it! :) With the step sequencer features the LoopA even becomes interesting for me as a guy who unlearned live playing (too much automation - I was better >20 years ago ;-) The graphics are epic! :) Best Regards, Thorsten.

It's difficult to predict if a reversed J19 connection could damage the DAC, but I still use the same board that I got from Seppoman many years ago, and somehow it survived although I sometimes did really stupid wrong connections. Typical test procedure at my side: connect the module (this can be done while MBSEQ is running) crossing fingers that I didn't misinterpreted the schematic enter CV page, re-select the interface with Encoder #16 (e.g. select AOUT, than back to AOUT_NG) -> this will initialize the DAC set different calibration values with Encoder #7/8 measure CV output - and if it doesn't change, measure also the DAC output pins (to confirm that the non-amplified voltage is changing) Best Regards, Thorsten.

We will continue the dialog via PM, and if a solution is found, post the update here. Best Regards, Thorsten.

Yes, but I wasn't able to reproduce this at my side. Could only be related to the LPC17 build (it has reduced RAM, and the hard fault address indicates a problem with memory writes), but unfortunately I don't have the HW ready. Best Regards, Thorsten.

Hi Gerhard, I like Python as well and use it sometimes @work, e.g. because it has very powerful libraries for data processing and visualization, and last but not least it's easier to share code with younger colleagues :) I'm not sure how well Python supports MIDI on different operating systems meanwhile - I selected Juce many years ago to get a stable solution for Windows/MacOS/Linux, but I'm missing scripting/quick exploration capabilities. An OS independent Python based MIOS32 communication library would definitely be valuable (but I've no bandwidth to do the groundwork :-/) - you've a use case where such a library would be helpful. Best Regards, Thorsten.

Very good! :) A nice feature could be to transfer the files directly via SysEx, so that the SD Card doesn't need to be removed. With some special firmware support (e.g. reload pattern when file has been updated) this could even allow on-the-fly editing. Unfortunately the file transfer protocol isn't properly documented, information has to be puzzled together from MiosFileBrowser in MIOS Studio: https://github.com/midibox/mios32/blob/master/tools/mios_studio/src/gui/MiosFileBrowser.cpp sendCommand() is used to request the directory tree, and the read/write files, and receiveCommand() shows how incoming data has to be handled. Best Regards, Thorsten

Hi, I'm currently trying to catch up with the issue reports. Some days before @modus0perandireported the issue with Duplicate FX, a user named "nullptr" at Github submitted a pull request which fixes it - cool! :) -> https://github.com/midibox/mios32/pull/9 Here the new binary: http://www.ucapps.de/mios32/midibox_seq_v4_097_pre5.zip Are there other issues which still appear with this version? (I need a detailed description how to reproduce it at my side) Best Regards, Thorsten.

Ok, ich habe in den entspr. Schaltplaenen dann mal Pin 4 und 5 miteinander verbunden. Wurde ja auch so langsam mal Zeit ;-) -rw-r--r-- 1 TK staff 12558 Dec 30 2015 /Users/TK/Sites/ucapps/mbhp/mbhp_4xsid_c64_psu.pdf -rw-r--r-- 1 TK staff 17371 Jul 1 2007 /Users/TK/Sites/ucapps/mbhp/mbhp_4xsid_c64_psu_optimized.pdf -rw-r--r-- 1 TK staff 22704 Jul 1 2007 /Users/TK/Sites/ucapps/mbhp/mbhp_8xsid_c64_psu_optimized.pdf -rw-r--r-- 1 TK staff 5799 Jun 10 2006 /Users/TK/Sites/ucapps/mbhp/mbhp_sid_c64_psu.pdf Gruss, Thorsten.

Frueher hat man auch Leute auf den Mond geschossen ohne zu bedenken, dass man das in 35 Jahren genau so wiederholen moechte... soviel zum Thema Nachhaltigkeit ;-) Schaust Du bitte nochmal auf den Schaltplan? Ist es nun Pin 4 oder 5, der bei Dir funktioniert? Gruss, Thorsten.

Super! :) Ich hoffe, dass ich in diesem Schaltplan ebenfalls Pin 4 eingetragen habe? -> http://ucapps.de/mbhp/mbhp_8xsid_c64_psu_optimized.pdf Interessanterweise steht hier: https://allpinouts.org/pinouts/connectors/power_supply/commodore-c64-power-supply/ das Pin 4 manchmal "nc" (not connected) ist, und 5V lediglich auf Pin 5 "garantiert" ist. Gruss, Thorsten.

Hallo Krizz, ich verwende das gleiche Netzteil von c64psu.com, da mir das mit den alten C64 Netzteilen zu gefaehrlich geworden ist - das bisher verwendete ist mittlerweile 35 Jahre alt, die Gefahr ist zu gross, dass irgendwann der 5V Regulator seinen Geist aufgibt und die Chips mit Ueberspannung versorgt. Gestern habe ich das neue Netzteil nach vielen Wochen mal wieder an meine MB6582 angesteckt, interessanterweise war die Spannung etwas niedriger als sonst. Das Backlight des Displays war dunkler als sonst, und nach einigen Minuten wurde der PIC reseted (wahrscheinlich der Brownout Reset, der bei VDD<4.5V anschlaegt)). Habe das Netzteil dann aus, und wieder eingeschaltet: danach lieferte es die volle Spannung (5V). Auch heute laeuft es problemlos, werde mir das aber beim naechsten Mal genauer anschauen. Insofern waere es interessant zu wissen, ob das neue Netzteil auch bei dir funktioniert, wenn es erstmal warm geworden ist? Danach aus/einschalten - vielleicht hilft es ja. Falls nicht, macht es u.U Sinn, c64psu.com zu kontaktieren (kann ich uebernehmen) - vielleicht kennen die das Problem bereits. Gruss, Thorsten.

Hi Rainer, I can help you on this - you got a PM Best Regards, Thorsten.

First of all we've to align on terminology: MIOS is an operating system, but we are speaking about the MIDIbox SID V2 application which is installed on your sammichSID hardware together with MIOS. It's the MIDIbox SID application which controls the SID registers. Second: there is no "clear gate" bit. In the video, you will see at 0:52 that the Gate bit (rightmost switch) is set to 0. And that's the same what MIDIbox SID is doing. And when you listen carefully, you will notice the same background noise, sometimes also called "leakage noise" With some SID chips (especially the older ones), this leakage noise is much louder. You are using 6581 R2 - this early chip version could be affected much more from this design flaw. From an interview with Bob Yannes: What Bob calls "stopping the oscillator" is done during patch change by setting the TEST bit. It's also used by the Phs ("Phase Oscillator Offset") feature when a new note is played (but not when somebody stops to play a note...) The problem with this flag: it resets the oscillators - for typical "analogish" sound really no preferred option! From this page: DOR: Disable automatic Oscillator Reset during patch change. Could also be called DAORDPC flag ;-) Background: after patch change, MBSID normaly resets the oscillators to ensure, that a patch always sounds identical w/o unexpected phase cancelation effects between the oscillators. Other peoples prefer such effects, caused by freerunning oscillators. If you belong to those peoples, and know what it means, just activate this option - it will make you happy! ;-) GSA requires an external VCA to control the volume You can set Atk, Dec and Rel to 0 in the OSC page, and configure the filter in the FIL page. Best Regards, Thorsten.

Just set the ABW (ADSR Bug Workaround) flag on your sammichSID. Search on this page to get more information about the consequences: ABW (ADSR Bug Workaround): an option which provides a less usual method to overcome the ADSR bug. Whenever the envelope is retriggered, the ADSR registers will be zeroed for at least 30 mS (time can be increased with the delay parameter). Thereafter the original ADSR values will be written back, and the gate will be activated. This results into a more deterministic envelope, but the latency makes it unsuitable for live playing. So, this feature can only be used in conjunction with a sequencer, which allows to compensate the delay (which allows to play the notes earlier by a given time). Another way to avoid it: set A, D, R to 0 and let the SW based Filter ADSR control the volume - this will also work live - and is used by most sammichSID patches. Best Regards, Thorsten.

Analog pins are permanently polled by the AIN driver, this is done via DMA in background (so that the CPU isn't loaded) If you've to set pins before the next scan, then just use a AIN ServicePrepare callback. See also following tutorial which shows how to scan a touchscreen - actually a similar handling like described for your use case: https://github.com/midibox/mios32/tree/master/apps/tutorials/022_glcd_touchpanel Best Regards, Thorsten.