TK.

Well done! :thumbsup: It seems that the Atmel microcontroller has much "stronger" pad drivers compared to the PIC which can lead to such EMC issues. This might also explain why the 6581 was working: it's produced in a different technology which consumes more power. Probably the input resistance of the clock input is lower, and this causes the same effect like the cap that you've added. The proper solution would be (if my assumption is correct) to add a resistor in serial, e.g. 100 Ohm should be fine. It will limit the current drawn during signal transitions so that the nominal voltage isn't exceeded. Using a cap is also possible, but not the best choice, because it will cause higher current drawn during transitions (no dramatic drawn, not really noticeable, but if you ask for the preferred solution, take the resistor) Best Regards, Thorsten.

Hi, it should work the following way: configure the encoder, so that it doesn't send a value. The integrated button has to execute a .NGR script section. From there you could send the current encoder value - e.g. here for encoder 1 (ENC:1) # type port chn value send ProgramChange USB1 1 ENC:1 Unfortunately timed events are not supported. Best Regards, Thorsten.

It's interesting, that the other guy was using an Atmel chip as well, and had (or still has?) the same issue. I would propose to check the shift register transfers. Write a routine which allows you to set different data values at the shift register output, e.g. controlled via incoming CCs or MIDI Note events (so that you don't need to change your program while testing different values). Check that you can control each individual bit of the address and data lines, and that there are no interdependencies. E.g. if it turns out, that the gate flag (D0) doesn't work reliable, then you know that something might be wrong with the SPI transfer routine. It wouldn't explain why this doesn't affect transfers to a 6581, but on such mysterious effects it's always a good idea to ensure the basic infrastructure first. Best Regards, Thorsten.

If you want to modulate all three pitches from a single modulation path, just enable the L/R switches of the direct modulation targets: These are the same switches which are displayed by the Matrix LEDs of the CS The "soft-targets" (Tr1 and Tr2) are only optional for the case that you want to control something else than Pitch, Pulsewidth, Filter or Volume. Best Regards, Thorsten.

Not really - but remote diagnosis is difficult without knowing your hardware setup + software. The effect happened sporadically when a free-running (not synchronized) oscillator was used; conclusion: a) the SID clock shall be generated by the microcontroller b) each write access to a SID register shall be synchronized to the SID clock as described above to avoid timing violations. If the effect always happens, it could also be related to your hardware setup. E.g. defective SIDs, wrong voltage, wrong filter caps. Best Regards, Thorsten.

Yes, this has been resolved in November 2005 (so, almost 9 years ago) with exactly the solution that I described above. Best Regards, Thorsten.

I've updated the MIDIbox SID Panel, so that it works with the latest Ctrlr version. Download links can be found in the first post of this thread: Best Regards, Thorsten.

I've updated the MIDIbox FM Panel, so that it works with the latest Ctrlr version. Download links can be found in the first post of this thread: Best Regards, Thorsten.

The shift registers (to which the encoders are connected) are scanned each mS. Higher scan rates don't make a difference for encoders with up to 100 pulses per rotation. Here is btw. a tutorial for the encoder usage in MIOS32: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F014_enc_relative%2F And here is an older PIC ASM based solution, which might help you to understand the migration from ASM to C ;-) -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmios%2Fmios_enc.inc Best Regards, Thorsten.

Yes, the numbers are documented here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Finclude%2Fmios32%2Fmios32_midi.h search for mios32_midi_port_t In the MBSEQ_GC.V4 file you can either enter them in decimal or hexadecimal format. Best Regards, Thorsten.

Hi, the source code can be found under: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2Fcommon%2Fmios32_enc.c It works with polling, interrupts are no option when encoders are scanned via serial registers. Best Regards, Thorsten.

Hi Lars, it would be very difficult (and the wrong way) to implement additional encoder functions for GPIOs. They consume more CPU time than scanning the SRIOs (might sound strange, but the standard scan via SPI in background results into a better overall-performance) Only possibility that I see is to explain you how to modify the firmware for your particular use case. But I don't really want to provide a generic (user-configurable) solution. Alternatively buy a 74HC165 @Reichelt for 0.30 EUR... Best Regards, Thorsten.

