TK.

yes, thats the way it works Here an excerpt from the MIDI spec: http://web.archive.org/web/20071005165309/www.borg.com/~jglatt/tech/midispec/seq.htm There was also a discussion in the (german) sequencer forum a while ago: http://www.sequencer.de/synthesizer/viewtopic.php?f=13&t=36650 Best Regards, Thorsten.

The resistance between directly connected pins shouldn't be higher than ca. 0.1 Ohm... With permutations I mean all possible combinations between Vss (Ground track), Vdd (+5V track) and the RD1/RD2/RD3 pins. See also http://en.wikipedia.org/wiki/Permutation Means: check Vss against RD1: no beep expected check Vss against RD2: no beep expected check Vss against RD3: no beep expected check Vdd against RD1: no beep expected (but resistance should be 10k, caused by R9) check Vdd against RD2: no beep expected check Vdd against RD3: no beep expected You could do the same at the 74HC165 site, but considered that Clk/LD/QH are directly connected to RD1/RD2/RD3, and there is no short between these pins, the results should be identical: check Vss against QH: no beep expected check Vss against LD: no beep expected check Vss against Clk: no beep expected check Vdd against QH: no beep expected (but resistance should be 10k, caused by R9 of the core module) check Vdd against LD: no beep expected check Vdd against Clk: no beep expected Best Regards, Thorsten.

Hi, pull the PIC and the 74HC165 out of the sockets, and use a multimeter beeper (or the ohmmeter function) to check following connections: PIC Pin RD3 -> 74HC165 Pin Clk PIC Pin RD2 -> 74HC165 Pin LD PIC Pin RD1 -> 74HC165 Pin QH If these connections are ok, check for shorts between the pins, e.g. check that the multimeter is not beeping when checking RD3 against RD2, RD3 against RD1, RD2 against RD1 Thereafter check Vss/Vdd as well, and all permutations between Vss/Vdd and RD1/RD2/RD3 This should help to identify the short or unconnected cable. Best Regards, Thorsten.

I'm glad to read this :) Best Regards, Thorsten.

This won't work properly with the AIN handler of MIOS8, because pin drivers have to be reconfigured, and some delay has to be inserted *before* the next conversion is started to get stable results. MIOS8 doesn't provide a hook for this, and because of various reasons (e.g. execution time requirements due to high update rate) I don't see a way to provide it for the 8bit version. MIOS32 already got this optional hook, and an example which scans a XY touchpanel is located here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F022_glcd_touchpanel%2F AIN_ServicePrepare() switches the pin configuration, and APP_AIN_NotifyChange() gets the conversion results. Only solution I see for PIC: you have to program an analog conversion handler by yourself. The performance won't be so good like with MIOS32, but it should be sufficient so long not so many other tasks are handled by the PIC as well. You could handle the conversion from the Tick() hook. This (assembly based) routine shows, how to control the ADC. The interesting part is located in AIN_Init and AIN_Tick, AIN_Handler is very application specific (you can ignore it) http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v2%2Fsrc%2Fain.inc Best Regards, Thorsten.

We upgraded this sequencer to MBSEQ V4 today. We replaced the MBHP_CORE module by a MBHP_CORE_STM32, created new LCD cables with 1:1 pinning and a new cable to DIN and DOUT chain: Fortunately the slot which was previously used for mounting three MIDI sockets and a power connector is large enough for the USB + 4 MIDI sockets of the new core module: For the SD Card we used a cheapo floppy edge connector: We haven't noticed hardware issues after the update, everything worked immediately! :) Best Regards, Thorsten.

You could speed up the next order by requesting more GM5 than you currently need (appeal to everybody). This makes it more expensive for you, but increases the chance that the 250 mark will be reached soon. Best Regards, Thorsten.

This topic has been moved to Miscellaneous. [iurl]http://www.midibox.org/forum/index.php?topic=13812.0[/iurl]

In the software you are using ("traktor PRO"?) Best Regards, Thorsten.

