TK.

No, unfortunately a PIC18F4685 won't work as it has less RAM than the PIC18F4620. Best Regards, Thorsten.

I haven't tried this yet, but it will only cost me a weekend... Most of the required functions are already prepared (e.g. scanning directories, reading configuration files, reading/writing SysEx files...) - I don't see a reason why it shouldn't work. However, I guess that documenting and releasing MIOS32 has higher priority? Best Regards, Thorsten.

Interesting find! The firmware already provides this mechanism (-> the Phase control allows to set/clear the test bit with a defined delay in the range of 1..255 uS in steps of 1 uS - exactly like if you would insert NOPs into the C64 code). All I need to do is to remove the noise lock protection (means: removing two assembly instructions which I included for your own comfort). And the best: since the phase parameter can control all 3 oscillators, more special sound variants can be generated compared to Wave Composer, which nobody have heard before ;) Best Regards, Thorsten.

Song mode: just read the manual of V3 - it's sufficient, nothing will be changed here. News: you could follow the log of this SVN directory http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2F The firmware is already in use by two friends and myself. All new features are working perfectly - no bugs so far, only unimplemented minor features which I don't find so important. Best Regards, Thorsten.

Could you please try Ploytec driver v1.0.6 instead of v1.0.7? It can be downloaded from this page: http://www.ucapps.de/mbhp_usb_gm5.html Best Regards, Thorsten.

Ja, mit wenigen Anpassungen in main.c wird das funktionieren. Statt CCs sendet man einfach Pitch Bender Events, und die VU Meter Werte erhaelt man als Channel Aftertouch Events Gruss, Thorsten.

Alright ;) (although I'm experienced with HDL design, the usage of FPGAs wouldn't be an option for my hobby project) Best Regards, Thorsten.

You could use MIOS_LCD_YAddressSet to adapt the offset. Best Regards, Thorsten.

What kind of MIDI events should be sent? So long the Note/CC number doesn't matter (as you can configure the routing in Ableton Live anyhow), you could use the ain64_din128_dout128 application without any changes. MB64 is only relevant for people who want to control MIDI hardware directly w/o using a computer. Best Regards, Thorsten.

I'm definitely interested on the results. I already did some plannings for MBSID V3 where similar update rates will be possible. What I found as a limiting factor is the bus interface of the SID, as the write/chip select input has to be strobed synchronous to the SID clock (= 1 MHz) to avoid sporadical effects like multiple gate triggers (especially bad if the ADSR workaround is applied) or crackling sounds on frequency/pulse width/filter sweeps. Such a requirement means, that it won't be possible to update more than 8..10 SID registers per scan cycle - did you already consider this and/or found a better solution (e.g. additional hardware) to ensure synchronous timings? dsPICs are a good choice for this kind of usecase. :) Best Regards, Thorsten.

Interesting! Could you please share some MP3s to give us an impression? How did you solve the problem of an accurate 1V/oct conversion, are you using an external 16bit ADC? And what is the sample rate, how many CV inputs are available? Best Regards, Thorsten.

Of course, if it is possible to create a unique byte value from the 2^(3*7) = 2^21 bit range, than a hash function is a practicable solution. But it will be less flexible, as you have to adapt the calculation of the hash value whenever new value sequences have to be parsed (no problem for you, as the sent MIDI events of your keyboard are known and won't be changed) It would be different if you would use a 32bit controller (like MBHP_CORE_STM32 :)), because here it doesn't matter if the hash is 8bit, 16bit, 32bit - in any case the CPU will need the same time to compare the value. For 8bit controllers it means that comparing values with range >8bit is very *very* expensive, since many instructions have to be executed to get the complete result. Accordingly, your coding strategy has to consider such limitations. Btw.: a binary tree search would also be an option, but a good solution would use a code generator (resp. parse tree generator) as well. Best Regards, Thorsten.

I would prefer method 1 due to the better overview. But I wouldn't start the search for a matching sequence once all three values have been received, instead I would do this on-the-fly whenever a new MIDI event has been received to improve the realtime responsiveness of the application. Just use a single table which contains the three values + a pointer to the function which should be called in each line. Something like this: const my_search_structure_t search_structure[] = { // BC LSB MSB PC Function { 0x00, 0x70, 0x01, &DoThisFunction }, { 0x00, 0x44, 0x05, &DoThatFunction }, }; [/code] Strategy: - when the first event (BC MSB) is received, search for the first member in the table with matching MSB number - when the second event (BC LSB) is received, check if the second value is matching as well, if not search for any of the following members with matching MSB/LSB number - same when PC is received. First check for matching PC, and if it doesn't match search for the next matching MSB/LSB/PC element. - finally you should know the member which is completely matching, so that the function can be called A way to speed up the search would be a sorted table (something you can do manually, especially because the table structure doesn't change during runtime), so that your algorithm can break the search once the incoming number is lower/higher than the value of the current structure member. And a way to speed up the search even more: set a threshold for the starting point. E.g. 64 (or any number which is in the middle of the search values in the first column). This allows you set the optimal starting point for the search. Alternatively to method 2: you could program a code generator (e.g. based on a small perl script) which generates the parser based on a human readable table. But I'm not sure, if it would run faster (on the PIC) compared to the table search method I mentioned above. Warning: there is a typical programming error in your code: [code] switch state { case 0: //no bytes received so far // ... case 1: //0x00 received there is no break before "case 1", accordingly case 0 will execute the code after case 1 as well (same for other case statements) Best Regards, Thorsten.

The link is already in the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=midi_specification I prefer to use the web.archive link since I know that it will exist permanently ;) Best Regards, Thorsten.

Great selfmade case and PCBs (?) :) What kind of encoder are you using? I never saw an encoder in such a white plastic package before. Best Regards, Thorsten.

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.