It still works at my side, but I noticed a problem with the "store" function - it doesn't store the network setup. Could this be the problem at your side? (check the current configuration with the "network" command) The fix will be available with the next release. Meanwhile you could enter the configuration directly into the MBSEQ_GC.V4 file: BLM_SCALAR_Port 66 and OSC_RemoteIp 2 192.168.11.102 OSC_RemotePort 2 8000 OSC_LocalPort 2 8000 OSC_TransferMode 2 1 (note that in this file the connection numbers are counted from 0) After the changes, enter "reset" to reload the configuration. Best Regards, Thorsten.

The required configuration is explained in the MBSEQ manual: http://www.ucapps.de/midibox_seq_manual_blm.html search for "osc_remote" Did you try the same? Best Regards, Thorsten.

To 1) in src/cs_menu_tables.inc you will find following table: ========================================================================== ; The wavetable menu ; ========================================================================== CS_MENU_TABLE_WT db (CS_MENU_TABLE_WT_End-CS_MENU_TABLE_WT)/CS_MENU_ENTRY_LEN, 0x00 ;; Register (00=dummy) |<-->| max print ix, exec ix parameter transfer CS_MENU_ENTRY CS_MENU_WT_STEP, "Step", 0x1f+1,PRINT_VAR_WTSTEP, EXEC_SELPAR, R2PP2R_VAR_WTSTEP CS_MENU_ENTRY 0x00, "Mode", 0x03, PRINT_VAR_WTMODE, EXEC_TOGPAR, R2PP2R_VAR_WTPAR CS_MENU_ENTRY 0x01, " #1 ", 0xff, PRINT_VAR_WTPAR, EXEC_SELPAR, R2PP2R_VAR_WTPAR CS_MENU_ENTRY 0x02, " #2 ", 0xff, PRINT_VAR_WTPAR, EXEC_SELPAR, R2PP2R_VAR_WTPAR CS_MENU_ENTRY 0x03, " #3 ", 0xff, PRINT_VAR_WTPAR, EXEC_SELPAR, R2PP2R_VAR_WTPAR CS_MENU_ENTRY MBFM_Px_WT_RATE, "Rate", 0x7f, PRINT_Px_DEC, EXEC_SELPAR, R2PP2R_Px CS_MENU_ENTRY MBFM_Px_CTRL2_U, "Sync", 0x02, PRINT_Px_WTSYNC, EXEC_TOGPAR, R2PP2R_Px CS_MENU_ENTRY MBFM_Px_WT_PAR1, "CC#1", 0x7f, PRINT_Px_CCASG, EXEC_SELPAR_ASG, R2PP2R_Px CS_MENU_ENTRY MBFM_Px_WT_PAR2, "CC#2", 0x7f, PRINT_Px_CCASG, EXEC_SELPAR_ASG, R2PP2R_Px CS_MENU_ENTRY MBFM_Px_WT_PAR3, "CC#3", 0x7f, PRINT_Px_CCASG, EXEC_SELPAR_ASG, R2PP2R_Px CS_MENU_TABLE_WT_End Here you could re-order the menu items to test if you are satisfied with the result. Once you are happy, and for the case that more people would like to get this change, I would change this in the official firmware To 2) I understand your wish (I had the same, and implemented in MBSID V2) But for MBFM it isn't possible due to memory limitations and design decisions which make it difficult today to add such changes, as simple they might sound for you as a user... Please note also, that the MBFM project is only in "maintenance mode" anymore, which means: only bugfixes and minor changes which don't need much attention from my side will be provided. Best Regards, Thorsten.

The usage of source drivers (the transistors) is for pro users who want to get perfect results. I'm unsure if this really makes a big difference. It's more important that you try to keep the number of selection lines per matrix as low as possible (8 is acceptable, 4 is perfect) Best Regards, Thorsten.

