TK.

I don't see a reason why a change has to be made in MIOS... there are many applications (like MBSID, MBSEQ) which provide such functions as well. They are not made for your usecase, of course ;) MB64 groups the 64 LEDs into 8 bytes. Each bit represents a LED (8x8 = 64) The first group is located in MB64_BUTTON_VALUES_SR0, the second in MB64_BUTTON_VALUES_SR0+1, the third in MB64_BUTTON_VALUES_SR0+2, etc... Example: If you would clear all bits in MB64_BUTTON_VALUES_SR0, before setting the bit which corresponds with the LED, you would easily get a "radio button group" of for 8 LEDs/buttons E.g., if you want to use it in conjunction with the "OnOnly" button function, just add: [tt] MB64_BUTTON_OnOnly ;; save status of button rcall MB64_BUTTON_Hlp_SaveStat ;; when on: send button value defined in dump ;; when off: send nothing BRA_IFSET TMP1, 0, ACCESS, MB64_BUTTON_NotifyChangeEnd ;; new SET_BSR MB64_BUTTON_VALUES_SR0+0 setf MB64_BUTTON_VALUES_SR0+0 ; turn off first 8 LEDs rgoto MB64_BUTTON_Send [/tt] and it will work. Wrong! See Keith's final solution below Using more or less LEDs will require some understanding about masked bit operations. The appr. assembly instructions (like andwf) are documented in the PIC18F452 datasheet Best Regards, Thorsten.

Yes, you have to change DEFAULT_SRM_BUTTONS_NO_UI to 0 Best Regards, Thorsten.

Welcome back! :) The version will be displayed in the main menu page (press menu button). If record was working before, it's probably only a coniguration issue. Maybe the wrong "keyboard channel" is selected in the MIDI Configuration page? Best Regards, Thorsten.

As mentioned above: it doesn't make sense to report any anomaly which happens with the right channel bassline I must say, that I'm not able to understand your descriptions completely, but in general I'm very sure, that there is no bug in the Oneshot and Sync handling - it works as intended (at least for the left channel bassline, as highlighted several times...) - in general, you can assume that I know what I'm doing... ;) Best Regards, Thorsten.

Hi, which tests of the MIDI troubleshooting guide are working, which ones are failing? Best Regards, Thorsten.

I'm planning to add such a function in future (there is another topic where possible use models have been discussed) Best Regards, Thorsten.

...and if you would add the 8 row and 8 column buttons of the modulation matrix, you could even be able to quickly select the sequence of left bassline (row buttons) and right buttons (column buttons) without external keyboard, and without time consuming CS interactions... Best Regards, Thorsten.

Thanks, it's really good to know that it was only an hardware issue! Best Regards, Thorsten.

uCApps answers the question, and there is even a snapshot which shows the two In/Out ports Good that we talked about this! Best Regards, Thorsten.

Keep on searching... ;) Best Regards, Thorsten. /Edit: ok, one hint: this function is only intended for slaves... accordingly, CS_MENU_SID should never be 0 If you are using a search function over all source files (Unix: grep), you will find some nice coding examples, how to use the function. If you search more, you will even find a function which allows to play notes/sequences via button

yes No, you can't. The trigger flag has no effect without the sync flag. See SIDSE_B_SYNC_LFO1_Skip and SIDSE_B_SYNC_LFO2_Skip. And on the other hand: a LFO resynchronisation is required anyhow to process a whole LFO period, so I don't see a reason why it should make sense to use Oneshot without Sync. If you want to realize an oneshot mode, which works independent from the played notes, some more changes are required. The existing code gives you some hints. Best Regards, Thorsten.