Nothing sounds wrong based on your descriptions. Some additional tips I could give you: - use the "verify" function in MPLAB to ensure, that the flash has been programmed correctly. - I don't know if it is still relevant, but PICstart doesn't program the device ID, it will be All-One instead of All-Zero with the result, that the wrong MIDI baudrate is selected. This page provides a small program which fixes the ID field (TEST SW2) - you could also try "TEST SW1" if you want - and all other tests of this page (I haven't found any reference in your posting, maybe you missed this guide?) My experiences with PIC programmers: I started with a PICstart kit ca. 11 years ago, and had to upgrade it several times With PIC18F4620 I noticed so many programming errors, that I decided to build an own programmer (-> MBHP_BURNER) which works pretty stable. Meanwhile I don't have a PC with RS232 port anymore, and my PICstart doesn't work via a USB->RS232 interface, so that I've no possibility to check the compatibility with certain alternative programming software. But I don't think that this information is relevant for you if the verify function passes! In other words: there is a certain chance that you will be able to program the PIC18F device properly with your PICstart. Especially if the verify function passes, it can be assumed that the PIC has been programmed correctly! Best Regards, Thorsten.

Alright - hope that this doesn't happen again when I release v3.4f this weekend ;) (it will contain the latest improvement requests) Best Regards, Thorsten.

Wasn't this issue fixed in v3.4e? I tested it myself, and futureman probably as well? If there is still an issue with this function, I need to know more details how to reproduce it. Best Regards, Thorsten.

Oh, what a great design, Allesandro! :) Sounds like the MIDI merger has been activated, and your software forwards incoming MIDI events to the output as well. This will result into a feedback loop which can quickly result into a MIDI buffer overrun either at the MIDIbox, and/or at your computer side. So - just disable the Merger (MB64E: can be done in the MIDI configuration page), and at your computer side disable the option which activates MIDI forwarding. Best Regards, Thorsten.

You forgot to initialize the SRIO driver, see also the Init() function of this example: http://www.ucapps.de/mios_c_set_dout.html Best Regards, Thorsten.

No feature, but a known issue: http://www.midibox.org/forum/index.php/topic,9457.msg117957.html#msg117957 The bugfix is already in the SVN repository. Best Regards, Thorsten.

Yes... see also http://www.midibox.org/forum/index.php/topic,13488.msg116060.html#msg116060 Best Regards, Thorsten.

No, this isn't required for MIOS8, as there is only a single interrupt level (for MIOS32 it's a completely different story...) Disabling interrupts is sufficient for "atomic operations" Best Regards, Thorsten.

Wow, thats an interesting input! This could explain, why people sometimes report a problem with their MIDI IN port, or why sometimes optocouplers got fried. Therefore I added TEST IN1B to the troubleshooting page, but I fear that I've to change the labels in all schematics to be sure that nobody interprets them incorrectly. TEST IN1B: Check that the 6N138 optocoupler is put with the correct pin orientation into the socket! Pin #1 (marked with a notch) shows into the direction of J11! Note that the optocoupler could be damaged if you are trying the wrong pin orientation! [/code] Best Regards, Thorsten. P.S.: LyleHaze: as always great tips!

I'm patentially waiting :) Best Regards, Thorsten.

No, samples are not supported. See also http://www.midibox.org/forum/index.php/topic,10421.msg78752.html#msg78752 You should go for HardSID if you are finding sample playback so important. Best Regards, Thorsten.

Ok, I added a record button and LED Problems: confusing handling if not consistently provided for most parameters in all menu pages, and there are more than 8 MIDI Output ports (currently: 20 different ports like USB1-4, UART1-2, IIC1-8, OSC1-4, AOUT1-4, Bus1-4, etc...) and more than 8 AOUT channels. I already spent some thoughts on providing a "quickselection page" of up to 16 "most important values" when pressing the SELECT button. But by thinking a step further I came to the conclusion, that this would only result into a lot of additional effort and many complains from users who think that they found a bug if a certain parameter isn't selectable or not visible on the page (e.g. MIDI Channel Selection in MIDI page: 1-16 could be selected, but what about "All" and "None" - a user could overlook such important options if he only uses the quickselection but never turns the encoder below the value) Best Regards, Thorsten.

Thank you - this bug exists since 224 days! Shame on the guy, who requested a bugfix for "character artifacts" but hasn't tested all menu pages! ;) (*) The fix is already in the repository and will be available with the next release. Best Regards, Thorsten. (*) just kidding - I knew that such dramatical changes will cause new issues w/o intensive tests

Yes, good hint LyleHaze - it makes sense to check a precompiled application after MIOS has been repaired If there is an issue with your LCD: there are a lot of troubleshooting infos in the forum and in the Wiki! Best Regards, Thorsten.

Probably you corrupted MIOS during your first experiments. I would propose to upload it again (-> mios_v1_9f.hex of the MIOS update package), thereafter upload the application. Note that once you've repaired the MIOS installation, you don't need to upload it again. Just ensure, that your application never overwrites the range between 0x0000..0x2fff (this range is excluded automatically by the linker script if you are using the original MIOS toolchain setup, and not your private .lkr file) Best Regards, Thorsten.

MIDI-Ox: uncheck the "Automatically attach Inputs to Outputs during selection" Option. It causes a SW loopback. Thereafter, deselect the MIDI Ports, select them again - this will activate the IOs without creating the loopback. Could it be, that you are running MIDI-Ox and MIOS Studio in parallel? THis would explain, why MIOS Studio behaves so strange as well. Best Regards, Thorsten.