I added the expert option in the Utility->OPT page (item #12) -> http://www.ucapps.de/mios32/midibox_seq_v4_084_pre1.zip Could you please test this at your side? Best Regards, Thorsten.

In this version the quantized value should be displayed at the lower line. The unquantized value is still visible at the upper right line. http://www.ucapps.de/mios32/midibox_seq_v4_084_pre1.zip This approach isn't an option, but always applied. Could you please test this at your side? Best Regards, Thorsten.

The Live feature shouldn't apply FTS to drum tracks anymore in this version: http://www.ucapps.de/mios32/midibox_seq_v4_084_pre1.zip Could you please test this at your side? Best Regards, Thorsten.

Ok, I see... please try this version: http://www.ucapps.de/mios32/midibox_ng_v1_031_pre2.zip In addition, you've to set "key=any" for EVENT_SENDER as well: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fconev_6.ngc Best Regards, Thorsten.

That's too much code for a quick check (and I'm also no DMX expert...) However, you wanted to setup Push Pull mode, but actually you activate Open Drain Mode: MIOS32_SYS_LPC_PINMODE_OD(2, 0, 1); Write (2, 0, 0) instead to ensure that Push-Pull is configured. (Sidenote: due to a LPC1769 silicon bug, it will be push pull anyhow, but just to ensure...) For the baudrate and pin behaviour, I'm sure that the scope will help to debug this! :) Best Regards, Thorsten.

Yes, it should have a positive effect on a MB64E as well. For large value ranges it's only subtile, for smaller ranges (e.g. 0..255 - mostly used) it's noticeable. This doesn't happen at my side. Ok, it depends on how we define "very slowly..." - but when I rotate the encoder slowly I can see that the values are incremented continuously and precisely +/- 1 With MIOS V1.9g sometimes the value was sporadically incremented much faster on slow movements, but with MIOS V1.9h this doesn't happen anymore. It could be related to your encoder. How does it work when you are changing CutOff with the main encoder instead? And compare also parameters with lower value ranges, acceleration control should be super-precise for them now :smile: Slave cores don't need the MIOS V1.9h update. Best Regards, Thorsten.

:pirate: :thumbsup:

Hi Phill, no, it "quantise" to the measure instead, and the measure length can be configured in the Utility->Opt page (it's 16 steps by default) Whenever these number of steps have been played, the step progression (clock divider values and step position) of the tracks which activated this synchronisation option will be reset. All tracks which have enabled the sync option should be aligned again once the measure has been played. I just tested this again at my side: it still works. :smile: This would be a slightly different approach, and I'm not sure if this is better than the current one. Currently the tracks just continue to play until the 1st step of the measure is reached, then all tracks which have this synch option enabled will be restarted and are then aligned again. The quantization works depending on the clock divider, and this might confuse you. Means: with a clock divider of 16 (16th notes) one step takes 96 "clock ticks". With a quantisation of 50% the incoming MIDI event will be put into the next step if it's delayed by more than 48 ticks. With a clock divider of 64 (4th notes) one step takes 384 ticks, therefore the incoming MIDI event will be put into the next step after a delay of 192 ticks. So: the time window over which the quantisation takes place is much larger. However, I think that 50% is a bad choice anyhow. Most people prefer 10% We had 20% by default some time ago, but users complained that this is too much. Therefore I would propose to try smaller values. Best Regards, Thorsten.

Ok, starting with MIOS32 was a good idea, because especially the possibility to send "printf" like debug messages helped me to find an easy solution, which also fits nicely into MIOS8. Could you please install this new MIOS version: /edit: removed expired link, please download the official version under http://www.ucapps.de/mios_download.html Thereafter install MBSID V2 again: /edit: removed expired link, please download the official version under http://www.ucapps.de/mios_download.html (still enctest2, the same that I provided some days ago) Encoders should behave better now! Best Regards, Thorsten.