Oneshot LFOs will be restarted with the gate. Legato Mode: you need to release all keys, and play a new note Mono Mode: with each new note Sequencer: when a note is not tied (no retrigger on slided notes) In all modes, the LFO Sync Flag needs to be set in addition It currently doesn't work for the right channel bassline. I know about this, no bug reports required. These inconsitencies came in with the latest changes in the multi engine (improved poly handling), this handling will be deactivated whenever bassline engine reuses code from multi engine. There is a similar issue with some parameters of the right channel envelope... In order to retrigger the LFOs, you need to set the flag SID_SE_TRG_EVNT_H, SID_TRG_TARGET_H_L1 for left channel LFOs, and SID_SE_TRG_EVNT_H, SID_TRG_TARGET_H_L4 for right channel LFOs (remember: right channel LFO handling currently doesn't work properly) If this doesn't make sense to you, I cannot give you additional tips, as nobody understands them anyway ;) Best Regards, Thorsten.

Will be fixed as well... Best Regards, Thorsten.

fixed...

Der MIDI-Kanal befindet sich in den unteren 4bit des Status-Bytes Moegliche Werte: 0xb0 (fuer Kanal 1) bis 0xbf (fuer Kanal 16) Das koennte man auch so schreiben: "0xb0 + kanal_von_0_gezaehlt" wobei "kanal_von_0_gezaehlt" ein Wert zwischen (dezimal) 0 und 15 sein sollte. In Deinem Anwendungsfall (11 Fader, pin == 0..10) koenntest Du den Kanal wie folgt bestimmen: [tt] MIOS_MIDI_TxBufferPut(0xb0 + pin); MIOS_MIDI_TxBufferPut(07); MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(pin)); [/tt] Gruss, Thorsten.

Nice "Blofeld" format! :) Best Regards, Thorsten.

A direct mapping of incoming SysEx parameter changes to CS items isn't possible without a lot of additional program code+map tables, or a lot of calculations, which would affect the performance of the synth engine. I guess, that nobody would really like such a visualisation feature which leads to drawbacks at the audible side, or which would prevent me from adding new features in future because of a completely allocated flash But - maybe a more powerful, because more flexible option: it would be possible to integrate a "remote control" function for button and rotary encoder functions. Are you able to send relative CCs with your MIDI controller? Best Regards, Thorsten.

Wow! :) Gruss, Thorsten.

So long an encoder is in normal mode, you won't notice any acceleration effect, because MIDI events are sent faster than the time between the "clicks" Once you are using "fast speed" mode, the incrementer changes as specified here MIOS_ENC_SPEED_FAST ~~~~~~~~~~~~~~~~~~~ // in this speed mode the increment value depends on the // rotational speed based on the following formula: // speed_ctr: decremented with every update cycle // (-> MIOS_SRIO_UpdateFrqSet) // (normaly 1 ms) to measure the time between // two encoder steps // Init value: 0x7f // reaches 0x00 after 127 update cycles // (normaly after 127 ms) // <parameter>: specified with the MIOS_ENC_SpeedSet // // function, allowed values: // 0 (fast) -> divider = 2^(7-0) = 128 // 1 (faster) -> divider = 2^(7-1) = 64 // ... // 7 (fastest) -> divider = 2^(7-7) = 1 // -> // incrementer = speed_ctr / (2^(7-parameter)) // set speed for encoder #0 to "fast", speed exponent value is 2 MIOS_ENC_SpeedSet(0, MIOS_ENC_SPEED_FAST, 2); [/code] So, I don't know why people are not searching in the MIOS function reference and in existing C examples? Sometimes, it really seems to me as it was wasted effort to write down all the details, because people will ask in the forum anyhow :/ Best Regards, Thorsten.

try the coding example, it is doing exactly for what you are searching for! Best Regards, Thorsten.

Das war ein Konvertierungsfehler in midio128_din.inc Unter http://www.ucapps.de/mios_download.html befindet sich nun der update Gruss, Thorsten.

Unter http://www.ucapps.de/mios_download.html Gruss, Thorsten.

If the first DIN sends multiple MIDI events, it seems to be a problem with the RC or SC clock line Some time ago, I wrote a troubleshooting guide which should help to find the wiring or soldering error: http://www.midibox.org/dokuwiki/din_module Best Regards, Thorsten.